Model Context Protocol turns AI agents into an identity risk

At a glance

What this is: This analysis argues that Model Context Protocol makes AI agents an identity and access problem because it lets authorized software act across live systems with real credentials.

Why it matters: For IAM and NHI teams, MCP changes the control question from preventing login to governing how trusted non-human identities behave once they can chain actions across tools.

👉 Read Unosecur's analysis of Model Context Protocol and hidden identity risk

Context

Model Context Protocol, or MCP, is an open way for AI agents to discover tools, request data, and execute actions inside enterprise systems. The governance gap is that conventional IAM controls were designed around discrete applications and human-driven workflows, not autonomous software that can maintain context while crossing system boundaries.

Once an agent can call APIs, query databases, and trigger workflows, every interaction becomes an access decision rather than a simple request. That makes MCP a non-human identity issue as much as an AI issue, because the risk comes from how permissions, context, and trust combine in production. This starting point is now typical, not exceptional, as more teams move agents from sandbox to operational use.

Key questions

Q: How should security teams govern AI agents that use Model Context Protocol?

A: Treat each agent as a non-human identity with scoped authority, short-lived credentials, and runtime policy checks on tool use. Governance should cover discovery, execution, and revocation, not just initial authentication. The goal is to prevent an approved agent from chaining ordinary actions into an unsafe outcome across systems.

Q: Why does Model Context Protocol create identity risk for enterprises?

A: MCP creates identity risk because it allows autonomous software to act across live systems with valid permissions and persistent context. That means the central control issue is not whether access exists, but whether that access is appropriate at each step of execution. Identity governance must therefore extend into runtime behaviour.

Q: What is the difference between securing an AI model and securing an MCP-enabled agent?

A: Securing a model focuses on output quality and prompt safety. Securing an MCP-enabled agent focuses on identity, tool permissions, credential lifetime, and the downstream systems the agent can affect. In practice, the second problem is broader because the agent can take real actions, not just generate text.

Q: When do MCP controls become more important than prompt guardrails?

A: MCP controls matter most when the agent can access production tools, sensitive data, or operational workflows. Prompt guardrails can shape language, but they do not limit which systems the agent can reach or how far a permitted action can cascade. Once execution is real, access control becomes the priority.

Technical breakdown

How MCP changes identity and access boundaries

MCP standardizes the relationship between an AI client and the servers that expose tools or data. The model no longer remains a passive responder; it can discover capabilities, request resources, and receive structured outputs that drive follow-on actions. That architecture matters because the agent is now operating with identity, authorization, and context, not just inference. The security issue is transitive trust. If an MCP server is trusted once, the agent may carry that trust into downstream systems, even when the resulting action was not intended by a human operator. In practice, this expands the attack surface from a single conversation to an execution chain.

Practical implication: Map every MCP-enabled action to the identity that authorizes it, the tool it reaches, and the downstream system it can affect.

Why valid access still creates risk in MCP workflows

MCP risk often appears without a classic exploit. An agent can authenticate successfully, call approved tools, and still produce unsafe outcomes because the problem is over-scoped authority plus persistent context. Prompt injection can redirect tool use, poisoned tool metadata can reshape behaviour, and broad token scope can let actions cascade across systems. Traditional security tooling often misses this because the activity looks legitimate from an authentication perspective. The failure mode is not broken access control in the narrow sense. It is authorised access behaving in a way that no one revalidated at each step.

Practical implication: Treat allowed activity from agents as something to continuously constrain, not something to trust after initial authentication.

Trusted continuity drift in agentic systems

A useful way to understand MCP failure is trusted continuity drift. Context is accumulated across tool calls, permissions are reused across workflows, and earlier assumptions are carried forward without a fresh policy check. That creates a path where every individual step is legitimate but the end state is harmful. The architecture is especially risky when tokens persist longer than the task, when tool permissions are granted broadly to avoid breaking workflows, or when teams assume that internal placement equals safety. The technical lesson is simple: context and authority must be revalidated, not inherited indefinitely.

Practical implication: Shorten credential lifetimes, re-check context before each high-risk action, and separate tool permissions by task scope.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a legitimate-seeming execution path for data exposure, workflow abuse, or unauthorized operational change.

1. Entry occurs when a manipulated prompt or poisoned tool response steers an MCP-enabled agent toward an unintended workflow while the agent remains authenticated.
2. Escalation occurs when the agent reuses persistent credentials and broad tool permissions to chain actions across systems without a fresh human review.
3. Impact occurs when the agent exposes sensitive data, updates records, or triggers operational actions that were never meant to be delegated end to end.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 is not a plugin layer, it is an identity expansion event. The protocol turns AI systems into actors that can discover tools, request access, and execute actions across enterprise services. That means the security boundary shifts from the model to the authority attached to the model. CISOs should treat every MCP connection as a new non-human identity with a defined blast radius, not as a convenience integration.

