MCP server identities and Zero Trust for AI agents

At a glance

What this is: This is a Cerbos analysis of why MCP-connected AI agents need first-class identities, fine-grained authorization, and delegation-aware controls rather than shared secrets.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent access as runtime identity behaviour, not just as another application integration.

By the numbers:

• AI agents dominated the conversation at KubeCon North America 2025, with every other conversation focused on agentic systems.

Context

MCP-connected AI agents create an identity problem, not just an integration problem. If an agent can call tools, query data, or trigger actions, the security model has to answer who that agent is, what it is allowed to do, and how those decisions are enforced at runtime.

The article argues that static API keys, shared service accounts, and undifferentiated user impersonation do not fit that model. Zero Trust for agentic systems requires unique identities, scoped delegation, and policy checks at the point of use, especially when the agent is acting on behalf of a person or across multiple tools.

The underlying governance issue is that current controls were built for stable application accounts and human-paced review cycles. MCP increases the number of tool relationships and makes authorization decisions more dynamic, so identity governance has to move closer to the request path.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do static API keys become risky in AI agent and MCP environments?

A: Static API keys become risky because dynamic AI workloads move fast, touch multiple tools, and often duplicate credentials across components. Once a reusable secret is copied into several places, rotation and revocation become partial at best. The risk is not only theft, but also untracked persistence across transient execution paths.

Q: What breaks when AI agents rely on shared service accounts or API keys?

A: Shared credentials hide which actor actually performed the action, make revocation coarse, and blur accountability across humans and machines. They also let multiple agents inherit the same authority, which increases blast radius and makes incident investigation much harder when something goes wrong.

Q: What should teams do when AI agents act on behalf of real users?

A: Treat the agent as a scoped identity with explicit permissions, audit trails, and revocation rules. The human owner should be verified strongly, but the agent still needs its own access boundaries. That prevents delegated activity from becoming invisible shadow access.

Technical breakdown

Why MCP changes the identity boundary for AI agents

Model Context Protocol standardises how an AI client discovers and calls tools, but it does not by itself establish trust. The moment an agent can invoke a remote server over HTTP or local transport, the tool call becomes an identity event that needs authentication, authorization, and audit context. That changes the boundary from “application integration” to “identity-mediated action”. In practical terms, an MCP server is not just a utility endpoint. It is a policy decision surface because it exposes real business capability to a runtime that may act independently of a human at every step.

Practical implication: treat every MCP server as a governed identity endpoint, not as a neutral tool catalogue.

Why static API keys and broad service accounts fail Zero Trust

API keys are bearer secrets, so whoever holds them can use them with little or no built-in context. In agentic environments, that creates a wide trust span because the credential does not encode who the agent is, which user it represents, or which action it may perform. Broad service accounts make the problem worse by pooling access into a single reusable identity. Zero Trust expects each request to be authenticated and authorized on its own merits, which is why short-lived, scoped credentials and policy-backed claims are a better fit than long-lived shared secrets.

Practical implication: replace reusable secrets with short-lived delegated credentials tied to a specific agent and task.

How on-behalf-of delegation and embedded policy checks constrain agent behaviour

On-behalf-of flows let an agent exchange a user-linked token for a narrower downstream token, preserving both accountability and least privilege. Instead of letting the agent hide behind a human session, the service can see that the request came from a specific agent acting for a specific subject. Embedded or service-side policy decision points then evaluate whether the requested action matches the token, the user’s rights, and the current context. This is the mechanism that keeps agentic behaviour auditable without granting ambient authority across every connected tool.

Practical implication: require token exchange and policy evaluation before the agent reaches the target API or data source.

Threat narrative

Attacker objective: The attacker objective is to abuse weak MCP credentialing to reach internal tools and perform actions without clean identity boundaries or reliable accountability.

1. Entry occurs when an AI agent is given a static API key, a shared service account, or a user session that can reach MCP servers and related tools.
2. Escalation follows when the credential exposes more tools or broader scopes than the current task requires, letting the agent act across systems without fresh authorization.
3. Impact is the loss of identity separation and auditability, because actions appear to come from a generic account or from the human user instead of from the agent.
4. The objective is to prevent agents from becoming uncontrolled pathways into internal systems while preserving traceable, scoped access.

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

