OWASP ASI04 Agentic Supply Chain Vulnerabilities Guide

Agents assemble their capabilities at run time from MCP servers, tool registries, skills, prompt hubs and other agents, so a single tampered component can change what every agent that loads it does. OWASP ranks this as ASI04 Agentic Supply Chain Vulnerabilities in the OWASP Top 10 for Agentic Applications, released on 9 December 2025. This guide explains what OWASP includes in the entry, how it differs from the classic software supply chain, how to turn the OWASP mitigations into enforceable requirements, and where the credentials that agent components hold fit in. It is written for AppSec, platform and AI engineering teams and for security architects who approve the tools and agents their organisation connects. For the full list, see the OWASP Top 10 for Agentic Applications Guide.

Key takeaways

The supply chain is live. OWASP stresses that agentic systems load tools, prompts and peer agents at run time, so the supply chain is not fixed at build and a change upstream reaches production without a release.
Text is now a dependency. Tool descriptions, prompt templates, agent cards and skills are read by the model as instructions, so a one-line change to a description can be as dangerous as a change to code.
Pin by content, not by name. OWASP advises pinning prompts, tools and configurations by content hash and commit ID, with staged rollout and automatic rollback, because trusted packages have been changed after adoption.
Every component carries the agent's credentials. An MCP server or skill runs with the access the agent gives it, which is why the incidents in this entry end in stolen tokens, keys and email.
Plan for a kill switch. OWASP lists the ability to revoke a tool, prompt or connection across all deployments quickly as a core mitigation, not an afterthought.

What it is and who it applies to

OWASP describes ASI04 as the risk that third-party agents, tools and related artefacts, including models, plug-ins, datasets, MCP and A2A interfaces, registries and update channels, are malicious, compromised or tampered with. The distinguishing point is timing: a conventional application fixes its dependencies at build, while an agent discovers and loads components while it runs, so compromise can cascade across agents that share them. OWASP's Appendix A maps ASI04 to LLM03 Supply Chain in the LLM Top 10 2025, to T17 Supply Chain Compromise (with overlaps into tool misuse, unexpected code execution, agent communication poisoning, rogue agents and insecure inter-agent protocol abuse) in the Agentic AI Threats and Mitigations taxonomy, and to the AIVSS core risk "Agent Supply Chain and Dependency Attacks".

It applies to anyone who installs MCP servers, agent skills or IDE extensions, pulls prompts or agents from a hub, lets agents discover other agents, or lets coding agents install packages. OWASP lists six common forms:

Poisoned prompt templates loaded remotely: an agent fetches its instructions from a location an attacker can change.
Tool-descriptor injection: hidden instructions in a tool's name, description or schema, which the model reads when deciding what to call.
Impersonation and typosquatting: a tool, package or agent named to look like a trusted one.
Vulnerable third-party agent: a remote agent that your agent delegates to is itself weak or compromised.
Compromised MCP or registry server: the server or catalogue that agents trust is altered.
Poisoned knowledge plug-in: a data source or retrieval plug-in returns manipulated content.

The OWASP scenarios, with what happened

OWASP scenario	What happened	Control that would have helped
Amazon Q supply chain compromise	A malicious prompt telling the agent to wipe local files and cloud resources was committed on 13 July 2025 and shipped in Amazon Q Developer for VS Code 1.84.0 on 17 July; AWS removed it and released 1.85.0. The root cause was an over-scoped GitHub token in the build configuration.	Least-privilege CI tokens, review before release, prompts treated as code
Malicious MCP server impersonating Postmark	The npm package postmark-mcp, unrelated to Postmark, added a hidden BCC of every email to an attacker address in version 1.0.16 on 17 September 2025, after fifteen clean versions.	Official publisher sources only, version pinning, diff review on upgrade
AgentSmith prompt-hub proxy	Noma Security showed that an agent shared on LangChain Hub could carry a proxy configuration that routed a user's OpenAI traffic, including the API key, to an attacker. LangChain added warnings; no exploitation was found.	Review of imported agent configuration, egress allowlists
Agent-in-the-middle via agent cards	SpiderLabs showed in April 2025 that a rogue agent's card description could persuade a host agent to route every task to it, exposing the user's data.	Closed agent registration, signed and reviewed agent cards
Compromised npm package auto-installed by coding agents	OWASP describes a package that coding agents installed automatically and that exfiltrated SSH keys and API tokens.	Package allowlists and sandboxed installs for agents
MCP tool descriptor poisoning	Hidden instructions in tool metadata steer the agent when it reads the tool list.	Description review, hashing and re-approval on change

Structure and key requirements

OWASP gives nine prevention and mitigation guidelines. The table paraphrases each and adds a testable requirement; the verification column is NHI Mgmt Group's.

