MCP instruction supply chains are creating new AI security risk

At a glance

What this is: Island’s research shows that MCP tool descriptions and runtime text can act as instruction-bearing inputs, creating a second supply chain that can steer AI agents without malicious code.

Why it matters: IAM and security teams need to govern what agents are allowed to infer, call, and trust because instruction poisoning can bypass package-centric controls and expand NHI risk.

By the numbers:

• 49% of server builds produced at least one non-informational finding in our scan, after excluding benign inventory markers.
• In 40.6% of builds, at least one tool appeared capable of accessing files or credentials, executing code, or taking destructive actions.
• 7.8% matched at least one execution rule, including taint-reachable injection paths, shell or subprocess calls, unsafe deserialization, and distinctive reverse-shell patterns.

👉 Read Island's analysis of MCP instruction supply chains and AI agent risk

Context

MCP security is now an access-governance problem as much as a software-supply-chain problem. The critical issue is not just whether a server contains malicious code, but whether its declared text, tool descriptions, and returned output can shape model decisions in ways traditional scanning does not assess.

This matters to NHI governance because AI agents increasingly behave like non-human identities with delegated access and decision rights. If a tool can influence the agent through plain English, then approval, least privilege, and runtime monitoring all need to extend beyond executable artefacts into instruction-bearing metadata.

Key questions

Q: What breaks when MCP tool descriptions can influence AI agents?

A: Package-centric review breaks down because the risky behaviour may live in plain-English metadata rather than executable code. When an agent treats descriptions or returned text as guidance, an attacker can steer tool choice, data handling, or downstream actions without a traditional vulnerability. The control gap is at the model boundary, not just the package boundary.

Q: Why do AI assistants create a new trust problem for identity governance?

A: AI assistants create a new trust problem because they can read data, choose tools, and act on external text in ways traditional review processes do not expect. Identity governance has to account for action promotion, provenance, and egress, not only authentication or entitlement assignment.

Q: What do security teams get wrong about shadow MCP servers?

A: They often treat them as developer convenience rather than identity-bearing infrastructure. In reality, local MCP servers can have full filesystem and system privileges while escaping central visibility. That makes them an unmanaged perimeter, so discovery, owner assignment, and policy enforcement have to extend to endpoints as well as platforms.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why MCP creates an instruction supply chain

MCP separates the thing that does work from the text that describes it, but AI models do not always treat that boundary as hard. Tool descriptions, prompt templates, and returned output can enter the model context and influence what it decides to call next. That makes natural language part of the trust surface, not just documentation. In practice, a server can carry instructions that are not code, yet still alter agent behaviour if the host exposes them and the model follows them. This is why package signatures, CVE checks, and license review are insufficient on their own.

Practical implication: review declared MCP text as an input channel and not merely as metadata.

How runtime output becomes a control bypass

The second risk is post-call manipulation. Even if a tool is legitimate at install time, its output can contain hidden instructions, deceptive formatting, or text that nudges the model into unsafe follow-on actions. That shifts the problem from static artefact trust to runtime trust. Security teams should think of the agent as reading untrusted content after every tool invocation, because the model may not reliably separate data from instruction. This is especially relevant where tools can access files, credentials, or internal systems, because the cost of one mistaken interpretation can be high.

Practical implication: validate and constrain tool output before it re-enters the agent context.

Why package-level review does not cover MCP risk

Classic supply-chain checks assume the dependency itself is the security object. MCP breaks that assumption because the dependency may be safe code while its declared instructions are unsafe, or vice versa. A clean release history, trusted publisher, or valid signature tells you little about whether the tool should be exposed to a model with authority to act. This creates a control gap between installation approval and behavioural approval. The right mental model is capability governance: what the tool can reach, what it can tell the model, and what the model is allowed to do with that instruction.

Practical implication: pair package review with capability scoping and runtime policy enforcement.

Threat narrative

Attacker objective: The attacker wants to steer an AI agent into making unsafe tool calls, exposing sensitive data, or carrying out actions that appear authorised to the model but not to the user.

1. Entry occurs when an MCP server is published with trusted-looking metadata, a clean package history, or plain-English instructions that are exposed to the model at discovery or tool selection time.
2. Escalation happens when the model treats descriptions or returned text as guidance and the host allows the tool to access files, credentials, or other sensitive capabilities.
3. Impact follows when the agent takes an unsafe action, leaks sensitive context, or executes a request the user never intended, without any malicious binary being present.

NHI Mgmt Group analysis

Instruction-bearing metadata is now part of the identity perimeter for agents. MCP turns tool descriptions and returned text into governance-relevant inputs because they can influence how an agent decides and acts. That means the boundary of trust is no longer just the server binary or package hash. For identity teams, the practical conclusion is clear: if the agent has delegated authority, the text it consumes must be treated as potentially privileged instruction.

