MCP security shows why AI agent access needs zero trust

At a glance

What this is: MCP connects AI agents to enterprise tools and data, and the key finding is that the protocol itself does not provide the security controls enterprises need by default.

Why it matters: IAM, NHI, and PAM teams need to treat MCP as a new identity surface because agent access can overreach faster than existing workload and human-access models can govern.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 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 AccuKnox's analysis of MCP security and Zero Trust controls for AI agents

Context

MCP security is an identity governance problem as much as a protocol problem. When an AI agent can call tools, read resources, and trigger workflows through MCP, the important question is no longer only whether the connection works. It is whether the agent's identity, scope, and authority are governed tightly enough for the actions it can take.

The article describes a familiar mismatch: security teams have invested in Kubernetes policies, CNAPP, and workload controls, but those controls do not automatically govern how an agent decides which tools to use or what data to request. That gap becomes especially visible when a shared credential, an overbroad token, or an unscoped MCP server allows agent behaviour to exceed its intended boundary.

For teams responsible for AI agent governance, the starting assumption should be that MCP expands the blast radius unless identity, authorization, and runtime enforcement are aligned. That is typical of early agent deployments, not an edge case.

Key questions

Q: How should security teams govern AI agents that use service accounts and MCP tools?

A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What do security teams get wrong about AI and zero trust?

A: They often treat zero trust as a one-time architecture choice instead of continuous verification. AI-driven workflows increase the number and pace of requests, so trust must be reassessed throughout the session, not only at sign-in.

Q: How can organisations tell if an MCP server is safe enough to use?

A: Look for evidence that every tool is bound to a narrow role, every session is logged, every credential is short lived, and unexpected outbound behaviour is blocked at runtime. If any one of those elements is missing, the environment is still relying on trust rather than control.

Technical breakdown

How MCP tool calls create a new identity boundary

MCP uses JSON-RPC to connect an agent to a server, discover tools with tools/list, and invoke them with tools/call. The protocol handles transport and messaging, but it does not define native authentication, authorization, or audit controls. That means the security boundary shifts from the protocol to whatever identity layer and policy engine the enterprise adds on top. In practice, the trust decision is made at the point of tool invocation, not when the protocol starts, which is why shared credentials and broad tokens are so dangerous.

Practical implication: govern MCP servers as access points, not as harmless middleware, and bind every agent to a distinct identity and scope.

Why prompt injection becomes tool abuse in MCP workflows

Indirect prompt injection matters because the agent reads untrusted content and can then use that content to choose an action. A malicious instruction hidden in a ticket, document, or database row can cause the agent to call tools, reveal data, or change state while appearing to follow normal workflow logic. The security issue is not just the model reading bad text. It is the model turning that text into an authorised action path through trusted tools, which makes content handling and action handling inseparable.

Practical implication: separate data ingestion controls from tool execution controls, and treat agent outputs as policy-relevant events rather than harmless text.

Why runtime enforcement matters when static policy is not enough

Static checks can tell you whether a tool exists, but they cannot reliably predict how an agent will combine tools or what a live tool response will contain. Runtime enforcement at the container or kernel layer closes that gap by watching actual system calls, outbound connections, and JSON-RPC activity. That matters when an MCP server is running inside Kubernetes, because pod-level RBAC does not inspect tool intent or response content. Runtime control is the difference between configuration hygiene and actual containment.

Practical implication: add runtime inspection and network containment for MCP workloads so unexpected tool use is blocked before data leaves the environment.

Threat narrative

Attacker objective: The attacker aims to turn a trusted agent workflow into a controlled path for data exposure, unauthorized actions, or credential leakage.

1. Entry begins when an AI agent is granted access to an MCP server through a shared key, token, or overbroad connector trust relationship.
2. Escalation occurs when prompt injection or a poisoned tool response causes the agent to invoke tools beyond the intended scope or to cross tenant boundaries.
3. Impact follows when the agent exfiltrates sensitive data, reveals credentials, or performs unauthorized actions on systems that appeared to be legitimately connected.

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 really a control problem, not a protocol problem: the protocol can move requests and responses, but it cannot decide who should be allowed to act. That means enterprises inherit the burden of identity binding, authorization scoping, and auditability at every tool boundary. The practitioner conclusion is simple: MCP should be treated as an identity plane for agents, not just a developer convenience.

