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 are different control layers, and why runtime enforcement matters when authorized agent activity is weaponized.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide where identity governance ends and runtime intervention begins when agents and tools operate through MCP.

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 Impart Security's analysis of MCP security vs. MCP protection

Context

MCP security is the identity and governance layer around model context protocol connections: it decides which agents can reach which tools, what gets logged, and which policies are enforced. The problem is that this layer is often treated as if it can also stop an attack in progress, when in practice it mainly governs access and records activity.

For IAM and NHI programmes, the important distinction is between policy control and runtime enforcement. In MCP environments, legitimate credentials and approved tools can still be used in ways that turn normal access into an attack path, so teams need to understand where their current control set actually ends.

This is why the article matters for agentic AI governance as much as for NHI governance. The control question is not whether an agent can authenticate, but whether the organisation can see and stop malicious behaviour after authentication has already succeeded.

Key questions

Q: How should security teams govern MCP access in agentic workflows?

A: Security teams should govern MCP access as delegated identity, not simple application connectivity. That means binding consent to the client, validating the token audience, refusing passthrough, and constraining each tool call to the narrowest possible scope. If those controls are not enforced per request, an authorised login can become an unauthorised action path.

Q: Why do authenticated agents still create security risk in MCP environments?

A: Authenticated agents still create risk because authentication only proves that a subject entered the system. It does not prove that the next tool call, data access, or transaction is still allowed under the original delegation. That gap becomes dangerous when agent behaviour changes across tools or sessions.

Q: What do organisations get wrong about MCP security?

A: They often focus on network isolation or prompt filtering and miss the real issue: an authorised workload can still perform an unintended action. MCP security fails when teams trust transport and service authentication to answer an authorization question that only the request context can resolve.

Q: Who is accountable when an MCP session misuses tools or data?

A: Accountability sits with the organisation that defined the policy, the control plane that granted the session, and the team that owns logging and revocation. If those responsibilities are split, investigation and containment become slow, and the governance gap becomes part of the incident itself.

Technical breakdown

MCP security: identity, policy, and audit at the gateway

MCP security is the governance layer that sits in front of MCP servers. It usually includes centralized authentication, tool allowlists, per-agent permissions, audit logging, and static policy enforcement. In NHI terms, it treats agents like identities with scoped access, then records tool usage for forensics and compliance. The limitation is structural: if a client bypasses the gateway or if the agent uses other channels such as direct API calls, the control plane no longer sees the activity. Practical implication: define MCP security as an access and observability layer, not as a complete defence model.

Practical implication: scope MCP routes, inventory all non-gateway connections, and treat bypass paths as governance exceptions.

Runtime MCP protection: blocking attacks during a live session

MCP protection is the inline enforcement layer. Instead of only logging tool calls, it inspects the session context, the sequence of actions, and the content returned by tools to detect prompt injection or tool poisoning while the session is still active. That matters because the malicious step is often indistinguishable from normal access if viewed in isolation. Session-level correlation is what turns a string of legitimate actions into evidence of abuse. Practical implication: if a control cannot interrupt a live session, it is not MCP protection in the operational sense.

Practical implication: pair runtime detection with active blocking, quarantine, or session interruption controls.

Why authorized access can still become an attack chain

The core risk in MCP environments is not always unauthorized access. It is authorized access being weaponized after the fact through prompt injection, malicious tool descriptors, or data that redirects the agent's behaviour. Because the agent is already authenticated, the attack uses legitimate permissions and valid tool paths to exfiltrate data or trigger unsafe actions. That makes tool-level metadata alone insufficient. Practical implication: analyse how a benign tool call can become the terminal step in a multi-stage chain, not just whether the call was allowed.

Practical implication: correlate prompts, tool outputs, and session order when evaluating abuse scenarios.

Threat narrative

Attacker objective: The attacker wants to turn legitimate MCP-mediated access into covert data theft or unsafe tool execution without triggering obvious authorization failures.

