MCP instruction supply chains are creating new AI security risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Island's research: MCP server descriptions and returned text can steer AI agent behaviour, creating an instruction supply chain that sits alongside ordinary code risk.

Why it matters: IAM and AI security teams need to treat MCP metadata as part of the control surface because approval, tool exposure, and runtime context can all change what an agent does.

By the numbers:

• 49% of server builds produced at least one non-informational finding in Island’s scan.
• 40.6% of builds included at least one tool that appeared capable of accessing files or credentials, executing code, or taking destructive actions.

Context

MCP extends tool access for AI agents, but it also extends the trust boundary. The issue is not only whether a server can execute code; it is whether the server can shape model behaviour through descriptions, prompt text, and returned output that the model may treat as guidance.

This matters because conventional dependency review is built for code provenance, known vulnerabilities, and package integrity. MCP adds an instruction layer that sits closer to agent governance, so security teams have to review what a tool is allowed to say to the model as well as what it can technically do.

For organisations adopting agentic AI, the governance problem is similar to identity sprawl in another form: there may be a clean software package on the surface, but the operational authority sits in metadata, runtime context, and approval pathways. That makes the starting position common, not exceptional, for early MCP deployments.

Key questions

Q: What breaks when MCP tool descriptions are treated as harmless documentation?

A: Security teams miss a second instruction channel that can steer the model even when the package is clean. The tool may be safe code but unsafe guidance, which means code scanning alone cannot tell you whether the agent will be manipulated. Review has to include metadata, output text, and the model’s runtime decision path.

Q: Why do plain-English MCP instructions create governance risk for AI agents?

A: Because the model may treat descriptive text as operational guidance once the host exposes the tool and the agent calls it. That means access control is no longer only about who can install software. It is also about who can place instructions into the model’s context and what the agent is authorised to act on.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Should organisations treat MCP approvals as a security control or a usability choice?

A: Security control. Approvals determine which tools an AI system can reach, which actions it can trigger, and how quickly damage can spread if a token is misused. If approvals are broad or permanent, they become standing delegation for the agent, so they should be governed like privileged access.

Technical breakdown

How MCP descriptions become part of the model context

Model Context Protocol separates tools, prompts, and returned content, but the agent does not always treat those boundaries the way a human reviewer would. A tool description can be injected into model context before the call, and a tool’s output can also be reintroduced after execution. If either contains directive language, the model may interpret it as guidance rather than documentation. That is why ordinary software review misses the risk: the dangerous content is not always executable code, it can be plain English wrapped in metadata or runtime output.

Practical implication: review MCP metadata and tool output as security-relevant input, not just as descriptive text.

Why instruction supply chains differ from code supply chains

Traditional supply-chain controls focus on whether a package is malicious, vulnerable, or counterfeit. In MCP, that remains necessary but insufficient because a dependency can be syntactically clean and still carry hidden operational instructions. This creates a second trust path. The host decides whether to expose the tool, the model decides whether to follow the instruction, and the runtime result may reinforce the instruction after the call. Security teams therefore have to reason about provenance, content, and runtime behaviour together, not as separate reviews.

Practical implication: extend supplier review to cover declared instructions, not only package signatures and known CVEs.

Where runtime approval becomes the real control point

MCP risk only becomes actionable when the host exposes a tool, the agent selects it, and the model accepts the instruction or output. That means the decisive control point is runtime approval, not installation alone. Static analysis can identify dangerous primitives, exposed listeners, or suspicious descriptions, but it cannot tell you whether a natural-language instruction will be followed in a specific session. For agent governance, this shifts the control model toward per-action authorisation, scoped capability exposure, and monitoring of what tools actually return.

Practical implication: gate high-risk MCP actions at call time and log the tool response that influenced the agent.

Threat narrative

Attacker objective: The attacker wants the agent to follow hidden instructions embedded in MCP metadata so that it performs unintended actions under apparently legitimate tool use.

1. Entry occurs when a published MCP server is exposed to an agent through discovery, installation, or approval, often before security teams have a mature review process.
2. Credential or behaviour steering occurs when plain-English tool descriptions or returned text carry covert instructions that the model may treat as guidance.
3. Impact occurs when the agent follows the hidden instruction and takes an action the user did not intend, such as suppressing visibility or changing what is logged.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• 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.

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 instruction supply chain is now a governance problem, not just a code problem: the article shows that a tool can be technically safe and still manipulate an agent through plain-English metadata. That changes the control objective from scanning packages to governing what a model is exposed to at discovery, approval, and execution. For identity and AI teams, the key point is that authority is being exercised through context, not only through executable code. Practitioners should treat tool descriptions and return values as policy-bearing inputs.

