MCP penetration testing exposes the context integrity gap in AI security

At a glance

What this is: Akto frames MCP penetration testing as a way to expose how AI systems fail when untrusted context can shape decisions, tool use, and downstream actions.

Why it matters: It matters because practitioners now need to govern context integrity as a security control, not treat AI model behaviour as isolated from authentication, validation, and tool access.

Context

MCP creates a new governance problem for AI security because the system does not just consume data, it consumes context that can alter behaviour and trigger actions. When that context is untrusted, weakly validated, or chained through multiple tools, the attack surface shifts from model output quality to control over the decision path.

For identity and access teams, the key issue is that agentic systems can inherit trust from the surrounding workflow without proving that each contextual input is safe. That makes MCP testing relevant to agent identity, tool authorization, and context validation as much as to application security. The article’s starting position is typical for modern agentic AI deployments, where the trust model is still catching up with runtime behaviour.

Key questions

Q: What breaks when MCP context is not validated before an AI agent acts on it?

A: The system can turn untrusted context into trusted action. That means a manipulated input can change tool selection, alter model reasoning, or trigger unsafe downstream workflow steps without ever compromising the model itself. The failure is in the trust boundary, not just in the answer quality.

Q: Why do weak authentication and open MCP endpoints increase AI security risk?

A: They let attackers intercept or inject context before the model evaluates it. Once that happens, the agent may act on attacker-controlled information while appearing to operate normally. In delegated AI workflows, poor endpoint control can become a privilege problem as much as a data problem.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: Should organisations test MCP security separately from traditional penetration testing?

A: Yes. Traditional pentesting finds infrastructure and application flaws, but MCP testing checks whether context handling, tool chaining, and validation logic can be manipulated. Both matter, but they answer different questions. Agentic systems need assurance over runtime decision paths, not only over exposed services.

Technical breakdown

How MCP context flows create a new trust boundary

Model Context Protocol systems move data between an agent, an MCP client, an MCP server, and external tools or data sources. The technical risk is that each hop can transform untrusted input into trusted context if validation is weak or missing. That is different from classic app security, where the boundary is usually the request or session. In MCP workflows, the boundary can span several components, and an attacker only needs one weak link to influence downstream model behaviour. This is why context integrity testing matters: it checks whether the system can distinguish verified context from manipulated input before the model acts on it.

Practical implication: map every MCP hop and define where validation must occur before context can influence tool use or model output.

Why weak authentication and open endpoints matter in MCP

MCP security is not just about what the model sees. It also depends on whether the protocol layer enforces authentication, encryption, and access control around context exchange. Open broker endpoints, weak authentication, and incomplete transport protection let an attacker intercept or inject data before the model ever evaluates it. In practice, that means the model may behave correctly from its own perspective while still acting on attacker-controlled context. For identity practitioners, this is the same class of issue seen in other delegated systems: if the caller or intermediary is not strongly proven, trust is inherited too early and too broadly.

Practical implication: require strong authentication and protected transport for every MCP endpoint that can feed privileged context into AI workflows.

Context injection is a governance failure, not only a model failure

Context injection attacks exploit the assumption that inputs are reliable simply because they arrive through an approved workflow. The attacker does not need to break the model itself. They only need to alter, poison, or selectively shape the context that the model uses to reason or to call tools. That makes validation policy the real control surface. The closer the system gets to autonomous action, the more dangerous this becomes, because the output is no longer advisory. It becomes executable. The governance lesson is that model assurance is incomplete unless the organisation can prove the provenance, integrity, and scope of the context feeding the model.

Practical implication: treat context provenance and input validation as security controls with ownership, testing, and audit evidence.

Threat narrative

Attacker objective: The attacker wants to influence AI decisions by turning untrusted context into trusted action.

1. Entry occurs when an attacker inserts malicious or misleading context into the MCP data flow through a weakly controlled input path.
2. Credential or trust abuse follows when the system accepts that context as legitimate and forwards it through chained tools or brokered exchanges.
3. Impact occurs when the manipulated context changes model behaviour, produces unreliable outputs, or drives unsafe downstream actions.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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

Context integrity is now a first-class security control for agentic AI. MCP testing shows that the real failure is not simply an incorrect model answer, but a system that cannot prove which context deserves trust. That shifts the security question from output quality to decision-path integrity. Practitioners should treat context validation as part of the control plane, not a downstream tuning exercise.

Identity and authorization gaps now reach into AI runtime behaviour. Once an agent can fetch context, call tools, and pass data across brokers, the question becomes who or what is allowed to influence that chain. This is where agent identity and tool authorization intersect with MCP security. A system that cannot separate authenticated access from trusted context will over-extend privilege into the model layer.

Context integrity gap: unverified inputs become operationally trusted context, which is the failure mode MCP penetration testing is designed to expose. That gap matters because attackers do not need model compromise when they can compromise the inputs the model believes. The practical conclusion is that organisations need governance over provenance, validation, and tool-chaining boundaries before autonomous use expands further.

Traditional pentesting is necessary but insufficient for agentic systems. Infrastructure testing can confirm that the server is hardened, but it will not tell you whether a prompt, tool response, or upstream context source can still steer the AI into unsafe action. MCP security extends the scope of assurance into the runtime logic of the agent. Security teams should align AI testing with the same discipline they use for privileged workflows.

AI governance teams should expect this problem to intensify as agentic adoption grows. The more workflows depend on context exchange, the more a single validation weakness can affect multiple actions and systems. That makes MCP testing a governance requirement, not a niche red-team exercise. Teams should build control evidence around context provenance, not just model safety metrics.

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.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Context integrity will become a routine governance requirement for agentic AI programmes. As more workflows depend on MCP-style context exchange, the practical control point moves to issuance time and validation time, not just model output review. Teams that still focus only on prompt safety will miss the broader trust boundary around tools, brokers, and upstream sources.

Agent identity and MCP security are converging. If an agent can only behave safely when its context, tool scope, and source trust are all constrained, then identity governance has to extend into the runtime chain. That means access policy, provenance logging, and tool authorization need to be designed together, not as separate projects.

For practitioners

• Map MCP trust boundaries Document every path from agent to MCP client, MCP server, and external tools, then mark where context is created, transformed, validated, and consumed.
• Enforce authentication on every MCP endpoint Require strong authentication, protected transport, and access scoping for all endpoints that can contribute context to agentic workflows.
• Test for context injection as a control failure Run controlled malicious input tests to confirm that unverified context cannot alter tool calls, model outputs, or downstream workflow decisions.
• Instrument context provenance in logging Record which source supplied each material context element so security teams can trace manipulation attempts back to specific injection points.
• Separate model assurance from infrastructure assurance Add agent and context validation checks to existing pentest and red-team programmes so AI runtime behaviour is assessed alongside platform hardening.

Key takeaways

• MCP testing exposes a security gap where AI systems trust context too easily, allowing manipulated inputs to shape decisions and actions.
• The risk is not limited to model robustness, because weak authentication, open endpoints, and poor validation can all turn context into a control path for attackers.
• Security teams should treat context provenance, tool chaining, and validation evidence as core governance controls for agentic AI deployments.

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 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.
• Context Injection: A failure mode where malicious or misleading content enters an agent's decision path and affects what it does next. In MCP environments, the injected context can alter tool selection, broaden data exposure, or trigger unsafe follow-on actions across multiple systems.
• Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the runtime decisions now shaping AI security programmes.