OWASP guideline	Requirement	How to verify
Provenance, SBOMs and AI-BOMs	Components are signed and attested; an inventory of AI components (models, tools, prompts, MCP servers, datasets) is maintained	Each production agent has a current bill of materials; unsigned components are listed as exceptions
Dependency gatekeeping	Allowlisted and pinned dependencies, typosquat scanning, rejection of unsigned or unverified items	Attempt to load an unlisted MCP server; confirm it is blocked
Containment and builds	Sensitive agents run in sandboxes with strict network and syscall limits; builds are reproducible	Egress from the sandbox to a non-allowlisted host fails
Secure prompts and memory	Prompts, orchestration scripts and memory schemas are under version control with peer review	Every prompt change in production traces to a reviewed commit
Inter-agent security	Mutual authentication, no open registration, signed inter-agent messages	Register an unknown agent; confirm it cannot join
Continuous validation	Signatures, hashes and SBOMs are rechecked at run time, not only at install	Alter a tool description on the server; confirm the agent refuses it
Pinning	Prompts, tools and configurations pinned by content hash and commit ID, staged rollout, automatic rollback	Configuration references hashes or commits, not "latest"
Supply chain kill switch	Emergency revocation of a tool, prompt or connection across deployments	Timed drill disables one component everywhere
Zero-trust application design	Design assumes any LLM or agent component can fail or be exploited	Threat model shows the blast radius of each component's compromise

Build provenance standards still apply to agent components. SLSA v1.0 Build Level 2 requires signed provenance from a hosted build platform, and Level 3 adds isolation between builds and keeps signing secrets away from user-defined build steps, which limits the damage from stolen upload credentials. CycloneDX's ML-BOM format records models, datasets and their configuration and provenance. See the SLSA and Build Provenance Guide and the AI Supply Chain and AI-BOM Guide.

Identity and NHI requirements

Almost every ASI04 incident has a credential at both ends: a stolen or over-scoped publishing token lets the attacker change the component, and the component then harvests the tokens the agent gives it. OWASP's Appendix C maps four NHI Top 10 entries to ASI04: NHI1 Improper Offboarding, NHI3 Vulnerable Third-Party NHI, NHI6 Insecure Cloud Deployment Configurations and NHI9 NHI Reuse.

Publishing credentials: the Amazon Q compromise came through an over-scoped GitHub token, and the Nx s1ngularity attack began with a stolen npm publishing token. Trusted publishing with OIDC removes stored tokens; where tokens remain, scope them to one package and rotate them. See the Software Supply Chain Security Guide.
Credentials the component receives: give each MCP server or skill its own narrowly scoped credential rather than the agent's or user's broad one, so a malicious update steals little. An email-sending MCP server such as postmark-mcp sees every message the agent sends through it, so its credential and its code both need scrutiny.
Credentials the component can read: local MCP servers and skills run with the user's privileges. The MCP security best practices warn that a one-click server configuration can run arbitrary commands, and require clients to show the exact command and get consent; they recommend sandboxing with restricted file system and network access.
Third-party agents: a remote agent is a third-party NHI. Authenticate it, record who owns it, and review the scopes it is granted. See the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.

The Nx case also shows a newer twist: the malicious post-install script called locally installed AI command-line tools with permission-bypass flags to help search for secrets. Developer AI CLIs with broad file access are now part of the supply chain blast radius. See the AI Coding Agents Security Guide.

Implementation steps

Discover what agents load. Inventory MCP servers, skills, extensions, prompt sources, remote agents and packages across endpoints, CI and agent platforms, including unsanctioned ones. See the Unsanctioned AI Agents and MCP Servers Guide.
Classify by power. Rank components by what they can reach: credentials, file system, network egress, write actions. Review the most powerful first.
Set the approved source rule. Install MCP servers and skills only from the publisher's official source or an internal mirror, never from a lookalike package.
Stand up a registry or gateway. Route agent tool traffic through an MCP gateway or internal registry that holds the allowlist, pinned hashes and descriptions. See the MCP Gateway and MCP Server Governance Guide.
Pin and diff. Pin every component by hash or commit. On upgrade, diff code and tool descriptions, re-approve, then roll out to a pilot ring before everyone.
Run in monitor mode first. Log what the gateway would block for a pilot group, fix false positives, then enforce. Roll back by switching enforcement off at the gateway rather than removing the allowlist.
Sandbox and scope. Run local servers and package installs in containers with egress allowlists and no access to SSH keys, cloud profiles or browser data; give each component its own scoped credential.
Build the kill switch. Make it possible to disable a component, revoke its credentials and block its hash across all agents in one action, and drill it.

Small teams and large organisations