Trusted access is the real MCP vulnerability. The protocol does not become dangerous because it exists, but because teams often combine broad permissions, persistent credentials, and assumed trust in internal servers. That combination creates a governance gap where valid activity can still be harmful. Security teams should focus on scope, lifecycle, and revalidation rather than on blocking the protocol itself.

Trusted continuity drift: this is the control failure that matters most for MCP-enabled environments. Once context survives across actions and systems, the organisation starts relying on yesterday's assumptions to authorise today's execution. The practical implication is that policy must be enforced at runtime, not just at onboarding or initial connection.

Conventional IAM is necessary but not sufficient for agentic systems. Role assignment and authentication still matter, but they do not answer whether an autonomous actor should keep the authority it already has. That is why NHI governance, lifecycle controls, and behavioural monitoring need to sit alongside identity infrastructure. Practitioners should plan for continuous oversight, not static approval.

MCP governance will increasingly converge with agentic AI security frameworks. The category is moving toward controls that reason about tool use, context poisoning, and delegated authority rather than only login events. Teams that build around that model will adapt faster than those waiting for a perimeter-style fix. Practitioners should align policy with how agents actually chain work.

From our research:

• 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%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree that governance is critical to enterprise security, according to AI Agents: The New Attack Surface report.
• For a broader view of where agentic risk sits in the NHI lifecycle, see the Ultimate Guide to NHIs for lifecycle, visibility, and access-control patterns that can be adapted to MCP.

What this signals

Trusted continuity drift will become a core planning concept for teams running MCP-connected agents. The practical issue is not just exposure at the point of access, but the way context, permissions, and tool use accumulate across a workflow. Teams should expect their IAM review model to shift from periodic approval to continuous revalidation, especially where agent actions can reach production.

With 80% of organisations already seeing agents act beyond intended scope, the governance problem is no longer hypothetical. That figure should push programmes to treat MCP as part of the NHI control plane, not as a sidecar to application security. The right response is to align policy, lifecycle, and monitoring before scale increases further.

For practitioners

• Inventory every MCP-connected agent and server Document each agent, the servers it can discover, the tools it can call, and the production systems those calls can reach. Include delegated access paths and any persistent tokens that survive beyond a single task.
• Shorten credential lifetimes for agent workflows Replace long-lived secrets with task-scoped credentials wherever possible, and reissue them only for the duration of the workflow. Pair that with explicit revocation when the task ends or the agent changes context.
• Apply runtime policy to tool chaining Require policy checks before high-risk actions such as data export, record updates, or workflow triggers. Do not rely on initial authentication alone, because MCP risk emerges when a sequence of valid actions is allowed to accumulate.
• Separate discovery from execution authority Allow an agent to inspect available tools without automatically granting the right to use them. This reduces the chance that trusted continuity drift turns one approved capability into a broad execution path.

Key takeaways

• MCP turns AI agents into operational identities, which means access governance matters as much as model safety.
• A large share of organisations are already seeing agent behaviour drift beyond intended scope, including data exposure and unauthorised system access.
• The practical response is runtime control: shorten credentials, limit tool scope, and revalidate context before high-risk actions.

Key terms

• Model Context Protocol: An open protocol that lets AI clients discover and use tools or data sources through standardised server interfaces. In security terms, it matters because it converts model output into executable action paths, which means identity, permissions, and trust become part of the threat model.
• Trusted Continuity Drift: A failure pattern where an AI agent keeps using earlier context, permissions, or assumptions without fresh validation. It is dangerous because each step can look legitimate on its own, while the combined sequence produces an outcome that no one explicitly reapproved.
• Non-Human Identity: A digital identity used by software rather than a person, such as a service account, token, certificate, or autonomous agent. For governance, it is the object through which machines receive authority, which makes lifecycle control, scope, and revocation central security concerns.
• Tool Poisoning: A manipulation technique where an agent trusts misleading or compromised tool metadata, descriptions, or server responses. The result is that the agent is steered toward actions that remain technically authorised but are operationally unsafe, because the decision inputs have been corrupted.

What's in the full article

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

• A plain-language walkthrough of how MCP clients, servers, and tool calls fit together in production deployments.
• The article's own risk taxonomy for prompt injection, tool poisoning, and privilege escalation through legitimate access.
• The practical control checklist the vendor recommends for agent identities, token lifecycle, and runtime monitoring.
• Examples of where MCP appears inside real enterprise workflows such as development, automation, and cross-system orchestration.

👉 Unosecur's full post covers the MCP failure modes, trust assumptions, and identity-control implications in more detail.

Deepen your knowledge

MCP governance and agent identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to formalise policy for autonomous tools, the course helps translate those decisions into operating practice.