In May 2026, 84 malicious package versions were published through TanStack‘s own CI/CD pipeline with cryptographically valid SLSA provenance attestations. They were not forged, not bypassed, not broken. Sigstore verified TanStack’s release workflow built those packages. It had, and the worm was inside the pipeline.
If you have spent years building supply chain controls, that should make you uncomfortable. Attacks exploiting this gap trace back to the same structural problem: how we assign trust to inputs. This article walks through four places that model breaks, identifies the root cause, and maps what a coherent architecture looks like when every control has a known failure mode. For the arms-race picture, see the full AI cybersecurity arms race.
What are SLSA provenance attestations, and why can malicious packages still carry valid ones?
SLSA (Supply-chain Levels for Software Artifacts) tells you how an artifact was built: which builder, from which source, using which workflow. Sigstore’s Fulcio CA and Rekor log make attestations tamper-evident, letting you verify which build process produced which artifact.
The gap is what SLSA does not verify. Provenance proves who built what from which source. It does not prove the source was benign. A compromised maintainer produces valid attestations on malicious code, and provenance was never designed to catch that. npm’s built-in provenance achieves Build Level 2, where the platform generates signed attestations. Build Level 3 adds platform isolation: no shared caches across builds, no build access to signing keys. The OpenSSF noted that L3 would have blocked it, but most of the ecosystem operates at L2.
The Mini Shai-Hulud worm chained pull_request_target exploitation, cache poisoning, and OIDC token extraction to publish through TanStack’s pipeline. Within hours it spread to 169 packages and 373 malicious versions, including Mistral AI’s TypeScript client. We covered the chain in the npm supply chain attacks that exposed the provenance gap. SBOMs tell you what is in your software; provenance tells you who built it. Lockfiles and release-age cooldowns help, but the attack exploited the trust boundary’s design, not a CVE.
If build-time verification can be bypassed at source, the next question is whether runtime detection catches what provenance misses.
What is Automated Moving Target Defense, and how is it different from everything EDR does?
Automated Moving Target Defense (AMTD) continuously shifts the attack surface: memory layouts, API endpoints, and runtime configs re-randomised so attackers cannot rely on static reconnaissance. ASLR randomises once at load time. AMTD re-randomises continuously, so a payload built against a snapshot taken seconds ago targets a layout that no longer exists.
EDR, exemplified by Microsoft Defender, identifies malicious behaviour then contains it. This breaks against attacks executing faster than response: Mandiant observed lateral movement beginning as little as 22 seconds after initial compromise. Before a SOC analyst finishes reading an alert, the attack has already moved. AMTD sidesteps the classification problem by making the environment unpredictable, which fileless malware and LotL techniques exploit when they abuse trusted system tools like PowerShell and WMI. Morphisec leads the category. For prevention-first security evaluation, the build-versus-buy article covers what to look for.
Detection has a gap, one that shapes the strategic decisions facing security leaders. Visibility has an even bigger one.
What is shadow AI, and how is it quietly expanding your attack surface?
Shadow AI is not just ChatGPT. It is AI-powered IDE plugins, model APIs called from dev environments, AI agents embedded in SaaS products, and automated workflows calling AI services without review. One-third of employees access AI tools via personal accounts. Each is an ungoverned exfiltration channel, injection vector, and supply chain dependency your procurement process never touched.
77% of IT managers say their AI agents are out of control. Shadow AI breaches cost $670,000 more per incident. Only 37% of organisations have detection policies despite a 68% surge in usage during 2025.
The attack surface expands three ways: data exfiltration (sensitive code, credentials, or customer data sent to external models with unknown retention policies), prompt injection (attacker-controlled content retrieved by the agent becomes instruction), and supply chain dependency (the model and its update cadence sit outside your control). The most reliable indicator of shadow AI is network traffic: model API calls to OpenAI, Anthropic, and Google endpoints from development IP ranges that do not match known projects. Unexplained API costs on departmental cards and sudden productivity spikes in specific teams, often from unauthorised Copilot or Cursor usage, are secondary signals worth watching.
Each of these failures, provenance, detection, visibility, looks like a different problem. They are not.
What is principal trust inversion, and why is it the root cause behind both supply chain and AI agent attacks?
Principal trust inversion is the architectural failure where a system treats its lowest-trust inputs as high-trust. The formal trust hierarchy runs developer, operator, user, peer-agent, supply-chain, environment. The environment, cached dependencies, retrieved documents, tool outputs, sits at the bottom. When a pipeline or agent implicitly trusts environment-level data to execute with full privileges, that hierarchy is inverted.
In Mini Shai-Hulud, the release workflow trusted a poisoned pnpm cache as if it were a legitimate dependency. In AI agent attacks, the same pattern appears: an agent retrieves a page containing a prompt injection, trusts the content as factual state, and executes attacker-specified tool calls. A survey of 116 papers found every attack at the tool execution layer reduces to this cause. Defences that skip trust-marking on inputs from lower-trust principals address symptoms, not the cause. Enclave architecture and credential substitution constrain what any input can cause, regardless of its trustworthiness.
If principal trust inversion is the diagnosis, Zero Trust for AI is the framework that operationalises the response.
Zero Trust for AI vs traditional perimeter security: what changes when AI agents become the attack surface?
Traditional Zero Trust, per NIST SP 800-207, verifies users, devices, and network requests. Zero Trust for AI must verify every agent action, tool call, and data access. An agent can chain dozens of tool calls in the time a SOC analyst reads a single alert, and detect-and-respond becomes detect-and-document.
86% of IT managers expect AI agents to outpace guardrails within a year. 68% of organisations cannot distinguish human from AI agent activity. Without attribution, accountability collapses.
The AI memory framework introduces a genuinely new attack surface. Agents need persistent state to function across sessions, but that memory becomes a target for poisoning (injecting malicious context that alters future behaviour in a different session) and extraction (exfiltrating accumulated sensitive data from the agent’s accumulated context). Temporal escalation attacks exploit this: a payload injected in one session writes to memory and is exploited in a future session, with no single session containing both injection and exploitation.
Control categories that matter: agent identity and scoping matters because shared API keys make attribution impossible. Tool-use authorisation matters because an agent’s reach, not its intent, determines the blast radius of a compromise. Memory isolation matters because cross-session attacks bypass per-session inspection. Human-in-the-loop for destructive operations matters because code pushes and production data access should never be fully autonomous. Microsoft extended Zero Trust across the AI lifecycle at RSAC 2026. The LLM firewall market’s projected growth from $1.20B to $14.17B by 2035 signals how seriously the market is betting on AI-specific controls, and how far the product landscape has to go.
With provenance, detection, perimeter, and agent governance each carrying a known gap, the question becomes what to build around them.
What does a layered defence architecture look like when provenance, detection, and perimeter controls all have known gaps?
The layered defence rests on assumed breach at every layer. No single layer suffices; each covers the failure modes of the others. Provenance catches build-chain tampering but not source malice. AMTD prevents reconnaissance-dependent attacks but not data exfiltration through legitimate channels. Zero Trust for AI governs agent actions but requires visibility into what agents exist. Shadow AI discovery provides that visibility but does not, by itself, prevent anything.
The four layers: build-time integrity (SLSA verification with builder identity enforcement, release-age cooldowns, lockfiles) for artifact-level risks. Runtime prevention (AMTD, memory isolation, enclave architecture) for attacks that bypass build-time controls. Agent governance (Zero Trust for AI, credential substitution, tool-use authorisation) for the attack surface AI agents introduce. Visibility (shadow AI detection, cross-session auditing) for the blind spots where what you cannot see, you cannot govern.
The four-layer stack is an architectural stance, not a product. No single vendor covers all four. The market is building toward this model, Morphisec in AMTD and Microsoft extending Zero Trust to AI, but integration across layers remains the defining challenge. Build-versus-buy decisions sit in the decisions that matter in the AI cybersecurity arms race.
The provenance attestation on that TanStack package was the system working exactly as designed, and the design was wrong. That distinction is the whole point. The principle that unifies the architecture: never let environment-level data execute with principal-level authority. Enforce that at every layer and you have addressed the root cause. For how these architectures fit into the broader arms race and budget constraints, the pillar page ties it together.
Frequently Asked Questions
If SLSA provenance does not guarantee safety, what value does it actually provide?
Provenance gives you a cryptographically verifiable answer to “who built this, from what source, using which workflow?” That is not the same as “is this safe?” but it is the foundation for every subsequent security decision. Without provenance, you cannot enforce builder identity policies, audit your supply chain, or implement release-age cooldowns. Provenance is necessary infrastructure; it was just never designed to detect a compromised maintainer.
How is AMTD different from existing runtime protection like ASLR and DEP?
ASLR randomises memory layout once at load time, and DEP marks memory regions as non-executable. Both are static: once set, they do not change. AMTD re-randomises the attack surface continuously during execution, so a payload built against a memory snapshot taken seconds ago is already targeting a layout that no longer exists. The difference is the difference between a locked door and a door that keeps moving.
What is the first step to discovering shadow AI in my organisation?
Start with your network traffic, not your asset inventory. Look for model API calls to OpenAI, Anthropic, and Google endpoints originating from development IP ranges that do not match known projects. Cross-reference those with departmental credit card charges for AI subscriptions. Unexplained API costs and sudden productivity spikes in specific teams are the two most reliable indicators that shadow AI is already running.
Which AI security controls should I implement first with a limited budget?
Begin with shadow AI discovery and agent governance, not detection tooling. You cannot defend what you cannot see, and you cannot govern agents whose existence you have not acknowledged. A network-level audit of model API traffic costs nothing but time and reveals the attack surface. Follow that with tool-use authorisation for any sanctioned AI agents: constrain what they can call, not whether they look suspicious while calling it.
Is shadow AI just employees using ChatGPT?
No. ChatGPT subscriptions are the visible tip of a much larger problem. Shadow AI includes IDE plugins like Copilot and Cursor, model APIs called directly from development environments, AI agents embedded in SaaS products without security review, and automated workflows that call AI services as part of their execution. Each of these is an ungoverned data exfiltration channel, a prompt injection vector, and a supply chain dependency your procurement process never touched.
Does SLSA Build Level 3 solve the provenance gap for malicious maintainers?
No. Build Level 3 adds platform isolation (no cross-build cache poisoning, no build access to signing keys), which closes the Mini Shai-Hulud attack vector but does nothing about a maintainer who intentionally publishes malicious source code. L3 proves the build was tamper-free; it does not prove the source was benign. The gap between build integrity and source integrity remains structural, not technical.
Are SBOMs redundant if you already verify SLSA provenance?
No. An SBOM tells you what is in your software; provenance tells you who built it and how. These answer different questions and cover different failure modes. An SBOM lets you identify whether a known-vulnerable library is present, which provenance alone cannot. Provenance lets you enforce that only authorised builders produced your artifacts, which an SBOM alone cannot. Both are necessary; neither is sufficient.
What makes an AI agent attack different from traditional malware in practice?
Speed and autonomy. Traditional malware relies on pre-scripted behaviour that detection tools can fingerprint. An AI agent attack chains decisions in real time: it retrieves context, evaluates options, and executes tool calls at machine speed. A SOC analyst reading one alert might miss fifty agent actions that already completed. The attack surface also shifts: the agent’s memory, tool permissions, and retrieved context are all attacker-influenceable, and none of them looks like traditional malware.
How do I know if my CI/CD pipeline is vulnerable to cache poisoning?
Check whether your build workflows share a persistent cache across pull request builds from forked repositories. If a pull_request_target workflow writes to a cache that subsequent builds read without validation, the pipeline is vulnerable. The Mini Shai-Hulud worm exploited exactly this pattern: a poisoned pnpm cache populated during one build was consumed by a release workflow that trusted it implicitly. Segregate caches by trust level or disable cache sharing across trust boundaries.
Can AMTD stop threats that are not memory-based, like data exfiltration?
No, and this is the point. AMTD prevents execution of attacks that rely on static reconnaissance of the target environment. It does not address an authorised user or process exfiltrating data through legitimate channels. That is why AMTD is one layer in a four-layer stack, not a standalone solution. Data exfiltration governance sits in the agent governance and visibility layers: credential substitution, tool-use authorisation, and cross-session auditing catch what AMTD was never designed to.
