Back to Blog 
AI AuditsAIMCPSecurity Checklist
OWASP ASI04 Explained: Agentic Supply Chain Attacks
12 min
TL;DR
- OWASP ASI04 ("Agentic Supply Chain Vulnerabilities") is item 4 of the OWASP Top 10 for Agentic Applications, released December 9, 2025.
- It covers attacks where a third-party tool, data source, connector, or runtime dependency loaded by an AI agent is compromised, malicious, or impersonated.
- The OWASP document names MCP Impersonation as the canonical example, with the September 2025 Postmark MCP supply-chain attack cited as the worked case.
- ASI04 is the most empirically validated item in the standard — at least 8 NVD-catalogued CVEs in 2025–2026 fit cleanly inside it (Postmark,
mcp-remote, gemini-mcp-tool clones, the April 2026 official-SDK design flaw). - Defending against ASI04 requires treating every third-party tool, connector, and dependency as untrusted input: pinning versions, verifying provenance, sanitising tool descriptors, and auditing the agent's full dependency graph — not just its prompts.
What ASI04 actually says
OWASP ASI04 is the agent-specific cousin of classical software supply-chain attacks. The risk it names: an AI agent loads code, tools, data, or connectors at runtime from sources it cannot fully verify, and one of those sources is compromised. Once compromised, the malicious component can read the agent's context, inject instructions, exfiltrate data, or drive the agent toward attacker-controlled outcomes — all while the user and the agent itself believe everything is operating normally.
Three properties make ASI04 distinct from general supply-chain risk:
The trust boundary is invisible. A compromised dependency in a traditional application typically has to bridge into a sensitive subsystem (database, auth, payments) to do harm. In an agentic application the dependency is already inside the trust-bearing context — the LLM reads its descriptor, output, or schema as part of its working input.
The attack surface is non-deterministic. The agent decides which tool to call based on prompt context. An attacker who controls the descriptor of a tool the agent might reach for has weighted influence over agent behaviour without a deterministic exploit chain.
The economic incentive is high. Because AI agents are increasingly granted real-world authority — sending emails, signing transactions, executing code — a successful ASI04 compromise often yields immediate, monetisable impact rather than a foothold that needs further escalation.
Real-world ASI04 incidents
The breach record from 2025–2026 contains at least eight clean ASI04 examples. Each is documented in the MCP Breach Index 2025–2026:
MCP Impersonation: the Postmark npm trojan (September 2025)
An attacker published a trojanised version of the Postmark MCP server to npm. Organisations that installed or auto-updated the package gave the malicious server tool access on their AI agents. Every email the agent sent through the impersonated server was silently BCC'd to an attacker-controlled inbox. The OWASP doc cites this exact incident as the worked example for ASI04 — it is the canonical MCP Impersonation attack pattern, where a trojanised connector replaces a legitimate vendor.
OAuth shell injection in mcp-remote (CVE-2025-6514)
The
mcp-remote npm package handled the OAuth flow for remote MCP servers. A crafted authorization_endpoint value embedded in the OAuth metadata triggered OS command execution on the host during the connection handshake. CVSS 9.6. Any agent that initiated an OAuth flow against an attacker-controlled MCP server endpoint could be remotely exploited. This is ASI04 because the failure originates in a third-party connector loaded into the agent's runtime.The April 2026 Anthropic SDK design flaw
The most consequential ASI04 incident to date. OX Security disclosed that the official MCP SDKs (Python, TypeScript, Java, Rust) flow configuration values directly into the command line used to spawn STDIO transport child processes. An attacker who controls any configuration source — a malicious package, a manipulated registry entry, a poisoned default — controls what the agent host executes. Anthropic declined to patch, citing developer responsibility for sanitisation. The implication: ~7,000 public MCP servers built on official SDKs all carry the same architectural exposure.
Look-alike package squatting (gemini-mcp-tool, Oura clones)
Trojanised look-alike packages targeting popular MCP servers. CVE-2026-0755 covers the gemini-mcp-tool variant: command injection in
execAsync over user-supplied input. SmartLoader's Oura MCP clone was distributed in February 2026 carrying the StealC info-stealer. Both fit ASI04's "compromised connector" pattern via package-registry impersonation.Attack patterns within ASI04
The OWASP standard groups ASI04 into recognisable patterns. From the disclosed-incident record, four are consistently the entry points:
1. Connector impersonation
A malicious server presents itself as a known vendor. The agent connects through normal configuration (registry entry, package install, hosted URL) and uses the impersonator's tools while believing it is using the legitimate service. Postmark is the canonical case. Defence requires pinned package versions, signature verification, and registry allowlisting.
2. Trojanised connector updates
A formerly legitimate connector publishes a malicious update through a compromised maintainer account or build pipeline. Distinct from impersonation because the connector itself is the target. Defence requires lockfiles, manual update review for high-permission connectors, and CI build provenance attestation (e.g., SLSA, Sigstore).
3. Configuration-channel injection
Configuration values that influence agent runtime spawn behaviour are themselves a supply-chain attack surface. The April 2026 Anthropic SDK flaw is the textbook case. Defence requires treating spawn-influencing config (paths, args, env vars, working directories) as untrusted input parsed against an allowlist before execution.
4. Tool-catalog poisoning
Tools registered in an agent's tool catalog carry tool descriptors read directly into the LLM's context. A poisoned descriptor is functionally a privileged prompt injection. This pattern overlaps with ASI02 (Tool Misuse) but is rooted in supply-chain trust — the descriptor is part of what the connector ships. Defence requires sanitising descriptors before context insertion and rejecting connectors whose descriptor content drifts post-install.
Why MCP makes ASI04 worse
The Model Context Protocol turned ASI04 from a theoretical risk into a high-volume threat class within 12 months of MCP's release. Several MCP-specific properties amplify the exposure:
MCP servers ship as packages. npm, PyPI, and GitHub-hosted MCP servers inherit the full attack surface of their respective registries — typosquatting, maintainer takeover, dependency confusion. This was the path of least resistance in 2025: more MCP-related disclosures came through package ecosystems than through any other vector.
MCP servers expose privileged tools. A typical MCP server provides file I/O, shell access, browser control, or API authentication on behalf of the user. A compromised server inherits all of those privileges. There is no internal MCP-level permission boundary that limits a tool's authority below what the host grants.
MCP servers run with the host's identity. Because STDIO-transport servers are spawned by the host process, they execute with the host's UID, environment, network access, and credential store. A compromise of the server is functionally a compromise of the host's operational context.
Tool descriptors are mutable post-install. A connector that was benign when installed can become weaponised on its next response cycle. The host has no inherent mechanism to detect descriptor mutation unless it explicitly logs and diffs.
Cross-server reach. When multiple MCP servers connect to the same agent context, a compromised server can shadow or override tools from trusted servers. One bad node yields multi-server reach without further exploitation.
Detection and mitigation
Defending against ASI04 is a depth-in-defence problem. The five operational controls below cover the disclosed-incident record:
1. Pin every connector and dependency. Lockfiles for npm/PyPI. Version pinning for hosted endpoints. Reject auto-updates for connectors that hold privileged tool authority. The Postmark and gemini-mcp-tool incidents would have been blocked or contained by version pinning alone.
2. Verify provenance. Sigstore signatures, SLSA build attestations, npm/PyPI provenance metadata where available. Treat unsigned connectors as elevated risk, especially those that spawn child processes or execute shell commands.
3. Sanitise configuration channels. Every value that influences agent runtime spawn — executable path, arguments, environment variables, working directory, transport URLs — should be parsed against a strict allowlist before reaching exec. The April 2026 Anthropic SDK exposure is mitigated entirely by adding this layer.
4. Sanitise tool descriptors. Before tool descriptor content enters the LLM's context, strip known prompt-injection patterns, enforce length limits, quarantine suspicious tokens, and prefer structurally validated subsets (parameter schemas) over raw natural-language description fields. This blocks the tool poisoning overlap with ASI04.
5. Log and diff connector behaviour. Record the full connector descriptor at the moment it enters context, the full spawn invocation at process creation, and any cross-server tool override events. Diff against the previous run. Treat any drift as an active incident requiring investigation.
For Web3 and DeFi teams specifically, an additional layer applies: never grant connectors transaction-signing authority, RPC access, or wallet credentials by default. A compromised ASI04 connector with on-chain authority converts the attack from data exfiltration to direct fund loss in one step.
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.
How Zealynx audits for ASI04
A Zealynx MCP Security Audit treats ASI04 as a top-priority category, focusing on five concrete tests:
-
Dependency-graph enumeration. We map every MCP server, connector, and runtime dependency the agent loads, including transitive packages. The output is a complete picture of the agent's attack surface — a baseline most teams have never produced.
-
Provenance and version audit. For each dependency: signed/unsigned, pinned/unpinned, registry source, last-update vector. Flags any auto-updating, unsigned, or registry-impersonation-prone components.
-
Configuration sanitisation review. We enumerate every configuration value that flows into a spawn command, transport handshake, or tool invocation. Validates allowlist enforcement, schema validation, and parser safety against known injection patterns.
-
Tool-descriptor adversarial test. We submit crafted descriptors that mimic known tool poisoning and MCP Impersonation patterns. The agent's defensive layer must filter or reject them before they reach the LLM context.
-
Cross-server isolation test. With multiple MCP servers connected, we verify whether a single compromised server can shadow or override tools from trusted neighbours. This is one of the most under-tested controls in production deployments.
The deliverable is a written audit report mapping each finding to ASI04 and the relevant MCP-specific patterns, plus prioritised remediation guidance.
FAQ
1. What is OWASP ASI04 in one sentence?
OWASP ASI04 (Agentic Supply Chain Vulnerabilities) is item 4 of the OWASP Top 10 for Agentic Applications, covering attacks where a third-party tool, data source, connector, or runtime dependency loaded by an AI agent is compromised, malicious, or impersonated.
2. How is ASI04 different from a classical software supply-chain attack?
ASI04 differs from classical supply-chain attacks because the compromised dependency is loaded directly into the AI agent's trust-bearing context, where the LLM reads its descriptors, schemas, or outputs alongside the system prompt. There is no separate trust boundary the dependency must cross — the malicious component already has read access to the agent's working state, and its content can influence every subsequent reasoning step.
3. What's the canonical real-world example of ASI04?
The OWASP document explicitly cites the September 2025 Postmark MCP supply-chain attack as the canonical ASI04 example. A trojanised version of the Postmark MCP server, published to npm, BCC'd every email the agent sent through it to an attacker-controlled inbox. The pattern OWASP names for this is MCP Impersonation — a malicious server posing as a legitimate vendor.
4. Why is MCP a high-risk surface for ASI04?
MCP amplifies ASI04 risk because MCP servers ship as packages (inheriting registry-level supply-chain risks), expose privileged tools (file I/O, shell, network, credentials), run with the host's identity (so server compromise equals host compromise), have post-install mutable descriptors (benign at install can be weaponised later), and allow cross-server reach (one compromised server can shadow tools from trusted neighbours in the same agent context).
5. Are there NVD-catalogued CVEs that fit ASI04?
Yes — at least 8 NVD-catalogued CVEs from 2025–2026 fit ASI04 cleanly. Examples: CVE-2025-6514 (
mcp-remote OAuth shell injection, CVSS 9.6), CVE-2026-0755 (gemini-mcp-tool command injection, CVSS 9.8), and the April 2026 Anthropic MCP SDK design flaw (multiple CVEs, declared by-design). The complete inventory is tracked in the MCP Breach Index 2025–2026.6. What are the top mitigations for ASI04?
The top five ASI04 mitigations are: (1) pin every connector and dependency with lockfiles and version pinning; (2) verify provenance via signatures, SLSA attestations, and registry metadata; (3) sanitise configuration channels that influence runtime spawn (paths, args, env vars); (4) sanitise tool descriptors before they enter the LLM context; (5) log and diff connector behaviour at every invocation, treating drift as an incident.
7. How does ASI04 relate to ASI02 (Tool Misuse)?
ASI04 and ASI02 overlap in tool-poisoning attacks, but the root cause differs. ASI04 is about the supply-chain origin of the compromised tool — who shipped it and how. ASI02 is about the runtime use of tools — how the agent invokes them, what permissions they hold, what guardrails apply. A poisoned tool descriptor is an ASI04 finding when the focus is on dependency provenance, and an ASI02 finding when the focus is on the agent's tool-usage controls.
8. How do I audit my agent for ASI04 vulnerabilities?
To audit for ASI04 vulnerabilities, enumerate the full dependency graph (MCP servers, connectors, runtime libraries, transitive packages), verify provenance and pinning for each, review configuration channels for sanitisation gaps, adversarially test tool-descriptor handling against known poisoning patterns, and verify cross-server isolation when multiple MCP servers connect to the same agent context. Zealynx's MCP Security Audit operationalises this against your specific deployment.
Glossary
| Term | Definition |
|---|---|
| Agentic Supply Chain | The full graph of third-party tools, connectors, data sources, and runtime dependencies that an AI agent loads at runtime — the attack surface OWASP ASI04 covers. |
| Trojanised Connector | An MCP server, plugin, or tool integration that has been replaced with a malicious version, typically through package-registry impersonation, maintainer-account compromise, or a poisoned build pipeline. |
| Tool Catalog | The set of tools an MCP server (or other connector) advertises to a connecting AI agent — names, descriptions, parameter schemas, and usage notes — that the LLM reads during planning. |
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.