Small teams: keep a short written allowlist of MCP servers and skills, pin versions in configuration files kept in source control, disable automatic updates for agent components, and remove permission-bypass modes from developer AI tools.
Large organisations: centralise discovery and enforcement in a gateway, require AI-BOMs from internal teams and suppliers, add agent components to third-party risk reviews, and close open agent registration in any multi-agent platform.

Evidence and assessment

Log for every component load and call: component name, source, version and hash, the description hash, the identity that approved it, the credential it was given and the agent that used it. Alert on these events:

A tool or MCP server not on the allowlist being loaded, or a known one appearing from a new source.
A change in a tool description or schema hash without a matching approval.
A component making network connections outside its declared destinations.
Package installs initiated by an agent, especially with install scripts.
New agents registering with, or winning tasks from, an orchestrator.

Metric	What it shows	Target
Share of agent components pinned by hash or commit	Exposure to silent updates	Towards 100%
Components in use that are not on the approved list	Shadow supply chain	Towards zero
Share of production agents with a current AI-BOM	Inventory coverage	Towards 100%
Median time from upstream advisory to component disabled everywhere	Kill switch effectiveness	Hours, falling
Components holding credentials broader than their function	Blast radius if compromised	Falling each quarter

Mapping to other frameworks

Framework	Where ASI04 sits
OWASP LLM Top 10 2025	LLM03 Supply Chain, which covers third-party packages, models and adapters; ASI04 extends it to tools, prompts, registries and peer agents loaded at run time
OWASP NHI Top 10 2025	NHI1, NHI3, NHI6 and NHI9 (OWASP Appendix C)
MITRE ATLAS	AML.T0010 AI Supply Chain Compromise and AML.T0010.005 AI Agent Tool, AML.T0104 Publish Poisoned AI Agent Tool, AML.T0109 AI Supply Chain Rug Pull, AML.T0110 AI Agent Tool Poisoning, AML.T0011.002 Poisoned AI Agent Tool, AML.T0081 Modify AI Agent Configuration
MITRE ATT&CK v20	T1195.001 Compromise Software Dependencies and Development Tools, T1195.002 Compromise Software Supply Chain, T1199 Trusted Relationship
NIST SP 800-53 Rev. 5	SR-3 Supply Chain Controls and Processes, SR-4 Provenance, SR-11 Component Authenticity, CM-7 Least Functionality, CM-14 Signed Components, SI-7 Software, Firmware, and Information Integrity, SA-9 External System Services
NIST CSF 2.0	GV.SC-05 and GV.SC-07 supplier requirements and risk, ID.AM-02 software inventories, ID.RA-09 authenticity and integrity assessed before use, DE.CM-09 runtime monitoring
ISO/IEC 27001:2022 Annex A	5.19 to 5.22 supplier relationships and ICT supply chain, 8.30 Outsourced development

ATLAS AML.T0109 describes the rug pull pattern directly: publish a legitimate component, gain adoption, then push a malicious update, which is what happened with postmark-mcp. The NIST and ISO mappings are NHI Mgmt Group's.

Common pitfalls

Vetting once at adoption. The postmark-mcp malicious MCP server was clean for fifteen versions before one line added a BCC. Review must repeat on every update.
Open marketplaces treated as curated. In the ClawHub malicious skills campaign, anyone with a GitHub account at least a week old could publish OpenClaw skills; Koi Security found 341 malicious skills among 2,857 audited, with fake "prerequisite" steps delivering credential stealers.
Prompts and instructions outside code review. The Amazon Q Developer extension compromise shipped a destructive prompt because a commit reached a release without human review.
Ignoring tool descriptions. Teams review MCP server code but not the descriptions the model reads, which is where descriptor poisoning lives.
Agents installing packages freely. A coding agent that can run installs with network access and the developer's credentials turns any malicious package into a credential theft.
Open agent registration. Letting any agent publish a card to an orchestrator invites agent-in-the-middle routing.

Practitioner checklist

Inventory every MCP server, skill, extension, prompt source, remote agent and package your agents load.
Allow only approved sources and publishers; block lookalike and typosquatted names.
Pin components by content hash or commit ID and disable automatic updates.
Diff code and tool descriptions on every upgrade, re-approve, and roll out through a pilot ring.
Keep prompts, orchestration scripts and memory schemas under version control with peer review.
Run local servers and agent package installs in sandboxes with egress allowlists and no host credentials.
Give each component its own narrowly scoped credential and scope publishing tokens to one package.
Maintain an AI-BOM for each production agent and require one from suppliers.
Close open agent registration and authenticate every remote agent.
Drill the supply chain kill switch and record the time to disable a component everywhere.

OWASP Agentic Top 10 ASI04 Guide