Capability scoping matters more than package reputation. A clean publisher, signed release, or popular registry entry does not tell you whether a tool can read credentials, reach the network, or manipulate context. This is a classic permission problem in a new form. The right control question is not whether the package looks trustworthy, but whether the action the model can take is constrained to the minimum required by the task.

Blind trust in tool descriptions creates a new governance gap. The article shows that some of the most consequential findings are written in plain English, not embedded in exploit code. That creates a named risk we can call instruction supply chain exposure: unsafe model guidance delivered through declared metadata and runtime output. Security leaders should treat this as a policy, review, and monitoring problem, not a scanning problem.

MCP governance should align with NHI lifecycle controls, not software-only controls. Agent access needs approval, scoping, continuous review, and revocation just like any other high-risk non-human identity. OWASP NHI Top 10 and the OWASP Agentic AI Top 10 both map well here because they capture secret exposure, tool misuse, and instruction poisoning as governance failures. Practitioners should move to runtime authorisation and not rely on install-time trust alone.

The market is moving toward agent control planes, not isolated point tools. This research signals that discovery, approval, configuration, and runtime monitoring now belong in the same governance model. Teams that keep separating software supply chain, IAM, and agent safety will miss the combined failure mode. The practical outcome is a stronger need for policy enforcement that follows the agent across tool selection, execution, and output handling.

What this signals

Instruction supply chain exposure is now a practical governance concern for any team approving MCP-based agents. If a tool can influence model behaviour through descriptions or output, then the control surface extends into content review, runtime policy, and access scoping. That is exactly where agent governance starts to overlap with NHI management and the OWASP Agentic AI Top 10.

The operational signal for practitioners is to stop treating agent approval as a one-time software review. Runtime authorisation, continuous revalidation, and output monitoring need to sit beside least privilege and access review, particularly when agents can reach files, credentials, or internal services.

Teams should also prepare for broader standardisation around agent control planes, because point controls will not be enough once discovery, installation, and execution are all part of the same risk chain. The practical next step is to align agent governance with established identity controls and with external guidance such as the OWASP Top 10 for Agentic Applications 2026.

For practitioners

• Treat MCP descriptions as untrusted inputs Review tool descriptions, prompt templates, and returned text as if they were user-supplied content. Block or rewrite instruction-like phrases that can change agent behaviour, especially where the tool has access to files, credentials, or internal systems.
• Scope tool permissions by capability, not by package reputation Separate read, write, network, and execution capabilities into distinct approval paths. A package that can only retrieve information should not inherit the same approval as one that can execute commands or access secrets.
• Revalidate every MCP version and configuration change Treat version bumps and config edits as permission changes, not routine updates. Rescan after every release because a safe-looking server can become unsafe in a later version or through a configuration swap.
• Monitor what agents actually call and return Log tool selection, tool output, and follow-on actions so you can spot instruction poisoning at runtime. Static review can miss a malicious instruction that only appears after the agent invokes the tool.
• Align agent governance with NHI controls Apply least privilege, approval, revocation, and access review to AI agents as delegated identities. Where the agent can reach sensitive systems, use policy gates and runtime authorisation before the next tool call.

Key takeaways

• MCP changes the security problem from code-only trust to instruction-bearing trust, which conventional scanning does not fully cover.
• Island’s scan of 33,563 MCP server builds shows that risky behaviour is common enough to require governance at discovery, approval, and runtime, not just at install time.
• Teams should govern AI agents like delegated identities, with capability scoping, instruction review, and continuous monitoring across the full tool lifecycle.

Key terms

• MCP instruction supply chain: The instruction supply chain is the path by which plain language, tool descriptions, prompts, and returned text influence what an AI agent does. It is different from the code supply chain because the risky material may be natural language rather than executable software, yet still change agent behaviour.
• Instruction poisoning: Instruction poisoning is the insertion of hidden or misleading directives into content that an AI system may treat as guidance. In MCP environments, that content can live in descriptions, prompts, or tool output, creating unsafe behaviour without a malicious binary being present.
• Tool output manipulation: Tool output manipulation is the use of crafted return text, formatting, or embedded instructions to alter what an AI agent or human operator believes is happening. It matters because the model may react to output as context, while the human may miss the manipulation entirely.
• Capability scoping: Capability scoping is the practice of limiting what a tool or agent can read, modify, execute, or reach. In MCP governance, it is the control that turns a broad approval into a narrow one by separating informational access from command, network, and secret-bearing actions.

What's in the full report

Island's full research covers the operational detail this post intentionally leaves for the source:

• The full scanner methodology used to evaluate 33,563 published MCP server builds and classify execution, exposure, and manipulation signals.
• Examples of tool-description poisoning and runtime instruction patterns that are easier to verify in the source than in a summary.
• The detailed breakdown of network exposure, unauthenticated access markers, and command-execution primitives across the sample.
• The discussion of how approval, configuration, and runtime monitoring should be combined into a single agent control plane.

👉 The full Island post covers scan methodology, exposure patterns, and control recommendations in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners translate identity control principles into policies for delegated systems and agentic environments.