Zero Trust for AI agents fails if the agent is treated like an application handle instead of an identity-bearing actor. The article shows that MCP makes tool use runtime-visible, but visibility alone does not create governance. Identity-aware access is the only defensible basis for deciding which tools an agent may call, which user it represents, and how those decisions are logged.

Static API keys are not just weak secrets, they are a governance shortcut that collapses authorisation context. A bearer token does not express agent purpose, task scope, or delegation chain, so it cannot support the policy precision that MCP environments now require. Practitioners should read this as a sign that secret-centric access models are already out of step with agentic operations.

On-behalf-of delegation is the right control pattern because it preserves actor separation. The important point is not simply shorter-lived credentials, but that the downstream service can still distinguish the user, the agent, and the action. That distinction is what makes accountability, review, and escalation control possible across human, NHI, and agentic workflows.

Agentic trust debt is accumulating wherever organisations connect tools before they define the delegation model. The article’s concern is structural: MCP adoption expands the number of places where identity decisions must happen, yet many teams still rely on inherited application patterns. That means the next wave of governance work will centre on scope, provenance, and request-time authorisation rather than on perimeter trust.

Access review processes were designed for privileges that persist long enough to be reviewed, and that assumption weakens under agentic execution. When an agent can request, use, and discard access inside a task flow, the review window moves to issuance time, not recertification time. Practitioners need to rethink governance around transient, runtime-checked authority rather than inherited standing access.

From our research library:

• Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
• Read next: AI Agent Authorisation Guide

What this signals

Agentic trust debt: Once organisations connect tools to agents before they define delegation, they accumulate access paths that are hard to explain, hard to audit, and easy to over-privilege. The control question shifts from whether the agent can call a tool to whether the request path proves who is acting and on whose behalf.

MCP adoption will push identity teams to move policy earlier in the flow, because review-based governance cannot compensate for ambient access granted at setup time. The practical test is whether every tool invocation can be tied to a scoped token, an actor, and a decision record.

This matters because the surface area is expanding quickly: MCP configuration files exposed 24,008 unique secrets in 2025 alone, according to the State of Secrets Sprawl 2026. Secrets that seep into agent tooling turn authorization design into a containment problem, not just a provisioning problem.

For practitioners

• Define agent identities before tool exposure Assign each AI agent a unique identity and separate it from the human user and the host application. Use that identity consistently across MCP servers, logs, and downstream services so actions remain attributable.
• Replace shared secrets with scoped delegation Move away from static API keys and broad service accounts. Use short-lived tokens, OAuth token exchange, or equivalent delegated credentials that are tied to a single user, agent, and task.
• Filter tool visibility by identity and context Expose only the tools, resources, and parameters that a given agent should see. Use policy to suppress sensitive MCP capabilities such as HR, admin, or production operations when they are not task-scoped.
• Place authorization at the request path Enforce policy checks in the MCP server or immediately downstream, not only at onboarding. The server should evaluate who is acting, on whose behalf, and whether the requested operation matches the allowed scope.
• Log delegation chains end to end Record the user, agent, token exchange, tool call, and result in one audit trail. That gives security, IAM, and compliance teams a way to trace actions through a multi-hop delegation path.

Key takeaways

• AI agents connected through MCP need their own identities, because shared secrets and undifferentiated sessions collapse the boundary between user, agent, and tool.
• The article’s central security pattern is delegated, short-lived authority with policy enforced at request time, not static access handed out at setup time.
• For practitioners, the priority is to govern tool exposure, delegation chains, and audit trails before agentic workflows become a new source of standing access.

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.
• On-Behalf-Of Delegation: On-behalf-of delegation is an OAuth pattern that lets one identity act using authority derived from another identity. In agentic systems, it is the mechanism that preserves accountability across chained actions, but it must be paired with traceability and policy context to remain governable.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Agentic Governance Debt: The accumulation of risk when organisations deploy AI agents faster than they build controls for authority, attribution, and containment. It shows up when policy exists on paper but runtime access remains broad, logs are incomplete, or emergency controls cannot act before damage occurs.

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