MCP creates an AI blind spot in CTEM programs

At a glance

What this is: This analysis argues that Model Context Protocol has become a new attack surface for agentic AI, and that CTEM programs usually miss it because the protocol enables attacks that change tool behaviour after approval.

Why it matters: It matters because IAM, PAM, and zero trust controls can authenticate a session yet still fail to govern the semantics and blast radius of AI agent actions across connected tools.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read SafeBreach's analysis of the NSA MCP advisory and CTEM blind spots

Context

Model Context Protocol, or MCP, is the layer that lets AI agents call tools and data sources in a standard way. In practice, that makes it an identity and governance problem as much as an integration problem, because the agent can inherit tool reach that traditional IAM and CTEM scoping never mapped cleanly.

The security gap is not that MCP is hidden, but that its behaviour can change after approval and still look authorised. That creates a governance mismatch for enterprise AI programmes that assume trusted integrations remain semantically stable across their lifecycle.

For practitioners, the starting point is to treat MCP like a load-bearing control surface rather than a convenience layer. That is a familiar pattern in NHI governance: once a machine identity can invoke tools, the issue becomes lifecycle control, blast radius, and auditability, not just connectivity.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP attacks bypass many zero trust controls?

A: Because zero trust can verify the source of a request without verifying that the request still means what it meant at approval time. MCP attacks exploit that gap by altering tool behaviour, injecting instructions, or shifting context after authorisation, while the session still looks legitimate.

Q: What breaks when CTEM does not include AI protocol layers?

A: Exposure management becomes incomplete because the programme may find endpoints and cloud assets while missing the agent-to-tool layer where modern AI abuse happens. The result is false confidence: the controls look scoped, but the actual attack path through the AI integration remains untested.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

How MCP changes the attack surface for AI agents

MCP standardises how an AI agent talks to external tools, but it also concentrates risk in the protocol layer. The agent becomes the decision-maker, while the MCP server executes actions, fetches data, or triggers workflows. That means one approved integration can expose many downstream systems if the server changes behaviour, accepts malicious tool descriptions, or chains requests across contexts. This is why the risk is not just authentication failure. It is a control-plane failure over what an approved tool is allowed to mean over time.

Practical implication: inventory MCP servers and map each one to the data, systems, and privileges it can influence.

Why zero trust does not fully cover MCP semantics

Zero trust checks identity, device, and request context, but MCP attacks can pass those checks while changing the meaning of a tool after approval. A server may be signed, reachable, and properly authenticated, yet still poison instructions, switch behaviour on later use, or relay context from one server to another. Classical policy engines are built to decide whether to allow a request, not to continuously verify that the request still means what it meant at approval time. That is the gap the NSA is highlighting.

Practical implication: validate approved integrations continuously, not just at onboarding or change approval.

Why CTEM needs attack validation for MCP infrastructure

CTEM is strongest when it tests whether an exposure is actually exploitable. For MCP, that means validating tool poisoning, indirect prompt injection, malformed JSON-RPC handling, and cross-server contamination against live controls rather than assuming the protocol stack is safe because it is new. The exposure surface also extends to reference tooling, scanners, and agent orchestration layers, not just production servers. If the validation program only covers endpoints, cloud, and enterprise ATT&CK tactics, it will miss a category of AI-native abuse by design.

Practical implication: add MCP abuse cases to exposure validation and detection engineering exercises.

Threat narrative

Attacker objective: The attacker wants to make an authorised AI agent do something dangerous while appearing to operate within approved access boundaries.

1. Entry occurs when an attacker introduces a malicious MCP server, poisons a public issue, or abuses a trusted integration path that an AI agent already consumes.
2. Credential or context abuse follows when the agent accepts the malicious instructions and uses its existing authorisation to reach private data, tools, or workflows.
3. Impact occurs when the agent exfiltrates sensitive content, changes behaviour silently, or executes unintended actions across connected systems.

NHI Mgmt Group analysis

CTEM blind spots now include AI protocol layers, not just exposed assets. MCP turns AI integration into a control surface that many exposure programs never modelled. Discovery and prioritisation are still necessary, but they are insufficient when the threat is behavioural drift inside an authorised tool channel. Practitioners should treat MCP inventory as part of the exposure management baseline, not as a separate AI project.

Meaning-based attacks expose a governance gap that IAM cannot close alone. When a server changes behaviour after approval, identity checks still succeed while the action becomes unsafe. That is a trust decay problem, not a classic authentication problem. The control failure sits between authorisation and runtime behaviour, which means NHI and agentic AI governance must extend into continuous verification and scoped execution.