Access scoping is the first thing MCP exposes when it is missing: tool catalogs make privilege width visible very quickly, and most environments are not prepared for that visibility. If an agent can discover tools broadly but is governed only by a shared credential, the real problem is not tooling sprawl, it is privilege ambiguity. The implication is that teams must re-evaluate how they define least privilege for non-human identities that can choose actions at runtime.

Tool poisoning and indirect prompt injection create an identity-adjacent trust failure: the system begins to trust content as if it were instruction, then trusts instruction as if it were authorized action. That is a governance failure across data handling, identity, and execution, not a single-layer defect. Practitioners should conclude that input trust and tool trust cannot be managed as separate controls once an agent mediates both.

Identity blast radius becomes the decisive metric for agentic access: MCP does not create risk because it exists, but because it can connect one agent identity to many tools and many datasets in one session. The more those connections are shared, static, or reusable, the more a single misuse event expands into an enterprise-wide exposure pattern. The correct question is how much damage one agent credential can cause, not whether the agent is technically authenticated.

Runtime enforcement is the only credible backstop when agent behaviour is dynamic: static policy can define intent, but live agent sessions decide what actually happens. That makes kernel-level blocking, output controls, and immutable logging central to MCP governance. The practitioner conclusion is that agent identity must be monitored where tool execution occurs, not only where access is provisioned.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface.
• A separate finding in the same report shows that 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a broader governance lens, see OWASP Agentic Applications Top 10 for the control patterns that map to agent behaviour.

What this signals

Identity blast radius: once an MCP server is connected to production data, the practical question becomes how far one agent credential can reach before policy stops it. With 80% of organisations already reporting agent actions beyond intended scope, per AI Agents: The New Attack Surface, the governance problem is no longer theoretical. Programmes should measure how many tools, datasets, and write paths each agent can touch in a single session.

MCP governance will increasingly converge with workload identity, prompt security, and runtime enforcement in the same operating model. Teams that continue to separate those functions will miss the shared failure mode, which is that instruction, authorization, and execution now happen in the same runtime flow.

The next maturity step is not broader visibility alone. It is the ability to prove that an agent cannot discover, select, and abuse tools outside its task boundary, even when the data it reads is adversarial.

For practitioners

• Bind each agent to a distinct identity Use per-agent workload identity rather than shared API keys or common service tokens, and make the credential scope match a single user or tenant context. This is the foundation for audit and containment.
• Scope tool permissions to explicit task needs Map each MCP tool to a narrow role and deny default access to unrelated tools, data sets, and write operations. Revisit the allow list whenever a new tool is added to the server.
• Separate input trust from execution trust Inspect untrusted content before it reaches the model, then enforce a second policy layer before any tool call is executed. Do not assume a clean prompt or a trusted source makes the action safe.
• Log every tool call as an identity event Record the agent identity, tool name, arguments, policy decision, and response metadata in immutable logs so compliance teams can reconstruct the full action path.
• Contain runtime network and system behaviour Apply kernel or container controls that block unexpected outbound connections, file access, and process behaviour from MCP workloads. Runtime containment should stop unexpected tool abuse before exfiltration occurs.

Key takeaways

• MCP expands the AI agent attack surface because the protocol enables tool use, but does not natively supply the identity or authorization controls enterprises need.
• The most serious failures are not abstract model issues but concrete governance gaps, including overbroad permissions, poisoned inputs, and weak runtime containment.
• Practitioners should govern MCP like a live identity surface, with scoped access, short-lived credentials, immutable logs, and runtime blocking for unexpected behaviour.

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.
• 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.
• Package Firewall: A package firewall is a control that blocks or screens software packages before they enter a development or build environment. It is used to prevent vulnerable, malicious, or non-compliant dependencies from reaching downstream pipelines where later detection may be too late to reduce risk.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.

What's in the full article

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

• A step-by-step MCP security architecture covering prompt firewall, runtime telemetry, and kernel-level enforcement.
• Concrete configuration examples for securing MCP workloads in Kubernetes and limiting outbound behaviour.
• A phase-by-phase roadmap for static scanning, active probing, and shadow MCP detection.
• A catalog of live MCP use cases and the specific tools exposed by the AccuKnox server.

👉 The full AccuKnox article covers MCP failure modes, runtime enforcement, and the roadmap for deeper agent controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.