MCP security shows why AI tools need content controls

At a glance

What this is: Lakera argues that MCP-based AI systems need content controls at the tool boundary because access to tools and data does not stop prompt injection or unsafe outputs.

Why it matters: IAM, PAM, and NHI teams need to treat AI tool execution as a governed action surface, not just an authenticated connection, because authorisation alone does not constrain model behaviour.

Context

MCP, or the Model Context Protocol, is a way for AI applications to connect models to tools, prompts, and resources. That makes the protocol useful for GenAI workflows, but it also turns context into something the system can execute, which changes the security problem from access control alone to content safety at the boundary.

Lakera's article focuses on the gap between being connected to a tool and being safe to use that tool. In MCP environments, a model can be exposed to malicious instructions embedded in content, then return unsafe or misleading output unless the input and output are screened in real time.

That makes MCP governance relevant to AI agents, but the same lesson applies to any identity programme that assumes authenticated access is enough. When a privileged runtime can act on untrusted context, the control point has to move closer to the action itself.

Key questions

Q: How should security teams handle prompt injection in AI systems?

A: Treat prompt injection as an authorisation problem, not only a content problem. Validate user input, monitor for override patterns, and block any prompt that tries to change model policy, exfiltrate data, or trigger sensitive actions. The safest design is one where untrusted prompts cannot directly reach code execution, production data, or privileged tools without policy checks.

Q: Why is access control alone not enough for AI tools connected through MCP?

A: Because the model can still process untrusted content and turn it into an unsafe action or output after access has been granted. Access control verifies who or what may connect, but it does not constrain what the model decides to do with the content it receives.

Q: What breaks when AI agents can call tools after reading untrusted content?

A: The system stops being a text processor and becomes an execution surface. If an agent can ingest poisoned context and then invoke tools with delegated privileges, the attacker can redirect control flow without direct user approval. That is why tool execution needs a separate authorization check from the model’s reasoning step.

Q: How should teams govern prompts, tools, and resources in an MCP deployment?

A: Govern them as separate execution surfaces with shared policy enforcement. Prompts, tools, and resources all need input screening, output inspection, logging, and scope review because each can become a path for prompt injection or unsafe model behaviour.

Technical breakdown

Why MCP needs boundary controls for tool execution

MCP standardises how AI applications call tools and consume external context, which is useful for orchestration but risky when the content itself is untrusted. The article's example shows an LLM summarising email with a hidden prompt attack embedded in the message body, which then influences the tool's output. This is not just classic input validation. It is a runtime control problem where the model treats retrieved content as instructions unless a policy layer inspects both input and output before execution completes.

Practical implication: screen prompts, resources, and tool inputs before the model can act on them.

Prompt injection in MCP is a content-to-action problem

Prompt injection in an MCP flow works because the model can be tricked into treating hostile text as operational context. Once that happens, the model may comply with attacker instructions while appearing to perform a legitimate task, such as summarising email or retrieving data. The article's key point is that the danger is not limited to prompt text itself. Any content that reaches a tool, prompt template, or resource can become a delivery path for malicious instructions if the system does not examine it at runtime.

Practical implication: validate both the content source and the model output, not just the authentication channel.

Why output screening matters as much as input screening

The article highlights that unsafe output can be as damaging as malicious input because the model may produce exfiltration, misleading links, or harmful instructions after processing tainted context. In MCP, the output is part of the control surface because it can trigger downstream user action or automated follow-on steps. That means the boundary must enforce policy in both directions. If screening only blocks inbound text, an attacker can still shape the final response and achieve the same harmful result through the model's own execution path.

Practical implication: apply the same policy controls to generated output that you apply to inbound context.

Threat narrative

Attacker objective: The attacker wants the model to turn hidden instructions in content into an unsafe output or data exposure through a legitimate MCP tool path.

