MCP supply chain security is now an AI governance issue

At a glance

What this is: Akto argues that MCP supply chain security has become an AI governance issue because compromised tool metadata, context stores, and orchestration layers can alter model behaviour and downstream actions.

Why it matters: IAM, NHI, and AI security teams need to treat MCP components as governed identities and trust boundaries, not just integration plumbing, because tampering can change decisions without obvious compromise signals.

By the numbers:

• In 2024, over 183,000 customers were impacted by supply chain cyberattacks.

Context

MCP adds a governed interface between AI systems and external tools, data sources, and workflows, which means its security problem is not only transport or code integrity. The real risk is that trusted integration points become the place where malicious metadata, poisoned context, or rogue updates can alter what the AI sees and does.

For IAM and NHI programmes, that matters because the control question shifts from who can authenticate to what can modify the AI's decision surface over time. A protocol that expands interoperability also expands the number of lifecycle points that must be inventoried, validated, and continuously monitored.

That makes MCP supply chain security a control-governance issue, not a narrow engineering hygiene issue, and the article's starting point is typical of modern AI deployments that inherit trust from many upstream components.

Key questions

Q: What breaks when MCP tool definitions change without re-approval?

A: What breaks is the assumption that a previously trusted tool still behaves the same way. If definitions can change silently between sessions, the agent may continue using a modified capability under old approval. That undermines auditability, makes security reviews stale, and hides new malicious instructions.

Q: Why do compromised MCP components create governance risk for AI systems?

A: Because MCP components can change what the model sees, which tools it can call, and what actions it can trigger. That makes them part of the AI's authority surface, not just plumbing. If lifecycle ownership is weak, a small upstream change can produce broad downstream effects that are difficult to trace back to the source.

Q: What are the signs that MCP context poisoning is happening?

A: Look for repeated policy violations, unusual tool choices, inconsistent outputs from the same task, or context that appears to survive longer than expected. The strongest signal is behaviour that changes without a corresponding business or data change. Teams should also watch for metadata drift in retrieved sources and unexplained shifts in agent decision paths.

Q: How should organisations govern agentic AI supply chains across MCP workflows?

A: Assign ownership for every upstream component that can influence agent behaviour, then require approval, traceability, and monitoring for changes to those components. The goal is to manage delegated trust, not just application access. Governance should cover provenance, update control, runtime isolation, and offboarding of untrusted or stale integrations.

Technical breakdown

How MCP supply chains can subvert AI decisions

Model Context Protocol links an LLM or agent to external tools, data connectors, and workflows. That architecture is useful because it lets the model act on current context, but it also means the model inherits trust from every upstream component that can shape prompts, metadata, or retrieved content. If an attacker changes tool definitions, inserts malicious metadata, or poisons context stores, the model can be nudged into unsafe outputs without touching the base model itself. The failure mode is governance drift across the integration chain, not just code compromise.

Practical implication: inventory every MCP component that can influence prompts, tool selection, or context injection.

Why context poisoning is hard to detect

Context poisoning is a persistence problem. Unlike a one-time exploit, it can live inside memory, retrieved documents, or cached instructions and continue to influence later sessions. That makes the attack look like normal model behaviour unless teams verify provenance, isolate session state, and track context changes over time. For security teams, the important distinction is between transient input and durable context. Once malicious instructions are stored or reused, they become part of the AI's decision environment until explicitly removed or invalidated.

Practical implication: apply provenance checks and lifecycle controls to stored context, not just live prompts.

Why runtime auditing matters for tool definitions

Tool definitions and version updates can change what an agent is allowed to call, which credentials it uses, and what side effects it can trigger. That makes them a privileged control surface similar to a service account or automation policy. If a rogue update or manipulated package changes those definitions, the agent may still appear to be operating normally while actually executing attacker-chosen actions. Runtime auditing, sandboxing, and version pinning reduce the chance that a trusted integration layer becomes a hidden privilege escalation path.

Practical implication: treat tool version changes and definition updates as privileged changes requiring audit and approval.

Threat narrative

Attacker objective: The attacker aims to steer AI behaviour and trigger unsafe or unauthorized actions through trusted MCP pathways.

