MCP security vs. MCP protection: runtime governance gaps

At a glance

What this is: This is an analysis of why MCP security and MCP protection address different parts of the same control problem, with one focused on governance and observability and the other on runtime enforcement.

Why it matters: It matters because IAM, NHI, and agentic AI programmes cannot treat policy, detection, and blocking as the same control, especially when legitimate tool access can still be weaponised in-session.

Context

MCP security is the governance layer for how agents authenticate, which tools they are allowed to reach, and what gets logged when they do. MCP protection is the runtime layer that inspects and blocks malicious behaviour while a session is in flight, which makes the difference between observing an attack and stopping it.

The gap matters because a tool call can look legitimate at the gateway while still being part of a larger abuse chain inside the session. For identity and access teams, the question is not whether the controls exist, but whether governance, observability, and runtime enforcement are being treated as separate responsibilities.

In agentic AI programmes, MCP also sits alongside direct API calls, browser automation, and other tool paths. That means securing the MCP surface alone does not equal securing the agent's full access pattern.

Key questions

Q: What breaks when MCP protection is missing even if MCP security is in place?

A: The gap is that access can be valid while behaviour is malicious. MCP security can log and constrain tool access, but without runtime protection a prompt injection or poisoned tool descriptor can redirect the agent after authentication and still complete harmful actions inside the same session.

Q: Why does session-level correlation matter for MCP risk?

A: Because single tool calls often look safe on their own. The risk appears when prompts, retrieved content, and downstream actions are connected into one sequence, showing that authorised access was being used to steer the agent toward exfiltration or other unsafe outcomes.

Q: How should teams decide between governance controls and runtime blocking for MCP?

A: Use governance controls to define who and what is allowed, then use runtime blocking to stop misuse once a session starts. If a control cannot see the prompt, the response content, and the action sequence together, it is not enough for active attack containment.

Q: What should security teams do when MCP tool calls are authorised but still look risky?

A: Treat authorised tool use as a possible attack path, not proof of safety. Investigate whether the call was preceded by suspicious content, followed by unexpected actions, or routed outside the intended gateway, because that is where legitimate access becomes abuse.

Technical breakdown

MCP security as governance and observability

MCP security sits at the identity and policy layer. It centralises authentication, enforces per-agent access to approved MCP servers, and records tool-call metadata for audit and forensics. That makes it useful for inventory, access scoping, and post-incident reconstruction, but it only sees what passes through the MCP route. If developer environments can bypass the gateway, or if agents use other tool protocols, the control plane has partial visibility rather than full governance.

Practical implication: Treat MCP security as the control layer for authorisation, logging, and access review, not as the full enforcement boundary.

MCP protection as runtime enforcement

MCP protection is an inline control that evaluates behaviour as the session unfolds. It correlates prompts, tool responses, and sequence context so it can block prompt injection or tool poisoning before the attack completes. The critical difference is timing: the system does not wait for an alert cycle or analyst review. It acts while the malicious sequence is still executing, which is why session context and semantic analysis matter more than static metadata.

Practical implication: Place runtime enforcement where the agent and tool exchange can be interrupted before the session reaches a harmful terminal action.

Why metadata alone misses session-level abuse

A single authenticated call can be harmless in isolation and dangerous in sequence. Static rules on identities, allowlists, or rate limits do not reveal whether an agent is reading a document, being steered by that document, and then exfiltrating data in the same session. That is the governance blind spot: metadata proves the call happened, not why it happened or what it was chained to. The article's key point is that authorised access can still be the attack path.

Practical implication: Correlate tool calls, prompts, and responses across the full session before assuming access metadata is sufficient evidence of safety.

Threat narrative

Attacker objective: Exploit legitimate MCP access to redirect agent behaviour and complete harmful tool-driven actions without triggering access-control alarms.

1. Entry occurs through legitimate MCP authentication or an approved tool route, so the initial access looks compliant rather than suspicious.
2. Credentialed tool use is then weaponised when a prompt injection or poisoned tool descriptor steers the agent into unsafe actions within the same session.
3. The attacker achieves exfiltration or other harmful downstream action while each individual tool call still appears authorised at the gateway.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

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

MCP security is governance, not containment: The control layer defines who may connect, what they may reach, and what gets recorded, but it does not stop a hostile session once authorised access is already in motion. That distinction matters because many teams still describe observability as if it were enforcement. The practical conclusion is that identity governance for MCP must be evaluated separately from runtime defence.

Session-level context is the real control boundary: Tool calls become risky only when the prompt, the retrieved content, and the downstream action sequence are analysed together. Static metadata cannot explain why a call happened or whether the agent was manipulated through an authorised channel. Practitioners should treat session correlation as the difference between post-incident forensics and active containment.

Runtime protection exposes the runtime governance gap: The gap is not simply missing controls, but the assumption that access control can see and stop all abuse at the point of authentication. That assumption fails when the threat emerges after a legitimate session begins and unfolds across multiple tool interactions. The implication is that MCP governance has to be designed as a layered decision model, not a single gateway decision.

MCP protection and MCP security are complementary, but they answer different questions: One asks whether access is permitted and visible, the other asks whether the session should continue. Organisations that collapse those questions into one vendor category will under-design one layer and over-trust the other. The practitioner takeaway is to separate governance, detection, and runtime blocking in both architecture and ownership.

Authorised access can still be the attack path: That is the most important governance lesson in the article. When agents interact through valid credentials, the security problem shifts from preventing login to constraining in-session behaviour. Teams should reframe MCP risk around legitimate access being redirected, because that is where policy-only controls stop being enough.

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

Runtime governance gap: MCP programmes need a split between policy decisions and in-session containment. If the same layer is expected to authenticate agents, permit tools, detect abuse, and stop the attack, the programme is already overloading one control boundary.

The operational test is whether the team can interrupt a hostile agent session after access is granted and before the final tool action completes. That is where MCP security and MCP protection diverge in practice, and where ownership between IAM, platform security, and AI security teams has to be explicit.

For practitioners

• Separate governance from enforcement Map MCP authentication, access control, and logging to the governance stack, then assign runtime blocking to a distinct control layer with clear operating ownership.
• Inventory every MCP route Identify MCP clients that bypass a central gateway and document any direct connections, because ungoverned routes leave the policy layer with partial coverage.
• Correlate full-session context Retain prompts, tool responses, and tool-call order so you can judge whether a valid action was part of a larger injection or poisoning sequence.
• Test for authorised abuse paths Run scenarios where a permitted document, tool descriptor, or downstream response changes agent behaviour after access is granted, then verify whether the control blocks the session.

Key takeaways

• MCP access governance and MCP runtime blocking solve different problems, and neither should be treated as a substitute for the other.
• A valid tool call can still be part of an attack chain when prompt content, response data, and session sequence are analysed together.
• Practitioners should separate policy, observability, and inline containment if they want MCP controls that hold up under authorised abuse.

Key terms

• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• MCP Protection: MCP Protection is the set of controls used to secure Model Context Protocol connections between AI agents and the tools, data, or services they access. It covers authentication, authorization, input validation, secret handling, logging, policy enforcement, and monitoring to reduce tool abuse, data leakage, and unauthorized agent actions.
• Session-Level Correlation: Session-level correlation links identity events across logs and tools into one continuous access story. This is critical when an attacker uses valid credentials, because isolated events can look harmless while the full sequence reveals compromise, privilege abuse, or lateral movement.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.