Prompt injection becomes an execution-control problem in MCP

At a glance

What this is: This analysis argues that MCP turns prompt injection from a language problem into an execution-control problem when agents can call tools.

Why it matters: IAM, NHI, and agentic AI teams need to treat tool access, approval, and auditability as identity controls, because poisoned context can become privileged action.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Unosecur's analysis of MCP prompt injection and tool-enabled execution risk

Context

Prompt injection in MCP matters because the model is no longer only generating text, it is deciding whether to invoke tools that can change state, move data, or trigger downstream workflows. For identity teams, that shifts the problem from prompt hygiene to execution governance, because the dangerous moment is the tool call, not the sentence that caused it.

MCP standardizes how models discover and call tools, but that standardization also expands the blast radius when untrusted content reaches the model. The practical identity question is whether the agent can be prevented from turning hostile instructions into authenticated actions, especially when tool permissions, secrets, and approval gates are all in play.

The article's starting position is typical of modern agent deployments: the model, the tools, and the trust boundary are being connected faster than governance is being designed. That is exactly where NHI and agentic AI control gaps start to show up.

Key questions

Q: How should security teams implement least privilege for AI agents and NHIs?

A: Start by treating AI agents as a separate identity class with explicit ownership, purpose, and lifecycle records. Assign the minimum permissions needed for a specific task, use time-bounded access where possible, and require validation before elevation. The goal is to make privilege narrow enough that compromise, misuse, or drift has a limited blast radius.

Q: Why do AI agents make prompt injection more dangerous than chat-only tools?

A: AI agents are more dangerous because they can act, not just generate text. When a model can invoke tools, access records, or send messages, a hidden instruction can become a real enterprise action. The risk rises sharply if the agent inherits broad NHI permissions instead of narrowly scoped access.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

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 prompt injection changes once tools are available

Prompt injection is usually described as instruction hijacking, but in an MCP environment it becomes execution steering. The model receives untrusted text from webpages, tickets, emails, tool descriptions, or returned content, then uses that text to choose the next action. If the agent can read, write, query, or transmit data, the injected instruction can cross the boundary from context into execution. That is why the problem is not just model alignment. It is whether a model can be tricked into exercising privileges it already has through tools that were meant to be authoritative.

Practical implication: separate reasoning from execution by constraining which tools an agent can invoke and under what conditions.

How MCP tool poisoning and shadowing work

MCP exposes tool names, descriptions, schemas, parameters, and returned results to the client, and any of those fields can carry attacker influence. Tool poisoning places malicious instructions in metadata or output so later model decisions are biased. Tool shadowing uses one compromised or malicious tool to distort the model's understanding of another trusted tool. Rug pulls are more dangerous because the tool changes after approval, which breaks the user's original trust decision. In identity terms, the protocol can preserve a valid session while the trust posture underneath it has shifted.

Practical implication: monitor tool definitions and tool behavior changes after approval, not only authentication events.

Why least privilege and execution-layer authorization are the real control plane

Prompt filtering alone is weak because it assumes the model will consistently obey instructions, which is exactly what injection attacks target. The control boundary has to sit outside the model, where tool access can be scoped, secrets can be withheld, and each call can be authorized independently. Execution-layer authorization matters because it evaluates the requested action before the model is allowed to make it real. That is the same governance principle identity teams use for PAM and NHI access: the power to act should be narrower than the ability to reason.

Practical implication: move approval, scoping, and logging into the execution path rather than trusting the model's own refusal behavior.

Threat narrative

Attacker objective: The attacker wants the agent to convert poisoned context into a privileged, authenticated action that produces real-world data exposure or system change.

1. Entry occurs when hostile instructions arrive through retrieved content, tool metadata, or tool output that the agent treats as trusted context.
2. Escalation occurs when the model converts that poisoned context into a tool call that reaches data, systems, or outbound channels beyond the user's intent.
3. Impact occurs when the agent performs an unauthorized action such as data exposure, account change, code execution, or external transmission through a legitimate tool path.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.

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

NHI Mgmt Group analysis

MCP prompt injection is an identity and execution problem, not a content-safety problem. Once a model can invoke tools, the security question becomes who or what is authorized to make a state-changing request. That is a familiar IAM problem, but the attacker is now shaping the request through poisoned context instead of stolen credentials. Practitioners should stop treating this as a chat moderation issue and start treating it as delegated execution with identity consequences.

