MCP can become an AI identity control plane for enterprise IAM

At a glance

What this is: MCP is emerging as a central identity and policy chokepoint for AI agents, with the key finding that governance shifts from scattered tool controls to a single enforced boundary.

Why it matters: This matters because IAM, NHI, and PAM teams can no longer treat AI tool access as isolated integrations; MCP changes where identity, policy, and audit must live.

👉 Read Astrix Security's analysis of MCP as an AI identity control plane

Context

Model Context Protocol is becoming the place where AI agent identity either becomes governable or remains fragmented. The problem is not MCP itself, but the fact that tool access, authorisation, and audit all collapse into one layer that IAM teams can either control centrally or lose entirely.

For identity teams, the real question is whether MCP acts like a brokered security boundary or a convenience layer that hands out privilege too widely. That distinction matters for service accounts, proxy identities, and agent-to-tool delegation, because the same control point can either reduce sprawl or concentrate failure.

The security upside is obvious: a central control plane can make AI agent actions attributable, policy-checked, and auditable. The operational risk is just as clear: if the MCP layer is not bound to enterprise identity governance, it becomes a new place to hide standing privilege and orphaned access.

Key questions

Q: How should security teams govern AI agent access through MCP?

A: Treat MCP as the decision layer for identity, not a transport convenience. Every tool request should be tied to a scoped principal, evaluated against enterprise policy, and recorded in an audit trail that links back to an owner. That gives IAM teams one place to enforce least privilege and revoke access consistently.

Q: When does MCP create more risk than it reduces?

A: MCP creates more risk when it centralises access without centralising governance. If the layer accepts broad tokens, lacks request-level authorisation, or cannot trace actions back to a principal, it becomes a high-value control point with weak accountability. In that case, it concentrates exposure instead of reducing it.

Q: What do teams get wrong about AI agent identity and MCP?

A: Teams often assume that a protocol layer automatically solves governance. It does not. If the agent still holds direct secrets, broad scopes, or unreviewed delegation paths, MCP only hides the sprawl behind a nicer integration surface. The control model has to change, not just the plumbing.

Q: Should organisations map AI agents to service-account style controls?

A: Yes, when the agent is acting on behalf of a business process rather than a person. Service-account style controls give teams a familiar way to manage scope, ownership, logging, and offboarding. The key is to add policy checks and audit at runtime, not only at provisioning.

Technical breakdown

MCP as an identity control plane for AI agents

MCP is useful as a control plane because it sits between the agent and the tools it wants to use. Instead of allowing every agent to call every API directly, the MCP layer can broker identity, map the requester to an enterprise principal, and enforce policy at request time. That turns the protocol into a central decision point for authentication, authorisation, and audit. In practice, this is the architectural shift that makes AI agent actions governable at scale rather than scattered across custom integrations.

Practical implication: treat MCP as a security boundary and attach policy, identity, and logging to the layer that brokers tool access.

Proxy identities, signed tokens, and scoped tool requests

The article’s model uses a proxy identity rather than raw secrets. That means an agent presents a signed token, the MCP server validates it, and the request is checked against allowed scopes before any tool executes. This is materially different from handing an agent direct API keys, because the identity assertion can be linked back to roles, owners, and policy. When done well, the control pattern resembles service-account governance more than ad hoc automation, with each action tied to a verifiable principal and a bounded permission set.

Practical implication: replace direct secret distribution with scoped, verifiable identities that can be reviewed and revoked centrally.

Continuous authorisation and audit at the MCP layer

The deeper value of MCP is not just initial login, but continuous enforcement across every tool request. If the server checks policy each time, it can support dynamic approval, time-bound access, and action-level logging without rebuilding auth in every downstream tool. That also creates a cleaner audit trail because the decision, the request, and the outcome live in one place. For IAM and NHI teams, this is the difference between a system that merely routes calls and one that actually governs them.

Practical implication: require request-by-request policy evaluation and immutable audit logging before MCP deployment expands.

Threat narrative

Attacker objective: The objective is to use agent-driven tool access to reach systems and data with insufficient identity controls while avoiding clear accountability.

1. Entry occurs when an AI agent is given direct tool access without a governed MCP boundary, allowing it to start calling downstream systems with broad or unscoped privilege.
2. Credential access or abuse follows when raw API keys, shared tokens, or weak proxy identities let the agent act outside the intended enterprise identity context.
3. Impact occurs when the agent can execute sensitive actions without consistent authorisation or audit, making misuse hard to attribute and harder to contain.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 an identity boundary, not just a developer convenience layer. The central issue is where control lives. If authentication, authorisation, and logging are pushed into the MCP layer, organisations can finally govern AI agent access as a coherent identity problem instead of a collection of tool-specific exceptions. That makes MCP relevant to IAM, PAM, and NHI governance at the same time, which is where the category is heading.

