MCP security shows why AI agent access needs zero trust

At a glance

What this is: This analysis explains why MCP creates a new AI agent access problem: the protocol enables tool use but leaves identity, authorisation, and audit enforcement to layers above it.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent tool access, short-lived credentials, and runtime enforcement instead of assuming the protocol boundary is protective.

Context

MCP, or Model Context Protocol, is a connector layer that lets AI agents call tools and data sources through a standard JSON-RPC interface. The security gap is that the protocol does not define native identity, access control, or audit logging, so enterprises inherit an access problem, not just an integration pattern.

For identity teams, the issue is not whether agents can talk to systems, but whether those interactions are scoped, attributable, and revocable. When an AI agent inherits broad credentials or shared tokens, the access model becomes harder to govern than a traditional workload account because the action path is decided at runtime.

AccuKnox frames the problem around real attack patterns including prompt injection, cross-tenant exposure, and privilege escalation through over-privileged agent sessions. That is a typical outcome once teams treat MCP as a convenience layer rather than a governed identity boundary.

Key questions

Q: What breaks when MCP servers are exposed without identity controls?

A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.

Q: Why do AI agents connected through MCP create zero trust challenges?

A: They create zero trust challenges because access is no longer bounded by a human session or a single application boundary. The agent can move across tools and data sources in sequence, which makes continuous verification, least privilege, and logging essential. Zero trust still applies, but it has to be enforced at the level of each tool call and approval path.

Q: What are the signs that an MCP deployment is over-permissioned?

A: Common warning signs include shared API keys, broad tool access that exceeds the task, missing tenant isolation, and logs that cannot show which agent invoked which action. If every agent can call the same tools with the same secrets, the deployment is likely over-permissioned. That usually means the control model is still centered on infrastructure, not on agent behaviour.

Q: What should teams do when an MCP agent can write or trigger actions?

A: Teams should require human approval gates or equivalent runtime controls before any write operation, workflow trigger, or external side effect is allowed. The key decision is not whether the agent can request the action, but whether the organisation can confirm the identity, scope, and policy state at the moment of execution. That is what keeps delegated access from becoming uncontrolled automation.

Technical breakdown

Why MCP tool invocation creates an identity boundary problem

MCP separates connectivity from security. An agent first discovers available tools, then invokes them, but the protocol does not itself prove who the agent is, what it should access, or whether the resulting action is authorised. That matters because the security decision is no longer attached to the application endpoint alone. In practice, the agent becomes an execution path across tools, data, and workflow systems, which means the real control point has to sit above the protocol. Without that layer, the organisation is trusting the MCP session rather than governing the identity behind it.

Practical implication: Treat MCP as an untrusted transport and enforce identity and authorisation outside the protocol.

How prompt injection and tool poisoning exploit MCP sessions

Indirect prompt injection works when malicious instructions are embedded in content the agent reads, such as a ticket, document, or database row. Tool poisoning is related but broader: the tool or response itself carries unsafe content that changes the agent’s behaviour or leaks data. Because the agent processes both trusted and untrusted inputs in the same runtime context, the attacker does not need to compromise the underlying system. They only need to shape what the agent believes is part of its task, then let the agent carry out the action chain on their behalf.

Practical implication: Inspect both input and output paths, and assume any retrieved content can alter agent behaviour.

Why zero trust for AI agents means runtime enforcement, not policy statements

Zero trust for MCP is about verified identity, scoped permissions, short-lived credentials, and audit trails that capture every tool call. The control model has to assume the agent may be overconfident, overprivileged, or manipulated mid-session. Runtime enforcement is therefore more important than static policy descriptions because the risk appears at execution time, not only at provisioning time. In Kubernetes-based deployments, kernel-level controls and eBPF telemetry can constrain network, file, and system call behaviour while also exposing what agents actually did. That is the difference between policy intent and operational assurance.

Practical implication: Bind agent identity to runtime policy and log each tool invocation as an auditable event.

Threat narrative

