MCP as an identity control plane for AI agents and governance

At a glance

What this is: This analysis argues that MCP is becoming the distributed control plane for AI agents, with survey results showing strong adoption intent and security shaping the buying decision.

Why it matters: Identity teams need to decide whether MCP becomes the enforcement point for agent authentication, scoped access, and audit, or another layer of unmanaged delegation.

By the numbers:

• 61% are using MCP with AI Agents today.
• 73% plan to expand their use of MCP.
• 77% of those not using MCP today plan to do so soon.
• 30% said security was the most important factor influencing future MCP choices.

Context

MCP is a protocol layer that can sit between AI agents and the tools they use, which makes it a natural place to concentrate identity, authorization, and audit decisions. The governance question is whether that layer becomes a control plane or just another connector surface with fragmented policy.

Astrix Security’s survey points to broad near-term adoption, but the real issue is operational. When agents can reach multiple tools through a shared abstraction, security teams need to decide where identity is asserted, how privilege is scoped, and where evidence is collected.

The article frames MCP as an identity fabric for AI scaling safely, which is a useful lens for both autonomous and non-autonomous agent programs. That framing is typical of where the market is heading: from tool integration toward policy enforcement at runtime.

Key questions

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.

Q: What breaks when MCP tools are treated as trusted by default?

A: When MCP tools are trusted by default, a poisoned or spoofed component can inherit privileged access, manipulate outputs, or expose secrets without crossing a traditional perimeter. The failure is not only technical compromise. It is the assumption that registration equals trust. Teams should verify provenance, scope permissions tightly, and review tool behaviour continuously.

Q: Why do short-lived credentials matter more for agentic AI than for ordinary apps?

A: Agentic systems can request, use, and discard access inside a narrow runtime window, so long-lived credentials create unnecessary exposure between actions. Short-lived credentials reduce the time available for misuse and make revocation meaningful at task completion. They matter because the control problem is runtime access, not only initial authorisation.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Technical breakdown

Why MCP behaves like an identity control plane

MCP standardises how agents discover and reach tools, which means it can also standardise how those agents are authenticated and authorized. In practice, that shifts control from each downstream tool to the layer that brokers access. If the broker knows the agent, the task, and the scope, policy can travel with the session rather than being re-created in every integration. That is why MCP matters to IAM and NHI teams: it changes where access decisions are made and where audit evidence can be attached.

Practical implication: Treat the MCP layer as the place to define and enforce agent identity, token scope, and action-level audit.

How token scope and server trust shape MCP risk

The security risk in MCP is not the protocol itself but the trust assumptions around servers, tokens, and tool reach. If an agent receives broad credentials, the abstraction layer can accelerate misuse just as easily as legitimate work. Short-lived, audience-scoped tokens reduce the persistence of that risk, while server trust policies limit which tools an agent can reach at all. Without those controls, MCP can hide privilege creep behind a clean interface.

Practical implication: Limit agent tokens to the smallest audience and lifetime that the task actually requires.

Why role-aware access matters more than simple connectivity

MCP is only useful for governance when access is tied to role, context, and purpose rather than generic connectivity. A finance agent, for example, should not inherit the same tool set as a support agent merely because both can reach MCP servers. Role-aware access makes policy portable across integrations and prevents the abstraction layer from becoming a privilege amplifier. This is especially important where the same agent can invoke multiple systems in a single session.

Practical implication: Map every MCP-connected agent to explicit roles, context rules, and approved tool sets before broad rollout.

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.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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 becoming the policy enforcement layer for AI agents, not just an integration protocol. Once multiple tools are reachable through one abstraction, the control question moves from individual app permissions to centralised identity and authorization at the broker. That is a governance shift, not a convenience feature. Practitioners should treat MCP as the point where agent access either becomes governable or becomes invisible.

Security-first MCP adoption will depend on whether teams can bind every agent action to a durable identity and a bounded purpose. The article’s survey data shows strong intent to expand use, but adoption intent does not solve accountability. Persistent agents, ephemeral agents, and shared server access all require different governance treatment. The implication is that identity architecture now has to distinguish the agent, the owner, and the session context.

Identity fabric only works if server trust is explicit rather than assumed. MCP can centralise policy, but it can also centralise risk if every connected server is implicitly trusted. That makes trust policy, scope design, and audit separation the real control surface. Practitioners should see MCP as a distribution layer for governance, not a substitute for governance itself.

Short-lived credentials become the baseline expectation when agents act through MCP. The article’s own examples point toward audience-scoped tokens, role-aware authorization, and operational visibility. That is consistent with NHI governance practice: the more flexible the access path, the shorter and narrower the credential should be. The conclusion for practitioners is simple: runtime governance has to move as fast as the agent does.

MCP highlights a named concept we should call identity abstraction debt. That debt appears when teams add a clean protocol layer without deciding where identity proof, authorization, and audit will actually live. The result is better connectivity with unresolved governance ownership. For security leaders, the question is not whether to adopt MCP but whether the abstraction pays down or compounds identity risk.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 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.
• Read next: Agentic AI Identity Guide

What this signals

Identity abstraction debt: MCP can reduce integration friction while leaving the real ownership of authentication, authorization, and audit unresolved. That gap matters because each new server or SDK increases the chance that policy lives in the connector instead of the control plane, which is where governance usually starts to leak.

If AI agents are going to scale through MCP, programmes should assume that tool reach will expand faster than manual review capacity. The practical response is to move decisions to issuance time, narrow token scope, and make the broker the only place where access is approved and observed.

For practitioners

• Define MCP as a governance boundary Make the MCP broker the place where agent identity is asserted, scope is issued, and audit is recorded across connected tools.
• Issue short-lived agent credentials Use audience-scoped tokens with the shortest practical lifetime so an agent cannot keep credentials beyond the current task.
• Restrict server trust by task type Approve specific MCP servers for specific work so agents do not inherit a generic route to every available tool.
• Map persistent agents to owners Bind each persistent agent to a human or service owner so reviews, approvals, and incident investigations have a clear accountability path.
• Stream MCP events into detection workflows Forward MCP audit events into SOC tooling and flag abnormal tool use, unexpected server reach, or repetitive high-risk actions.

Key takeaways

• MCP is shifting from a developer convenience layer into a governance boundary for AI agents, which changes where identity and policy must be enforced.
• The article’s survey data shows strong adoption intent, but it also shows that security is the deciding factor for most teams.
• Practitioners need to bind agents to owners, scope server trust, and issue short-lived credentials before MCP becomes a privilege amplifier.

Key terms

• MCP Control Plane: The policy layer that governs which identities can reach which MCP servers and tools. In practice, it centralises registration, authorisation, and audit so access does not depend on the specific AI client a person or workflow happens to use.
• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.
• Server Trust Policy: A governed rule set that determines which MCP servers an agent may use and under what conditions. It combines ownership, approval status, and permitted use so that protocol compatibility does not become blanket trust. Without it, distributed agent access becomes difficult to control or investigate.
• Identity Abstraction Debt: Identity abstraction debt is the governance gap created when a shared protocol simplifies integrations faster than identity ownership, authorization, and audit are defined. The system appears easier to use, but the organisation carries unresolved control decisions into production.

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.