OWASP Agentic AI Top 10 and MITRE ATLAS are now relevant to CTEM scope decisions. MCP abuse belongs in the same defensive conversation as prompt injection, tool misuse, and context poisoning. If a validation programme only speaks ATT&CK Enterprise, it will understate the real attack surface of agentic systems. Teams should align AI validation with AI-native threat models, not retrofit them after an incident.

Identity and access teams need to reframe AI agents as governed non-human identities. The article is really about what happens when machine-initiated actions outgrow the lifecycle controls built for service accounts and integrations. The practical lesson is that authorisation, audit, and offboarding logic must follow the agent and its tool bindings, not just the API key or session token. That is the NHI governance gap this topic exposes.

Model Context Protocol blind spot: MCP creates a new class of authorised-but-misleading behaviour, where the approved integration remains valid while the semantics become hostile. That concept matters because most controls are designed to detect unauthorised access, not authorised misuse through shifted tool meaning. Practitioners should use this as the framing for runtime control design and assurance testing.

What this signals

Model Context Protocol is becoming a governance problem before it is a tooling problem. If AI agents can call tools and move data through a protocol layer that traditional CTEM does not scope, then the next control gap is runtime assurance, not another discovery scan. Teams should expect validation requirements to expand from assets and endpoints into agent behaviour, tool semantics, and delegated authority.

The practical name for this gap is trust decay. Approval time and execution time are no longer the same moment, which means the safest control is not just authentication but continuous verification of tool meaning, scope, and ownership. That is where AI governance starts to overlap with NHI lifecycle control and with standards such as NIST AI Risk Management Framework and OWASP Agentic AI Top 10.

For identity programmes, the key shift is to treat AI integrations like ephemeral delegated privilege. Once an AI agent can act across email, storage, ticketing, and CRM, offboarding, scope review, and audit evidence need to follow the agent and its servers. That is why machine identity governance now sits alongside exposure management rather than after it.

For practitioners

• Inventory every MCP connection Build a live register of MCP servers, clients, and tool bindings across sanctioned and shadow AI deployments. Classify each connection by data sensitivity, business owner, and change-control path so you can see where AI agents already have production reach.
• Require identity-aware controls on sensitive servers Mandate mutual TLS, identity-aware proxy enforcement, and role-based access control for MCP servers that touch regulated or sensitive data. Treat specification optionality as an implementation risk, not a policy decision.
• Add MCP abuse cases to validation testing Exercise tool poisoning, indirect prompt injection, and cross-server context exfiltration against your live controls before deployment. Feed the results into your CTEM and SIEM workflows so detection gaps surface during testing, not after first use.
• Instrument tool invocations for auditability Log parameters, identities, and result hashes for every significant tool call, then correlate them to behaviour baselines. Without that record, incident response will struggle to distinguish normal delegation from malicious redirection.

Key takeaways

• MCP introduces an AI-native attack surface that can pass classical identity checks while still producing unsafe actions.
• The strongest evidence is behavioural, not theoretical: tool poisoning, context exfiltration, and silent scope changes have already been demonstrated.
• Practitioners should extend CTEM into agent validation, runtime auditability, and NHI-style lifecycle control for AI tool bindings.

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.
• Trust Decay: The idea that trust becomes less reliable over time unless systems keep re-checking the conditions behind it. In identity governance, this explains why static login decisions age badly and why continuous verification matters across human, NHI, and autonomous access models.
• Cross-server context exfiltration: A failure mode where an AI agent uses one trusted server or context to pull information from another and move it into an unintended destination. It is especially dangerous in multi-server agent setups because the breach occurs across connected tools, not at a single perimeter.
• Adversarial Validation: Adversarial validation is the practice of testing a model or system against realistic attack patterns before and after deployment. It checks whether hidden instructions, multi-turn pressure, and malicious context can change behaviour. For enterprise GenAI, it is more useful than synthetic benchmark confidence because it reflects live operational risk.

What's in the full article

SafeBreach's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step attack validation examples for MCP tool poisoning and context exfiltration.
• Practical inventory guidance for finding shadow MCP servers in live environments.
• Detection and response checkpoints for SIEM correlation and runtime alerting.
• Control recommendations for identity-aware proxy enforcement and RBAC at the server layer.

👉 The full SafeBreach post covers the attack techniques, validation examples, and control steps in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and machine identity security for practitioners who need to control delegated access across modern environments. It helps security and identity teams connect lifecycle control, auditability, and least privilege to real-world operational decisions.