MCP turns AI agents into identity and access decisions

At a glance

What this is: This article argues that Model Context Protocol makes AI agents an identity and access governance problem because it gives them real authority inside production systems.

Why it matters: IAM, NHI, and PAM teams need to treat MCP-enabled agents as governed identities, because trusted access paths can amplify risk without any obvious authentication failure.

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

👉 Read Unosecur's analysis of MCP and the hidden identity risk behind agentic AI

Context

MCP is an open protocol that lets AI systems discover tools, request data, and act inside business workflows. That changes the security model from simple model output to real execution, which means identity, permissions, and trust become the controls that matter most for MCP server security and agentic AI governance.

The governance gap is not that AI can talk to tools. It is that tool access now sits inside production systems where credentials persist, permissions accumulate, and legitimate requests can still produce harmful outcomes. In that environment, traditional perimeter thinking is too coarse for NHI and agentic AI risk.

For identity programmes, MCP should be read as a lifecycle and authorisation problem. The core question is not whether an agent can call a tool, but who governs the identity, scope, and duration of that authority as the agent moves across systems.

Key questions

Q: What breaks when MCP agents are given broad permissions?

A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity. The agent can read, write, and trigger actions beyond the original workflow, which makes tool poisoning, credential theft, and accidental misuse far more damaging. Least privilege is the control that limits how far the delegation chain can spread.

Q: Why do MCP servers create new NHI governance concerns?

A: MCP servers create new NHI governance concerns because they expose application capability to non-human callers through tools and prompts that can be invoked at runtime. That shifts the question from who can reach an API to what an agent is allowed to decide and execute. The governance challenge is preventing the agent from inheriting broader privilege than the user or workflow intended.

Q: What do security teams get wrong about prompt guardrails?

A: Teams often treat prompt guardrails as if they were authorisation controls, but they are only one layer of defence. A model that filters unsafe language can still execute hidden instructions inside legitimate content if tool permissions are broad. Guardrails reduce exposure, but they do not replace separate approval checks for sensitive actions.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Technical breakdown

How MCP maps AI agents to production tool access

MCP defines a structured way for an AI client to discover servers, request tools, and receive machine-readable responses that the model can act on. That removes custom integration work, but it also means the agent is no longer just generating text. It is issuing operational requests into live systems with authenticated access, which makes each tool call an identity event as well as a software event. Once an MCP server is connected to CRM, HR, ITSM, or internal data sources, the protocol becomes an execution layer that can inherit whatever trust, scope, and persistence already exist in the underlying identities.

Practical implication: treat every MCP connection as governed access, not a harmless integration shortcut.

Why trusted context can become a hidden control plane

MCP agents carry context forward across multiple actions, and that context can be manipulated by user input, upstream tools, or server metadata. The risk is not only prompt injection. It is that the agent may use valid credentials to take a sequence of valid actions while following corrupted assumptions. In identity terms, trusted continuity becomes the control plane. If context is not revalidated, the agent can keep acting on stale or poisoned state even though every access check still passes.

Practical implication: monitor context lineage and tool metadata, not just successful authentication events.

Why legitimate access is still a breach condition in MCP environments

Traditional detection is tuned to spot unauthorized access, malware, or policy violations. MCP risk often lives in the opposite pattern: the agent is authenticated, the permissions are real, and the actions look normal to logging systems. That is why over-entitlement, transitive trust, and persistent tokens matter so much. The failure mode is not a broken login. It is a valid identity operating across too many tools for too long, with no strong boundary around what it should be able to do next.

Practical implication: analyse privilege paths across tools and limit the duration of any credential that can chain actions.

Threat narrative

Attacker objective: The objective is to convert trusted AI-driven access into unauthorized business actions and data exposure without triggering traditional breach signals.

1. Entry occurs when an attacker injects manipulated content or poisons an MCP server so the agent receives a compromised instruction or tool description.
2. Escalation occurs when the agent uses valid credentials and trusted context to call additional tools, broaden access paths, or chain actions beyond the original intent.
3. Impact occurs when those legitimate actions expose sensitive data, trigger destructive workflow changes, or propagate unsafe context across production systems.

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 is an identity expansion event, not an AI feature release. The protocol turns AI systems into actors that can request tools, carry context, and execute inside production workflows. That means every deployment decision is also an identity governance decision, because access scope and trust now travel with the agent. Practitioners should stop treating MCP as a connector and start treating it as a governed authority layer.

