Agentic supply chain security is now part of identity governance

At a glance

What this is: This is an analysis of agentic supply chain vulnerabilities, showing that runtime tool trust has become part of the identity problem for AI agents.

Why it matters: It matters because IAM, NHI, and autonomous governance teams now have to verify not only who the actor is, but which tools it can trust, call, and mutate at runtime.

By the numbers:

• The official MCP Registry launched in September 2025 and reached nearly 2,000 entries within months.
• Between January and February of 2026, security researchers filed roughly 30 CVEs against MCP servers, clients, and infrastructure.

👉 Read WorkOS' analysis of securing agentic app supply chains

Context

Agentic supply chain risk starts when an AI agent depends on tools that can change after approval. In this article, agentic supply chain vulnerabilities are the core issue: the agent is not just using software, it is relying on runtime tool identities, tool descriptions, hosted platforms, and transitive dependencies that can shift without a new security decision.

That creates an identity governance problem for NHI and agentic AI programmes. A tool that was safe at onboarding can become unsafe through manifest drift, hosting compromise, or a poisoned description, which means trust has to be revalidated at runtime rather than assumed from initial approval.

Key questions

Q: What breaks when AI agents trust MCP tools after a single approval?

A: A one-time approval model fails when the tool can change after trust is granted. If descriptions, schemas, or hosting conditions can mutate at runtime, the original review no longer matches the live capability. Security teams need continuous validation of the tool manifest, the hosting environment, and the agent’s allowed arguments before trust can be reused.

Q: Why do AI agents make supply chain security harder than traditional software?

A: Because the agent’s dependency chain is active at runtime, not fixed at build time. The model reads tool descriptions, selects tools dynamically, and may trust hosted infrastructure that can change between approvals. That makes tool identity, tool metadata, and hosting isolation part of the security boundary, not just package versions.

Q: How do security teams know if an MCP server has drifted out of policy?

A: They compare the current tool manifest, descriptions, and schemas against a captured baseline and investigate any change. New tools, altered parameter definitions, or rewritten descriptions are governance events, not routine updates. The same is true for dependency updates that could alter the runtime trust chain.

Q: Who is accountable when a hosted MCP platform exposes credentials?

A: Accountability sits with both the platform owner and the organisation that chose to place sensitive credentials there. If a hosted environment concentrates many servers and secrets, a single platform flaw can become a multi-tenant incident. Governance teams should document ownership, isolation expectations, and re-approval rules for hosted tools.

Technical breakdown

Tool description poisoning and prompt injection in MCP

In MCP environments, tool descriptions are not just documentation. They are machine-readable instructions that the model uses when deciding which tool to call and how to call it. That makes the description part of the attack surface. A compromised server can hide malicious guidance inside a plausible description, steering the agent toward exfiltration, unsafe tool selection, or suppression of other tools. This is structurally different from classic software supply chain compromise because the code may remain unchanged while the natural-language interface becomes the attack vector. The failure mode is not binary compromise, but manipulated interpretation.

Practical implication: treat tool descriptions as security-relevant artefacts and revalidate them whenever a server changes.

Approve-once trust and runtime manifest drift

The article highlights a core MCP weakness: many clients approve a server once and then trust future tool definitions silently. That creates a trust gap between initial review and later runtime behaviour. A server can add a tool, change a schema, or alter a description after approval, and the client may continue as if nothing changed. In governance terms, this is a drift problem, not a discovery problem. The security decision was made at one point in time, but the operational authority persists across later states. Traditional package pinning does not solve this because the entity being trusted is live and mutable.

Practical implication: capture a baseline manifest and block unreviewed changes until they are explicitly re-approved.

Hosted MCP platforms and transitive dependency exposure

Hosted MCP platforms compress many trust relationships into one layer. You are relying on the server code, the host environment, the platform isolation model, and the dependencies underneath all at once. The Smithery path traversal example in the article shows why this matters: one platform flaw could expose credentials for thousands of hosted servers. Transitive dependency chains make the same problem worse, because a proxy or helper package may introduce remote code execution even when the server itself seems legitimate. In practice, the attack surface moves from a single package to a multi-tenant runtime trust boundary.

Practical implication: isolate third-party servers, restrict their network reach, and review the hosting layer as part of the access decision.

Threat narrative

Attacker objective: The attacker wants to turn trusted agent tooling into a covert data-exfiltration and credential-abuse channel.

1. Entry begins when a developer installs a lookalike MCP server or remote proxy that appears legitimate but is designed to alter tool behaviour at runtime.
2. Credential access or abuse occurs when poisoned descriptions, unauthenticated connections, or a vulnerable proxy let the attacker steer the agent into leaking data, credentials, or emails.
3. Impact follows when the compromised tool chain forwards sensitive content or exposes server credentials across connected systems and tenants.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic supply chain vulnerabilities turn tool trust into an identity control, not a procurement control. Once an AI agent is allowed to select tools at runtime, the security question is no longer only whether a package is signed or a server is familiar. The question becomes whether the tool can change its behaviour after approval and still inherit trust. That is why agentic supply chain risk sits inside OWASP-AGENTIC and OWASP-NHI, not just traditional software supply chain work. Practitioners need to treat tool manifests, descriptions, and hosting boundaries as governed identity artefacts.