1. Entry occurs through a legitimate MCP connection or trusted tool channel, not necessarily through unauthorized login.
2. Escalation happens when the agent follows poisoned tool content or injected instructions that redirect its next actions.
3. Impact follows when the attacker weaponizes the authorised session to exfiltrate data, manipulate downstream tools, or complete a multi-stage abuse chain.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 security is an access-control and observability layer, not a runtime containment layer. That distinction matters because organisations often expect policy enforcement, audit logging, and authentication to do the job of stopping an attack in progress. They cannot. In MCP architectures, the security control may know who connected and what tool was called, but not whether the session was being steered toward abuse. Practitioners should treat this as a governance boundary, not a marketing distinction.

Session-level context is the named concept teams should be tracking. The article shows that individual tool calls can look legitimate while the session as a whole is malicious. That means identity governance for MCP cannot be reduced to per-call allowlists or token validation. It has to understand the sequence of actions, the source content, and the relationship between prompt, tool output, and downstream behaviour. The practical conclusion is that session context is now a control object, not just a telemetry detail.

Runtime enforcement becomes mandatory once authorised access can be weaponized. This is where MCP protection sits, but the field should be clear about why it is needed: static policy assumes the harmful event is the access itself, while MCP abuse often starts after access has already been granted. That makes the governance problem a post-authentication control problem. Teams should re-evaluate whether their current NHI and agent controls can still operate when the threat is inside the session.

MCP governance exposes a wider identity assumption that is already breaking. Least privilege is often designed as a provisioning-time decision because the actor's intent is assumed to be stable. In MCP-driven agent activity, intent can shift after a tool response or injected instruction. The implication is that identity governance cannot stop at issuance, because the risk changes during execution and not just at the point of access grant.

MCP runtime enforcement gap: This is the control gap that matters most here, because the article makes clear that observability without intervention leaves security teams watching an attack unfold. That gap is especially relevant for NHI and agentic AI programmes that rely on centralized audit trails as proof of control. Practitioners should interpret this as a call to separate governance evidence from containment capability.

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, which helps explain why governance-only controls remain incomplete.
• For a broader view of where the category is heading, compare this with OWASP Agentic Applications Top 10, which frames how tool abuse and identity exposure combine.

What this signals

MCP governance will increasingly be judged by whether it can prove control across the full session, not just at authentication time. The organisations that rely only on gateway logs will continue to miss the behavioural gap between allowed access and malicious use, especially as agent adoption expands. With 96% of technology professionals identifying AI agents as a growing security threat in the AI Agents: The New Attack Surface report, the operational question is no longer whether to inspect, but whether you can stop abuse before the session completes.

Session-context governance: that is the real control problem here. Teams need to understand how prompt, tool output, and execution order interact, because the attack surface is now defined by behaviour across time rather than by a single authorisation event. The practical shift is from auditing permitted actions to governing the path an agent takes through them.

For practitioners

• Define the MCP control boundary Document which controls are governance only, such as authentication, allowlisting, and audit logging, and which controls can actually interrupt a live session. If a capability cannot block execution inline, do not treat it as runtime protection.
• Inventory every non-gateway MCP path Map direct client connections, developer-installed tool integrations, and any API routes that bypass centralized MCP enforcement. The article's governance warning only matters if you can see where the gateway is not in the path.
• Correlate prompts, tool output, and action sequence Require the security team to review how prompt content, tool responses, and downstream actions fit together during an incident. Per-call logs alone will not show whether a legitimate tool invocation was the start of a session-level abuse chain.
• Separate audit evidence from containment evidence Use audit logs to support investigation and compliance, but require a different control class for blocking prompt injection, tool poisoning, or malicious agent behaviour during execution. That distinction is central to MCP governance.

Key takeaways

• MCP security and MCP protection solve different problems, and confusing them leaves teams with either governance without enforcement or detection without containment.
• The central risk is authorised access being weaponized inside a live session, which makes session context and runtime blocking more important than isolated tool-call logs.
• Practitioners should separate identity governance for MCP from runtime response capability, because audit evidence does not stop a poisoning or prompt-injection chain.

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.
• 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.
• 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.

What's in the full article

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

• A side-by-side breakdown of MCP security and MCP protection control responsibilities across the stack.
• Specific examples of inline response techniques for blocking prompt injection and tool poisoning.
• The operational distinction between session-level correlation, alerting, and true enforcement.
• The practical gap between gateway governance and runtime interruption in deployed environments.

👉 Impart Security's full post covers the runtime enforcement details and the limits of governance-only MCP controls.

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.