Attacker objective: The attacker wants the agent to execute harmful tool actions or disclose data while appearing to use legitimate MCP behaviour.

1. Entry occurs when a legitimate agent reads malicious content through MCP and accepts hidden instructions as part of the task context.
2. Credential abuse follows when the session or tool permissions allow the agent to act with more authority than the user should have delegated.
3. Impact appears when the agent performs unauthorized actions, leaks data across boundaries, or triggers workflows that the attacker could not access directly.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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 really an identity governance problem disguised as a protocol problem. The article makes clear that MCP handles connectivity, not trust, so the security outcome depends on what sits around it. That means identity proofing, authorisation scope, and auditability are not optional add-ons but the actual control plane. Practitioners should stop reviewing MCP as a developer convenience and start treating it as governed non-human access.

Tool poisoning exposes a runtime trust gap that static access models do not see. If an agent can read a prompt-injected ticket, document, or response and then act on it, the enterprise has allowed untrusted content to influence authorised execution. This is not just malware in a new wrapper, it is a governance failure where the trust boundary moved from the user to the data stream. The practitioner implication is that control design must assume content can become instruction.

Short-lived credentials matter because long-lived shared tokens erase accountability. MCP sessions are only governable when the access path is attributable to one agent, one role, and one time-bound privilege set. Shared or static credentials collapse that structure and make post-incident reconstruction weak or impossible. The practical conclusion is that revocation speed and session uniqueness are now core identity controls for AI agent operations.

Verified agent identity and enforced tool allow lists are the new least-privilege baseline for agentic access. Namespace-scoped RBAC is not enough when the action of concern is which tool the agent can invoke and what data it can return. The article points toward a security model where each agent gets a bounded identity, a bounded tool set, and a bounded runtime. Practitioners should align MCP governance with NHI controls, not with generic application security assumptions.

AI agent access review processes will need to be redesigned around execution evidence, not entitlement lists. The moment an agent can discover, call, and combine tools autonomously, reviewing the initial permission grant tells you very little about actual risk. The important signal is what the agent invoked, when it invoked it, and whether the resulting output crossed a policy boundary. Teams should therefore treat runtime telemetry as the authoritative record for agent oversight.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Agent tool access should now be treated as a governed identity boundary, not an integration detail. MCP changes the enforcement point from application login to runtime tool invocation, which means existing IAM assumptions no longer hold by default. Teams that keep relying on static credentials and perimeter-style controls will keep missing the moment when an agent turns a permitted tool call into an unsafe action.

Identity review has to move from entitlement lists to execution evidence. An MCP-connected agent can appear compliant at provisioning time and still behave outside policy during a live session. The useful signal is not whether access was granted, but whether the agent actually invoked the right tools, with the right scope, under the right identity, at runtime.

MCP-aware governance must align with zero trust for AI agents. That means short-lived credentials, per-agent identity, tool allow lists, and immutable logs are now part of the access model itself. If those controls are absent, the organisation is effectively delegating trust to the protocol instead of to the identity programme.

For practitioners

• Enforce verified agent identity Bind each MCP-connected agent to a unique workload identity so tool use is attributable, revocable, and separated from the user account that launched it.
• Reduce credential lifetime to session scope Replace static or shared secrets with ephemeral credentials that expire quickly and cannot outlive the task that created them.
• Limit agents to explicit tool allow lists Give each agent only the tools required for its role and block everything else, including hidden write paths and unintended network destinations.
• Log every tool invocation as an audit event Capture agent identity, tool name, arguments, policy decision, and timestamp for each MCP action so incident review has executable evidence.

Key takeaways

• MCP makes AI agent access operationally useful, but the protocol itself does not solve identity, authorisation, or audit governance.
• Prompt injection, tool poisoning, and overprivileged sessions show that agent behaviour can become the control failure, not just the data source.
• Zero trust for MCP means binding agent identity, limiting tools, shortening credentials, and recording execution evidence at runtime.

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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

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.