Raw secrets are the wrong primitive for AI agent access. The article’s proxy-identity model reflects a broader shift away from handing agents direct credentials. Once agent actions are mediated through signed tokens and enterprise policy, the identity programme can reason about ownership, scope, and revocation. The practitioner takeaway is that agent access should be represented as governed identity state, not embedded as static credentials.

Centralising policy at the MCP layer can either reduce sprawl or concentrate risk. A single chokepoint improves consistency, but it also raises the stakes if that layer is weakly governed or loosely integrated with the enterprise identity stack. The implication is that security teams must treat MCP as critical identity infrastructure, not middleware.

Governance for AI agents is converging with service-account discipline. The article shows that teams are already mapping agent requests to roles, scopes, and audit trails much like workload identity. That matters because the field is moving toward a shared control model where agents, service accounts, and other NHIs are governed by the same lifecycle and privilege logic.

Fine-grained capability discovery is the next pressure point. Once MCP becomes the identity and policy layer, the open question is not whether access exists, but how precisely capability boundaries are exposed and enforced. That forces practitioners to rethink least privilege as a runtime property of the protocol layer, not a static provisioning exercise.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why identity sprawl persists even where governance programmes exist.
• For a broader identity baseline, see Top 10 NHI Issues, which frames visibility, rotation, and privilege as connected control failures rather than separate tasks.

What this signals

MCP governance will increasingly look like workload identity governance. As agents move from direct tool use to brokered access, teams will need to align MCP policies with existing identity, access, and audit processes rather than treating the protocol as a standalone layer. That is where the operational work begins: ownership, scope, revocation, and traceability must all line up.

Identity programmes should expect the control plane to become the new choke point. With so many NHIs already in play, the challenge is not adding one more integration layer but ensuring that layer is deterministic enough to withstand scale. Organisations that cannot explain who or what is allowed to do what through MCP will struggle to prove least privilege in practice.

AI agent access will follow the same lifecycle logic as other NHIs, but with tighter runtime pressure. The difference is that request timing, tool selection, and policy enforcement happen faster than traditional review cycles. Teams that want to stay ahead should prepare to govern agent identities with continuous checks rather than periodic trust assumptions.

For practitioners

• Define MCP as a governed identity boundary Map every MCP server to an enterprise control owner, an approved policy source, and a logging destination before letting agents use it in production.
• Replace direct API keys with proxy identities Issue signed, scoped identities for agent requests and tie them to a human owner or workload record so access can be revoked without hunting through tool configurations.
• Enforce request-level authorisation Require the MCP layer to evaluate policy on every tool call, including step-up approval for unusual actions, sensitive data access, or cross-domain requests.
• Log agent actions as auditable identity events Store who or what made the request, which scope applied, what tool was touched, and whether approval was granted in an immutable audit stream.

Key takeaways

• MCP can either centralise AI identity governance or conceal new privilege sprawl, depending on where policy is enforced.
• AI agents should be governed through scoped, auditable proxy identities rather than direct secret distribution.
• The practical test for MCP is simple: every tool action must be attributable, policy-checked, and revocable from one control point.

Key terms

• Model Context Protocol: A brokered interface that lets AI agents connect to tools and data sources through a common layer. In identity terms, it can become the place where requests are authenticated, authorised, and logged before any downstream action is taken.
• Proxy Identity: A mediated identity used to represent an AI agent or workload when it accesses tools on behalf of a business process. It carries scoped permissions and auditability, which makes agent activity governable without exposing raw credentials.
• Identity Control Plane: The layer where policy decisions, identity assertions, and audit events are centralised for enforcement. For AI agents and other NHIs, this is the difference between scattered tool-level access and a single place to apply least privilege and accountability.
• Scoped Token: A credential that limits what a non-human identity can do, where it can do it, and for how long. In governed agent systems, scoped tokens replace broad static secrets and help keep access tied to a specific task or role.

What's in the full article

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

• How their survey respondents are thinking about MCP rollout, governance pressure, and security readiness in more concrete terms.
• The specific pattern they describe for MCP gateways, signed tokens, and role mapping across tool requests.
• The examples of how teams are tying MCP tool access to enterprise IAM systems and logging workflows.
• The future-facing security features the article says are still maturing in the MCP ecosystem.

👉 Astrix Security's full post covers MCP gateway patterns, token handling, and the security features teams are waiting for.

Deepen your knowledge

MCP identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing agent access controls around a brokered control plane, this is a strong fit for your programme.