Agentic supply chain security is now part of identity governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Agentic supply chain security has become an identity governance issue because AI agents now depend on runtime tools whose manifests, descriptions, hosting, and dependencies can change after approval.

Why it matters: IAM, IGA, and NHI teams need to govern not just who or what is authorised, but which tools an agent can trust at runtime and how that trust is revalidated.

By the numbers:

• The official MCP Registry launched in September 2025 and reached nearly 2,000 entries within months, while unofficial registries index over 16,000 servers.
• Between January and February of 2026, security researchers filed roughly 30 CVEs against MCP servers, clients, and infrastructure.
• A hosting platform flaw could have exposed credentials for over 3,000 hosted MCP servers.

Context

Agentic supply chain security is the problem of deciding whether an AI agent can trust the tools it calls at runtime. In this article, WorkOS shows that the control surface now extends beyond package dependencies to MCP servers, tool descriptions, hosted platforms, and transitive dependencies.

The governance gap is that many teams still approve tools once and assume they remain stable. That assumption breaks when a server can mutate its manifest, a host can expose many tenants at once, or an agent can be manipulated by poisoned tool descriptions after 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 agentic supply chain issues create security risk even when the code looks legitimate?

A: Because the attack surface includes semantics, hosting, and dependency paths, not only source code. A legitimate-looking server can still poison tool descriptions, mutate its manifest, or inherit a vulnerable proxy and expose the agent to malicious behaviour. The risk comes from what the agent believes about the tool, not just what the tool binary contains.

Q: How should security teams detect tool description poisoning in agentic systems?

A: Look for description text that reads like instructions, not capability statements, and compare every new description against a baseline. Changes in wording, scope, or parameter guidance should trigger review because they can alter model behaviour without changing the code. The key is to treat natural-language metadata as security-relevant control material.

Q: How do teams decide whether to use self-hosted or remote MCP servers?

A: Choose based on the level of control you need over credentials, logging, and system reach. Self-hosted deployments give more direct governance, while remote servers usually require stronger authentication and proxy controls. The deciding factor is not convenience alone, but whether you can enforce the same policy standard end to end.

Technical breakdown

Runtime tool trust in MCP ecosystems

MCP changes the supply chain model because the agent consumes tools at runtime, not just code at build time. A tool is not only a function endpoint, it is also a natural-language description, parameter schema, and hosting context that the LLM interprets before deciding what to call. That means a server can shift behaviour without changing the application code that invokes it. In practice, this collapses the old assumption that version pinning alone is enough to lock behaviour. The trust boundary is now the manifest, the server identity, and the runtime environment together, not any single artifact.

Practical implication: Treat tool manifests and server identity as governed runtime assets, not static documentation.

Tool description poisoning and manifest drift

Tool description poisoning works because the LLM reads descriptions as operational guidance. If a description contains hidden instructions, the model may alter its tool choice or arguments even when the tool schema itself remains valid. Manifest drift creates the same risk through legitimate updates: a tool can be modified, added, or removed after approval, and the agent may inherit that change silently if the client does not compare the current manifest with a known-good baseline. This is why approve-once trust is structurally weak in agentic environments. The issue is not merely malicious code, but mutable semantics that the agent treats as authoritative.

Practical implication: Pin manifests, diff every update, and block any tool change that has not been re-approved.

Hosting isolation and transitive dependency risk

Hosted MCP platforms concentrate risk because one bug can expose many servers and the credentials those servers hold. WorkOS cites a path traversal flaw in a hosting layer that could have exposed credentials for over 3,000 hosted servers, which is a classic tenant-isolation failure amplified by agentic reliance. Transitive dependency risk compounds this because server packages, proxies, and OAuth flows bring their own vulnerabilities into the trust chain. In agentic supply chains, the security of the host and the package tree both matter because either layer can become the compromise point for runtime tool access.

Practical implication: Isolate third-party servers, scope their credentials tightly, and review the hosting layer as part of identity governance.

Threat narrative

Attacker objective: The attacker wants the agent to treat an untrusted tool as legitimate so they can exfiltrate data, hijack actions, or reach credentials beyond the original compromise point.