Trusted continuity is the hidden failure mode in MCP environments. The protocol allows context to persist across tool calls, which means a manipulated instruction can survive long enough to shape later actions. This is not the same as a one-off prompt injection problem. The real issue is that normal-looking activity can remain harmful when the system never re-establishes trust at each step, and that breaks the assumption that valid access equals safe access.

Broad permissions are the default path to invisible agent sprawl. When teams widen scopes so workflows do not break, they create authority that is difficult to review, recertify, or revoke later. That is a classic NHI lifecycle problem, but MCP makes it move faster because the agent can coordinate across systems without a human in the loop. Identity teams should expect more policy drift unless scope is tied to task, time, and tool.

Runtime governance has to move ahead of scale, or MCP will normalise privilege creep. Static policy documents do not control how an agent behaves after authentication, and perimeter tools rarely understand chained tool use. The field needs a governance model that covers discovery, lifecycle, and behavior monitoring together, because MCP changes the unit of control from single credentials to continuously acting identities. Practitioners should align governance with execution, not with intent.

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.
• 52% of companies can track and audit the data their AI agents access, which means 48% still operate with a complete compliance and investigation blind spot.
• For a governance framework that aligns with this risk, see OWASP Agentic AI Top 10 for runtime controls and tool-abuse scenarios.

What this signals

Identity blast radius: MCP will push security teams to judge agents by the breadth of systems they can influence, not by whether a login succeeded. With 80% of organisations already seeing AI agents act beyond intended scope, per the AI Agents: The New Attack Surface report, the programme risk is no longer theoretical.

The next maturity step is to unify discovery, lifecycle, and runtime monitoring for agent identities. Teams that separate development enablement from identity governance will miss the point where context, permissions, and persistence combine into operational risk.

Enterprises should also prepare for policy overlap between MCP, agentic AI governance, and classic NHI controls. The practical answer is a single authority model that can classify, scope, and revoke non-human access across agents, service accounts, and delegated tools.

For practitioners

• Discover every MCP-connected identity Inventory clients, servers, service accounts, tokens, and delegated pathways before production rollout. Map which tools each agent can reach, which credentials they inherit, and where those credentials are reused across workflows. Use that map to identify hidden privilege chains and unmanaged access paths.
• Scope tool access by task and time Limit MCP permissions to the minimum set of tools needed for a defined workflow and remove persistence wherever possible. Avoid broad server-level trust, and prefer short-lived credentials that expire when the task ends.
• Monitor context drift and chained actions Track sequences of tool calls, not just single requests. Flag agents that combine unrelated actions, move across systems unexpectedly, or continue using stale context after the original trigger has changed.
• Govern lifecycle events for agent identities Apply joiner, mover, and leaver controls to agents, tokens, and MCP server integrations. Revoke credentials when a tool path changes, a project closes, or the underlying data access no longer has a business justification.

Key takeaways

• MCP turns AI integration into an identity governance problem because agents can now act inside production systems with real authority.
• The hardest failure mode is trusted continuity, where valid access and persistent context allow harmful actions without obvious security alerts.
• Security teams need lifecycle control, scope reduction, and runtime monitoring before MCP deployments become normalised privilege sprawl.

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.
• Trust Continuity: Trust continuity is the ability of an identity system to preserve context, confidence, and safe access across devices, sessions, and channels. In practice, it is the measure of whether the customer experiences the business as consistent, respectful, and secure at every step.
• Identity Expansion Event: A change in architecture that adds materially more identities, credentials, and authority paths to an environment. For MCP, this means each agent, server, token, and delegated workflow becomes part of the identity surface and must be governed as such.
• Privilege path: A privilege path is the route an identity uses to move from ordinary access to sensitive systems, data, or administrative functions. It can involve accounts, tokens, roles, or delegated permissions, and it often determines whether a vulnerability becomes a real incident.

What's in the full article

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

• Concrete examples of MCP risk patterns in production workflows, including tool misuse and transitive trust.
• Operational guidance for deciding where agent credentials should be short-lived versus persistent.
• The article's own framing of how developers, platform teams, and security teams divide responsibility.
• The vendor's examples of where traditional IAM and perimeter controls fail to see legitimate but unsafe agent activity.

👉 The full Unosecur post covers MCP abuse patterns, trusted continuity drift, and identity-first controls in more detail.

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 IAM programme, it is worth exploring.