1. Entry occurs through a compromised MCP component such as a tool definition, context source, or connector that the AI trusts at runtime.
2. Credential or instruction abuse follows when malicious metadata, poisoned context, or unauthorized updates alter how the model selects tools or actions.
3. Escalation happens when the manipulated AI chain reuses that trust across sessions or workflows, extending the attacker influence beyond one interaction.
4. Impact is measured in altered decisions, unsafe actions, data exposure, or downstream workflow failure rather than a conventional host compromise.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.

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

NHI Mgmt Group analysis

MCP supply chain security is now an AI governance problem, not just a software integrity problem. The article is right to frame tool definitions, context stores, and orchestration layers as control points that can alter the behaviour of the system itself. Once AI systems consume external inputs continuously, security has to govern the lifecycle of those inputs, not only the code that delivers them. Practitioners should treat MCP trust boundaries as part of AI governance.

Context poisoning creates a durable trust failure because it survives beyond a single prompt. That makes the risk materially different from ordinary input abuse. When misleading instructions or corrupted retrieval data persist across sessions, the organisation loses visibility into where the model's decisions are coming from. The named concept here is context integrity debt: the longer polluted context remains unverified, the more downstream decisions inherit that corruption. Practitioners should audit stored context with the same seriousness they apply to privileged configuration.

The identity problem in MCP is about who or what can change the AI's authority surface. Tool publishers, connectors, and orchestration services function like non-human identities because they carry delegated trust into runtime decisions. That makes NHI governance directly relevant: if these components are not inventoried, scoped, and lifecycle-managed, AI agents can inherit privileges that were never meant to be durable. Practitioners should bring MCP components into NHI and access governance rather than leaving them in engineering-only workflows.

Runtime control is the deciding factor once tool chains become mutable. Pinning versions, sandboxing execution, and auditing changes matter because a manipulated tool definition is effectively a privilege escalation mechanism for the agent. The broader market signal is that agentic AI security is converging with supply chain control, where provenance, approval, and drift detection become primary controls. Practitioners should align AI governance with change management and runtime monitoring, not separate them.

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 Identity Guide

What this signals

MCP is creating a new class of trust boundary that sits between AI models and the data or tools they consume. Security programmes that still treat integrations as static plumbing will miss the lifecycle controls that actually determine whether a model can be steered, poisoned, or misled.

Context integrity debt: once contaminated context is stored or reused, the model's future decisions inherit that compromise until teams prove the data is clean. That pushes practitioners toward provenance, isolation, and continuous auditing rather than one-time validation.

Agentic AI governance now needs to overlap with NHI governance because the systems that publish tools, connectors, and orchestration policies are acting like delegated identities. If those non-human authorities are not inventoried and controlled, the AI inherits privileges that were never intended to persist.

For practitioners

• Map the full MCP trust chain Inventory tool definitions, connectors, context stores, update channels, and orchestration services that can influence agent behaviour. Classify each component by the level of trust it receives and the actions it can trigger.
• Apply provenance checks to context inputs Verify the origin and integrity of documents, metadata, and retrieved context before the model can reuse them in later sessions. Remove or quarantine sources that cannot be traced back to an approved owner.
• Pin and audit tool versions Treat tool definition changes and package updates as privileged events. Require approval, maintain version baselines, and log any modification that can expand agent capability or change execution behaviour.
• Isolate high-risk runtime actions Run agent-executed tools in constrained environments with explicit sandboxing, limited egress, and narrowed permissions so a compromised component cannot cascade across other workflows.
• Add continuous context auditing Monitor for abnormal tool selection, unexpected metadata changes, and reused instructions that survive across sessions. Use alerts to surface drift before it becomes accepted model behaviour.

Key takeaways

• MCP supply chain security should be treated as governance over the AI decision surface, because compromised tool and context layers can change model behaviour without touching the base model.
• The main risk is not only tampering but persistence, since poisoned context and mutable tool definitions can keep influencing later sessions after the original change is forgotten.
• Practitioners need inventory, provenance, runtime audit, and sandboxing controls for every MCP component that can alter agent authority or outputs.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• Tool-definition drift: A mismatch between the tool definition that was approved and the tool definition that is later executed. Drift can happen when descriptions, schemas, or tool lists change after onboarding, which means a prior review no longer reflects the live authorisation surface.
• Context Integrity: Context integrity is the assurance that an AI agent is operating under the correct task frame, policy boundary, and operational intent. When that integrity is broken, the agent may perform authorised-looking actions for hostile purposes. For autonomous systems, this is as important as credential protection.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.