1. Entry occurs through untrusted content delivered into an MCP-enabled workflow, such as an email containing hidden prompt text.
2. The model ingests the malicious context and uses it during tool execution, turning the hidden instruction into an active request.
3. The resulting response can expose links, data, or misleading actions that the user would not have received from a benign summary.
4. Impact is achieved when the model's output carries the attacker's intent into the workflow without any human noticing the manipulation.

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.

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

Content controls are now part of identity governance for AI tool use: MCP makes it clear that authenticated access is not the end of the control problem. Once a model can read prompts, resources, and tools, the governance question becomes what the runtime is allowed to do with that context. Practitioners should treat screening as a policy control at the action boundary, not as an optional content filter.

Model Context Protocol turns context into an executable trust surface: Traditional IAM assumes access is granted to a known actor with a known purpose. MCP breaks that assumption because the model can combine tool calls, retrieved content, and generated output in ways that were not fully predetermined at provisioning time. The implication is that least privilege for AI systems has to account for behaviour after access is already in place.

Tool-boundary screening is the right place to absorb prompt injection risk: The article's decorator pattern is less important than the governance idea behind it, which is that every prompt, resource, and tool output must pass through the same policy gate. That is the closest analogue to enforcing control at issuance time for NHI flows, except here the execution path is content-driven. Practitioners should anchor controls to the boundary where context becomes action.

MCP security is a preview of broader agentic governance pressure: As AI workflows become more capable, the industry will need controls that evaluate intent, content, and output together. This is not only an AI security issue. It is a lifecycle issue for machine and agent identities that can consume context faster than human review cycles can respond. The programme implication is to move from static access approval toward runtime policy enforcement.

Prompt injection is a named concept, but the deeper risk is executable context debt: Once organisations let untrusted content flow into model execution without inspection, they accumulate a hidden obligation to review every action the model may take. That debt cannot be resolved with access reviews alone because the harmful decision happens inside the session. Practitioners should reframe MCP governance around execution-time trust, not just access grants.

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: MCP Security Guide

What this signals

Executable context is the new control boundary: MCP-style integrations make it impossible to rely on access approval alone. Once untrusted content can influence tool execution, security teams need policy enforcement at the point where the model reads, reasons, and responds.

The practical programme shift is to treat AI tool boundaries like high-risk identity boundaries: inspect content, constrain outputs, and log the full execution path. That is especially important where prompts, resources, and tools are all exposed to the same model session.

According to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly protocol adoption can outpace governance maturity.

For practitioners

• Screen prompts and resources at the MCP boundary Inspect inbound content before it reaches the model so hidden instructions, unsafe links, and data leaks are blocked before tool execution begins.
• Add output policy checks to model responses Apply the same inspection logic to generated text so unsafe summaries, exfiltrated data, and misleading instructions do not leave the system unchecked.
• Treat tool calls as governed actions Map every MCP tool to an approval and logging policy that records what content was processed, what decision was made, and what left the session.
• Review resource exposure paths Inventory which resources, prompts, and connected data sources can be reached through MCP and remove any that do not need model access.

Key takeaways

• MCP expands what AI systems can do, but it also creates a control gap when untrusted content becomes executable context.
• The article's example shows that prompt injection can alter model output even when the tool path looks legitimate.
• The limiting factor is not authentication alone but runtime policy at the boundary where the model reads and acts.

Key terms

• MCP Boundary: The control point where an AI client reaches external tools through Model Context Protocol. It is where identity, authorisation, and logging need to be enforced so that downstream systems do not receive uncontrolled or untraceable requests.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Workflow Execution Policy: Rules that decide which events, actors, and repositories may trigger automation and under what conditions. For CI/CD governance, it is the control that turns implicit trust in YAML and repository settings into explicit, organisation-level authorisation.
• Executable Context: Executable context is information that an AI system can treat as instruction rather than passive reference. Prompts, documents, and tool responses can all change what the system does, which means they need governance and integrity controls similar to code or privileged configuration.

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.