Approve-once trust is a broken premise for runtime agents. The idea that a reviewed tool remains the same tool was designed for static dependencies and human-paced change control. That assumption fails when the actor can reload tools, consume updated descriptions, or invoke a hosted server whose behaviour shifts after approval. The implication is not simply stronger scanning. It is that governance models built around one-time approval no longer describe the thing being governed once the agent is operating in a mutable tool chain.

Runtime tool descriptions create a named concept we should call description-level trust drift. This is the gap between what the manifest said at onboarding and what the agent reads at execution time. It matters because the model interprets text as actionable policy, so a seemingly harmless description edit can become a behavioural change. Practitioners should recognise that the control failure is not only missing validation, but the assumption that descriptive metadata is non-operational.

Hosted MCP platforms concentrate identity risk across tenants and credentials. The platform bug described in the article is not just a hosting incident. It is a governance signal that the security of one server cannot be separated from the security of the environment carrying its credentials and neighbour workloads. That aligns directly with NIST-CSF and ZT-NIST-207 thinking: isolation, verification, and blast-radius reduction must extend to the tool host itself.

Agent supply chain governance now spans identity, invocation, and infrastructure at the same time. The article shows why a single control family cannot hold the line. Identity scoping defines who may act, tool validation defines what they can call, and hosted isolation defines where those calls can safely execute. The practitioner takeaway is to govern agent supply chain risk as a layered trust problem, not a software-only review exercise.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• The same research found that 80% of organisations report AI agents have already performed actions beyond their intended scope, which makes runtime governance a present-tense control issue.
• That pattern aligns with the broader identity model in OWASP Agentic AI Top 10, where tool misuse and supply chain trust are treated as first-order agent risks.

What this signals

Description-level trust drift: the practical risk here is that a tool can remain approved while its runtime meaning changes. For teams that are already building agent workflows, that means review cadence has to move closer to execution, not just procurement or onboarding. The blind spot is not only the server, but the text the model reads to decide whether the server is safe.

With only 52% of companies able to track and audit the data their AI agents access, the governance gap is already large enough to break compliance and incident response assumptions. That is why tool identity and auditability need to sit beside secret management in programme design, not after deployment.

For practitioners building policy around agent toolchains, the next step is to separate low-risk utility servers from production-connected tools and to apply different approval paths to each. That distinction becomes more important as hosted platforms scale and as dependency chains become harder to inspect end to end.

For practitioners

• Baseline every MCP tool manifest Capture tool names, descriptions, schemas, and return types at first approval, then block any unreviewed drift until a human re-approves the change. Use the manifest hash as the comparison point and treat any new tool as untrusted until reviewed.
• Validate tool descriptions as security inputs Scan descriptions for instruction-like language, hidden exfiltration cues, and override patterns before the agent loads them. Pair that scan with manual review for high-risk servers because description changes can alter behaviour without any code change.
• Isolate third-party MCP servers by blast radius Run untrusted servers in containers or sandboxes with strict outbound network allowlists, limited filesystem access, and no inherited secrets. Reserve sensitive production connectors for self-hosted or tightly controlled environments with separate credentials.
• Audit transitive dependencies before remote connection Pin exact package versions, verify publisher identity, and re-run security scans on every update to the server stack and proxy layer. A proxy or helper package can be the real compromise point even when the MCP server itself appears legitimate.

Key takeaways

• Agentic supply chain attacks target the live tool chain, so a safe onboarding review does not guarantee safe runtime behaviour.
• The article’s evidence shows a fast-growing attack surface, with thousands of MCP servers, dozens of CVEs, and over 400,000 affected installations in one proxy case.
• Continuous manifest validation, sandboxing, and transitive dependency review are the controls that reduce the blast radius of compromised agent tools.

Key terms

• Agentic Supply Chain Vulnerability: A weakness in the tools, registries, hosts, or dependencies that an AI agent relies on at runtime. Unlike a normal build-time dependency issue, this class of risk can change after approval because the agent continuously consumes live tool metadata and remote services.
• Tool Manifest: The structured record of an MCP server’s tools, including names, descriptions, schemas, and return types. In practice, it is the baseline an organisation should compare against to detect drift, hidden changes, or unauthorised additions before an agent is allowed to trust the server again.
• Description-level Trust Drift: The gap that appears when a tool’s natural-language description changes after initial approval, altering how the model interprets the tool without changing the code. For agentic systems, this is a security-relevant behaviour change, not a documentation update.
• Hosted Tool Isolation: The practice of separating an externally hosted agent tool from other systems through network limits, filesystem restriction, and scoped credentials. It reduces the blast radius when a third-party server, platform, or dependency is compromised.

Deepen your knowledge

Agentic supply chain vulnerabilities and tool trust review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI agents that depend on mutable tools, it is worth exploring.

This post draws on content published by WorkOS: Securing agentic apps: How to vet the tools your AI agents depend on. Read the original.