In May last year, someone opened a public GitHub repository and filed an issue. The issue contained instructions written for the AI assistant the repository’s owner had connected to their account. Read the user’s private repositories. Send their contents to an attacker-controlled endpoint. The MCP server bound to the user’s GitHub credentials read the issue, treated the embedded text as a command and walked the user’s data out the door.
No malware. No exploit code. The repository was not compromised. The infrastructure was not compromised. The agent had the user’s authority and the issue had no provenance, and that was enough.
This is the new shape of supply chain compromise in agent systems. It is not the npm story repeated. It is a structural step worse, because the agent is not just running code from somewhere. It is running code as someone, with their access, on their behalf. When the components or the inputs cannot be verified, the user’s authority becomes the attack surface.
Four cases. One mechanism.
The GitHub MCP exfiltration was not the only one. The Azure MCP Server shipped with missing authentication on a critical function and hit CVSS 9.1 in April this year, disclosed as CVE-2026-32211. EchoLeak, the zero-click data exfiltration against Microsoft 365 Copilot disclosed in June 2025 as CVE-2025-32711, used hidden instructions in an email the assistant was asked to read. No user interaction. CVSS 9.3.
OpenClaw, the agent runtime that put MCP infrastructure on every developer’s desk in late 2025, ran in over twenty-one thousand exposed deployments on the public internet by spring 2026. The components ran because they existed. Few were signed. Fewer were attested.
Four cases. One mechanism. The agent is acting on behalf of the user. The things directing the agent have no traceable origin the architecture can check before they take effect.
IBM X-Force’s 2026 report records a near four-fold increase in supply chain compromises since 2020, driven by attackers exploiting trust relationships across CI/CD automation and SaaS integrations, with AI tooling accelerating the curve. OWASP catalogued the agent-specific shape of the same pattern in December 2025 in the Top 10 for Agentic Applications, as ASI04, agentic supply chain vulnerabilities. The numbers are not warning signs. They are the floor.
Vetting is not provenance.
The industry response has been to add detection. Prompt scanners. SBOMs. Vulnerability tools. Signature checks at install time. Each is a sensible operational layer. None of them close the gap, because they answer the wrong question.
Vetting asks: is this component compromised? It looks at what is known about a thing. Provenance asks: where did this thing come from, and is the path from there to here verifiable? It looks at the chain.
The two questions sound similar. They are not. A vetting tool can tell you a package has no known vulnerabilities. It cannot tell you the package you are running is the package you vetted. The difference is the gap supply chain attackers walk through.
Pharmaceutical supply chains figured this out a generation ago. Vetting a batch of pills is not the same as knowing the batch came from the manufacturer named on the label. Track-and-trace is not a quality check. It is the architecture that makes the quality check meaningful. Without provenance, vetting only tells you what is true of something whose identity you cannot verify.
AI agent infrastructure is at the pre-track-and-trace stage. The components run because they exist. The inputs are obeyed because they arrive. The architecture has not yet drawn the line between things with verifiable origin and things without it.
Authority without provenance.
If your agent has the user’s authority, your supply chain has to have the user’s trust. That sentence is the whole argument. The trust model is two-sided. Most current architectures build only one side.
The agent inherits authority from the user. Tokens, credentials, scopes, account access. That side is well-developed. OAuth flows, scoped permissions, rotation, audit. The agent operates under the user’s identity because the architecture says it can.
The components and inputs the agent acts on inherit nothing comparable. A package the agent uses, a memory store the agent reads, an issue the agent parses, a tool response the agent passes through. None come with a verifiable origin the agent can check before acting. They flow into the agent’s reasoning and out into actions taken under the user’s identity.
When the two trust models meet, the gap is the attack surface. The user is authorised. The component is not authenticated. The agent splits the difference by acting.
Build for the chain.
Provenance verification is a system property. It has to be designed in, not bolted on.
Every component the agent runs should have a verifiable signature traceable to a source the system explicitly authorises. Where the chain breaks, the component does not run. Or it runs inside a containment boundary the architecture defines, with limited authority over the user’s identity.
Memory writes need the same treatment. Memory poisoning, where an injection corrupts an agent’s long-term context and the agent then defends the false belief as correct, is supply chain compromise applied to the agent’s own state. Treat the memory write surface as code. If the input cannot be traced, it cannot be persisted at the user’s authority level.
Inputs from outside the system’s authority need a marked path. Untrusted content can be read. It cannot drive a privileged action without crossing a boundary the architecture enforces. The wider case for structural over prompt-based enforcement has been made before. The supply chain version of that case is provenance over vetting.
Quality observability sits over this as a secondary signal, not the primary defence. Statistical Process Control on agent quality scores will catch the behavioural drift that follows a poisoned memory or a compromised component. Drift detection tells you a boundary was crossed. The boundary itself, drawn by the architecture, is what keeps the blast radius bounded.
If you are evaluating an agent system, the question is one sentence. Pick a privileged action your agent can take. Trace, in the architecture, the chain of provenance for every component and input that contributes to that action. If you cannot answer where any link in that chain came from, you have a supply chain exposure no scanner is going to fix.
Architecture decides what survives.
AI does not create supply chain compromise. The npm and PyPI worlds had this problem long before agents existed. What AI changes is the consequence. A poisoned package in a build pipeline produces a defective build. A poisoned component in agent infrastructure produces an agent acting under your identity, with your access, on instructions you never gave.
Architecture is what decides whether the consequence is bounded. Vetting is necessary. Provenance is what makes it enforceable. The teams who treat that as architecture work will defend. The teams who treat it as procurement will keep being surprised by news cycles that will not stop coming.
Sources
- IBM 2026 X-Force Threat Intelligence Index — supply chain compromise rate, AI-as-attack-vector findings (February 2026).
- OWASP Top 10 for Agentic Applications — ASI04 agentic supply chain vulnerabilities (December 2025).
- GitHub MCP Exploited: Accessing private repositories via MCP — Invariant Labs disclosure of the issue-as-instruction exfiltration (May 2025).
- Inside CVE-2025-32711 (EchoLeak): Prompt injection meets AI exfiltration — Microsoft 365 Copilot zero-click, CVSS 9.3 (June 2025).
- CVE-2026-32211: Azure MCP Server Information Disclosure — missing authentication on a critical function, CVSS 9.1 (April 2026).
Leave a Reply