Approval without runtime control is not durable trust: the article’s core lesson is that one-time review does not establish continuing safety once the agent can call tools dynamically. That is the same governance failure pattern seen in other identity domains when standing access outlives the decision that granted it. The named concept here is instruction supply chain risk, meaning the hidden control influence carried in MCP metadata and responses. Security teams need revocable, session-aware control rather than install-time optimism.

Conventional software scanning underestimates agentic abuse paths: CVE checks, license checks, and package reputation are necessary, but they do not answer whether a server can steer a model’s decisions. This creates a blind spot at the intersection of NHI governance and agentic AI security because the object being governed is not only a package, but also the instructions that package can present to the model. Practitioners should expand review to the full agent control plane.

Agent governance now needs a separation between capability and instruction: MCP tools can be powerful without being obviously malicious, which makes capability-based allowlists incomplete on their own. The better control question is whether the tool is authorised to expose instructions, not just whether it is authorised to run. That aligns with emerging agentic AI security models and with NHI-style lifecycle control over non-human access. Teams should redesign approvals around what an agent is allowed to know and do.

Discovery, installation, and runtime are one chain of risk: the article usefully collapses the false comfort that risk begins only after code execution. The discovery layer can already be manipulated by lookalike repositories and persuasive READMEs, while runtime can be manipulated by tool output. The broader governance implication is that agent security has to span inventory, approval, and session-level monitoring. Practitioners should manage MCP like a live trust relationship, not a static dependency.

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.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Instruction supply chain risk: MCP governance now has to account for what a tool can tell the model, not only what the code can execute. That shifts the control problem from package review to context review, where descriptions, prompts, and returned text become policy-bearing inputs.

Static scanning remains useful for code-level exposure, but it cannot fully decide whether an instruction will be followed in a live agent session. The control that matters is whether the host can separate tool capability from tool guidance before the agent acts.

MCP creates a control-plane problem for AI security teams because approval is no longer a one-time installation event. The operating model has to include discovery, policy review, runtime logging, and revocation when tool behaviour changes.

For practitioners

• Inspect tool descriptions before approval Review MCP tool descriptions, prompts, and returned text for directive language that could steer the model, not just for code defects.
• Gate high-risk tools at runtime Require session-level authorisation for tools that can read sensitive data, execute commands, or alter logs, and revoke access after each approved action.
• Rescan every MCP version change Treat each MCP update as a fresh trust decision because a later release can introduce covert instructions or new execution capability.
• Separate capability from instruction exposure Do not allow a tool to both influence the model and reach sensitive systems unless the business case justifies both dimensions together.
• Monitor tool outputs for behavioural steering Log the response text that the agent sees, not only the command it sent, so hidden instructions in returned content can be investigated.

Key takeaways

• MCP changes the threat model by adding an instruction layer to supply-chain risk, not just a code layer.
• The practical failure is a governance one: package review alone cannot tell teams what an agent was allowed to read, infer, or obey.
• Security teams need runtime control, metadata inspection, and session-scoped authorisation if they want to govern MCP safely.

Key terms

• Instruction Supply Chain: The ecosystem of files, marketplaces, dependencies, and publishers that deliver agent instructions into production workflows. Like software supply chains, it can carry hidden risk through unreviewed sources, weak provenance, and altered dependencies. For agentic systems, the instruction chain can be as important as the code chain.
• 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 Approval: Runtime approval is a control that pauses a sensitive AI agent action until a human confirms it. It is used when the agent is about to make destructive or high-risk changes, such as altering code, modifying data, or touching production systems. The control reduces automation risk without removing the agent’s usefulness.
• Configuration Exposure: Configuration exposure is the unintended disclosure of system settings, secrets, or environment details through an API, file, or diagnostic endpoint. Attackers use that information to understand the environment, steal credentials, and plan follow-on access. The risk is especially high when plaintext secrets appear in web-accessible output.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners translate identity controls into practical governance for agents, tools, and ephemeral access.