1. Entry begins when a developer installs a believable MCP server or connects an agent to a hosted tool without strong identity checks or manifest validation.
2. Credential or trust abuse follows when the agent accepts a poisoned description, a changed manifest, or a vulnerable proxy flow and uses the tool with high privilege.
3. Impact occurs when the tool forwards data, executes unintended actions, or exposes credentials across connected systems and tenants.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic supply chain security is now an identity governance problem: Once an AI agent can select tools at runtime, the question is no longer only whether the agent is authorised. It is also whether the tool itself is trustworthy, mutable, and isolated. That expands governance from identity assignment to runtime trust assurance. Practitioners should treat tool provenance, manifest drift, and host tenancy as part of the access decision.

Approve-once trust is the wrong model for agentic systems: Traditional software supply chain controls assume the dependency tree is stable after release. This article shows that MCP tools can change semantics after approval through description edits, new tools, or compromised hosts. That means the old policy premise fails at runtime, not just at release time. The implication is that governance must move from one-time approval to continuous re-validation.

Tool description poisoning is a named concept worth tracking: In agentic environments, natural-language tool metadata becomes an attack surface because the model interprets it as instruction. That is a different failure mode from package tampering or API abuse. Security teams should recognise it as a semantic supply chain risk, not a conventional code integrity issue. The practitioner consequence is that content controls and manifest controls now sit together.

Hosted MCP isolation determines blast radius: A single hosting flaw can expose many servers because agents often trust the platform behind the tool as much as the tool itself. That makes tenant isolation, scoped credentials, and dependency provenance part of the same control plane. This is where agentic supply chain security converges with NHI governance: runtime privileges are only as safe as the infrastructure carrying them.

OWASP-AGENTIC and OWASP-NHI now overlap in practice: The article maps to ASI04 because the primary risk is supply chain vulnerability in an agentic system, but the control failure also matches NHI concerns around over-trusted service identities and long-lived tool access. That overlap matters because practitioners cannot separate agent security from identity security once tools are acting as privileged runtime dependencies. The right response is a combined governance model, not a siloed one.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Agentic supply chain governance starts with runtime trust, not package hygiene: Once tools are selected at execution time, the security question shifts from what was shipped to what the model is being asked to trust right now. That makes manifest pinning, server identity, and hosting isolation part of the identity control plane.

Tool description poisoning deserves its own control category: Descriptions are no longer documentation alone when an LLM uses them to decide action. Teams need a policy for detecting semantic drift in tool metadata, because a harmless-looking wording change can be operationally equivalent to a tool replacement.

Runtime approval has to replace approve-once trust: Agentic systems need continuous revalidation because the trust boundary moves after deployment. A one-time review cannot protect a tool that can change its behavior, its dependencies, or its host between two invocations.

For practitioners

• Pin and re-approve every MCP manifest Capture the initial tool manifest as a baseline, compare every subsequent manifest against it, and block any tool addition, schema change, or description change until it is reviewed.
• Require authenticated server connections Make OAuth 2.1 authentication mandatory for remote MCP servers, and deny any server that cannot present a verifiable identity before the agent connects.
• Sandbox third-party servers Run hosted or external MCP servers with restricted outbound network access, limited filesystem exposure, and no inherited host credentials.
• Validate tool arguments at the boundary Check each agent tool call against local policy before it leaves your system, especially for email delivery, database queries, and file writes.
• Scan descriptions for hidden instructions Inspect tool descriptions for prompt-injection style language that attempts to override instructions, exfiltrate data, or suppress other tools.

Key takeaways

• Agentic supply chain attacks shift security attention from build-time dependencies to runtime tool trust, where manifests, descriptions, and hosts can all change after approval.
• The article shows that this risk is already measurable in the wild through Registry growth, CVEs, and hosting-layer exposure across thousands of servers.
• Practitioners need continuous manifest review, strict server authentication, and isolation controls if they want identity governance to keep pace with agentic tooling.

Key terms

• Agentic Supply Chain: The collection of models, tools, plugins, prompts, memory stores, and middleware that an AI agent depends on to operate. Weaknesses in this chain can introduce hidden instructions, poisoned context, or exposed secrets, so security teams need inventory, trust validation, and isolation controls across the entire path.
• 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.
• Tool description poisoning: A manipulation technique where malicious instructions are embedded in tool metadata that an agent reads before acting. The danger is that the agent may treat those instructions as trusted context, allowing unauthorized calls or data access without any obvious code change or network anomaly.
• Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.