Least privilege in agentic systems fails when tool trust is inherited too broadly. A summarizer, search connector, or support agent should not carry the permissions of the entire workflow just because it sits in the same session. The danger is cross-tool escalation, where a low-trust input influences a higher-privilege capability. The implication is that tool boundaries, not model prompts, must define the trust perimeter.

Execution-layer authorization is the named concept that matters here. This is the control gap that emerges when policy is applied after the model has already decided. In MCP-style workflows, authorization has to evaluate the requested action, target, and data path before the tool executes. The practical conclusion is that identity governance must move from advisory checks to enforced runtime control.

Shadow tool trust creates a new form of ambient privilege. When tool descriptions, schemas, or server behavior are not continuously validated, the agent can be manipulated into trusting a capability that no longer matches the original approval. This is the same governance failure pattern seen in stale NHI permissions, only now it is hidden inside the tool graph. Security teams should assume the tool catalog can drift faster than review cycles can detect it.

Prompt injection in MCP accelerates the convergence of agentic AI and NHI risk. The model is not the only identity subject that matters. Tool servers, tokens, outbound channels, and execution gateways all become part of the identity chain. That means practitioners need a shared governance model for human IAM, NHI controls, and agentic behavior, because the attack path moves across all three domains.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, leaving most tool estates over-broad by design.
• For the governance side of the problem, see OWASP Agentic Applications Top 10 for a broader control model around tool misuse and prompt injection.

What this signals

Execution-layer authorization will become the dividing line between manageable agent deployments and ungoverned ones. If tool calls are still approved by prompt wording or static policy alone, the organisation has no real control boundary when hostile content reaches the model.

With 96% of technology professionals already identifying AI agents as a growing security threat and 66% calling the risk immediate in our reference research, the next control maturity step is not more prompt engineering but narrower tool scope, stronger provenance checks, and decision logging that survives incident review.

The broader trend is that agentic AI is collapsing traditional separation between identity, privilege, and workflow. Teams that already run NHI programmes should use the same discipline here: verify the executor, scope the action, and record the outcome before the model can turn context into execution.

For practitioners

• Constrain tool permissions by function Give each agent only the files, APIs, commands, and destinations required for its specific task. Separate read from write, and treat deletion, code execution, financial actions, and external transmission as distinct permission classes.
• Move approval to the execution path Require action-level authorization before a tool call is executed, not after the model has already chosen it. Show the target, data involved, requested privilege, and destination so reviewers can validate the exact operation.
• Monitor tool drift and post-approval changes Track tool descriptions, schemas, server identity, and returned content for changes after trust is established. A tool that changes behavior after approval should be treated as a governance event, not a routine update.
• Keep secrets out of the agent context Store credentials in the execution gateway or broker rather than in the agent itself, and strip sensitive data from both outbound arguments and inbound responses. If the agent is hijacked, it should not hold reusable keys.
• Record the full execution chain Log tool discovery, description changes, model decisions, arguments, results, authorization outcomes, and network destinations. Without that evidence, a malicious action can look like an ordinary API call.

Key takeaways

• Prompt injection becomes materially more dangerous in MCP because tools let poisoned context produce real actions, not just bad text.
• The control failure is execution governance, especially broad tool scope, weak approval, and missing lineage between content and action.
• Identity teams should treat agent tool access as delegated privilege and enforce per-call authorization, scoped secrets, and durable audit trails.

Key terms

• Execution-Layer Authorization: A control that approves the action itself before a tool call is allowed to execute. In agentic environments, this matters more than prompt wording because the model's decision can be wrong while the surrounding control still prevents impact.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Cross-Tool Escalation: A failure mode where output from a low-trust tool steers an agent toward a higher-privilege tool or action. It often appears legitimate in logs unless the environment records tool lineage and enforces permissions at each step.
• Rugpull: A change in an MCP tool’s advertised behaviour after approval while agents continue using a cached definition. The server appears familiar, but its semantics have shifted, which means the identity and access decision made at approval time no longer matches the live system.

What's in the full article

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how MCP tool poisoning moves from untrusted content to privileged execution.
• Specific examples of tool shadowing, rug pulls, and cross-tool escalation in agent workflows.
• A practical control set for least privilege, sandboxing, and execution-layer authorization in MCP environments.
• The vendor's logging and inspection flow for tracing model decisions, arguments, and downstream actions.

👉 Unosecur's full post covers the MCP attack paths, execution controls, and detection signals in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.