MCP server identities and Zero Trust for AI agents

At a glance

What this is: This is an analysis of how AI agents, MCP servers, and Zero Trust controls intersect, with the key finding that static secrets and broad access still leave agent workloads under-governed.

Why it matters: It matters because IAM teams now need to govern agent identity, delegated access, and tool-level authorization with the same discipline used for human and machine identities.

👉 Read Cerbos' analysis of MCP server identities and Zero Trust for AI agents

Context

AI agent security is becoming an identity problem before it becomes a tooling problem. When agents can call tools, query data, or act on behalf of users, the question is no longer whether automation is useful, but whether the identity model can keep pace with runtime decision-making and delegated access.

MCP makes that gap visible because it standardises how agents discover and invoke tools, but it does not by itself solve authorisation, tool scoping, or accountability. For IAM teams, the practical issue is whether agents are treated as first-class identities with bounded authority or as convenient wrappers around long-lived secrets.

Key questions

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

A: Security teams should treat AI agents as first-class identities, not as hidden extensions of a user session. Each agent needs its own credential path, its own policy boundary, and its own audit trail. The key control is to scope what the agent can discover and call, then enforce authorisation at the moment of tool use rather than relying on a trusted network perimeter.

Q: Why do static API keys create risk for AI agent access?

A: Static API keys create risk because they are long-lived, reusable, and difficult to tie to a specific action. In an agentic environment, that means the same secret can be replayed across tools, sessions, or workloads long after the original task is complete. Short-lived delegated credentials give teams a much better chance of limiting scope and preserving accountability.

Q: What breaks when MCP tools are exposed without policy controls?

A: Without policy controls, MCP tools become a discoverable privilege surface rather than a governed capability set. An agent may see sensitive tools it should never use, and downstream services may have no reliable way to distinguish approved use from overreach. That makes least privilege impossible to enforce consistently and undermines auditability.

Q: What is the difference between agent authentication and delegation?

A: Authentication proves the agent or the user is who they claim to be. Delegation proves what the agent is allowed to do on someone else's behalf and keeps that authority narrow and visible. For AI agents, delegation is the more important governance problem because it defines the real security boundary for downstream tool calls.

Technical breakdown

How MCP server identity and tool discovery work

Model Context Protocol gives an AI client a standard way to discover tools, prompts, and resources exposed by an MCP server. The server advertises capabilities, the client loads them into context, and the model can invoke tools through structured requests. That design is useful for interoperability, but it also expands the trust boundary: every connected server becomes part of the agent's effective action surface. If discovery is unrestricted, the model may see tools that a user or workload should never have been able to call. The result is not just integration sprawl, but an authorisation problem hidden inside the prompt layer.

Practical implication: scope MCP tool discovery by identity and context before the model ever sees the full tool set.

Why static API keys weaken Zero Trust for agents

The article's central warning is that many agent deployments still rely on static API keys or broad service accounts. In Zero Trust terms, that creates ambient authority: a long-lived credential that can be replayed, leaked, or reused far beyond the task that justified it. By contrast, an identity-bound agent should present short-lived, narrowly scoped credentials that reflect both who initiated the action and what the agent is allowed to do. This is the difference between a shared secret and a verifiable identity with policy attached. Once a key becomes the de facto identity, auditability and least privilege both start to collapse.

Practical implication: replace shared secrets with short-lived delegated credentials that can be traced to a specific agent and user context.

On-behalf-of tokens and embedded policy decision points

A stronger pattern is token exchange, where an agent trades one credential for a downstream token with narrower scope. That lets the system preserve a visible chain of delegation, for example user to agent to tool, instead of letting the agent hide inside a browser session or generic user token. The article also points to embedded policy decision points, which means enforcing authorisation close to the action rather than only at the edge. This is the architectural shift that matters: the control is no longer just authentication, but per-request policy evaluation over an identity chain that the platform can actually audit.

Practical implication: design for visible delegation chains and runtime policy checks at the point where tools are actually called.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity is becoming the control plane for tool-using AI. The article shows that MCP standardisation alone does not create security, because the real risk sits in how identities are issued, scoped, and audited. When an agent can reach tools through broad credentials, the governance problem is no longer prompt quality but access design. Practitioners should treat every agent as a governable identity, not as a feature wrapped around a user session.

Static secret trust debt: This article exposes a familiar NHI failure mode in a new form. Static API keys were designed for stable, low-change service access. That assumption fails when agents discover tools dynamically and execute tasks at runtime. The implication is that teams must rethink whether secret-based access can still support traceable, least-privilege delegation for agentic workloads.

Tool-level authorisation is now part of identity governance, not application plumbing. The important shift is not whether the agent can call a tool, but whether the tool can validate who is acting, for whom, and under what policy. That puts MCP server access control into the same governance domain as workload identity and privileged access. Teams that leave tool permissions outside IAM will create invisible privilege paths that no access review can reliably catch.

Zero Trust for agents depends on proving delegation, not just proving authentication. The article aligns closely with OWASP NHI and Zero Trust thinking because the real challenge is not only authenticating the agent, but preserving the chain of accountability through every downstream call. If the agent can borrow a human session or reuse a broad token, the security model loses the distinction between actor and delegate. Practitioners should prioritise delegation visibility as a governance requirement, not a logging nicety.

Named concept: delegation-chain accountability. This is the practical governance gap the article surfaces. An agent acting on behalf of a user, through MCP and token exchange, needs an identity trail that survives the handoff into downstream systems. Without that, policy enforcement becomes guesswork and forensics become attribution theatre. Security teams should build their programmes around the chain of action, not just the initial login.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That makes the governance question immediate, and the wider agent risk picture is laid out in OWASP Agentic AI Top 10 for teams building policy and containment around autonomous behaviour.

What this signals

Delegation-chain accountability: agent programmes are moving faster than the controls that prove who acted, for whom, and under which policy. With 92% of organisations saying governing AI agents is critical but only 44% having implemented policies, the operational gap is now about enforcement, not awareness.

IAM teams should expect MCP-style integrations to increase pressure on authorisation services, audit pipelines, and policy decision points. The practical response is to map where agent actions cross from human intent into machine execution, then ensure those transitions remain visible in logs, entitlement models, and review workflows.

For practitioners

• Define agents as governed identities Assign each AI agent a unique identity, separate from human users and separate from generic service accounts. Use that identity consistently across MCP clients, downstream APIs, and audit logs so authorisation decisions can be tied to a specific actor.
• Remove long-lived shared secrets from agent workflows Replace static API keys and copied admin tokens with short-lived, scoped credentials issued for a single task or delegation path. Keep secrets out of code and reduce the blast radius of any credential leak.
• Scope tool discovery by policy Filter which MCP tools and resources an agent can see based on user role, agent trust level, and context. Do not expose HR, finance, or sensitive operational tools just because the server advertises them.
• Enforce on-behalf-of delegation end to end Use token exchange or equivalent delegation flows so downstream systems can see both the human subject and the agent actor. Preserve that chain in logs and policy decisions rather than collapsing everything into a single user session.
• Place authorisation close to the action Add embedded policy decision points or service-side PDP checks at the moment a tool call is made. That keeps authorisation aligned with runtime context and prevents agents from crossing privilege boundaries after initial authentication.

Key takeaways

• AI agents create an identity governance problem as much as a tooling problem, because MCP expands the number of places where access can be granted and abused.
• The biggest weakness in current agent security is the persistence of static secrets and broad service accounts, which are incompatible with short-lived, auditable delegation.
• Practitioners should focus on visible delegation chains, scoped tool discovery, and policy checks at the point of action if they want Zero Trust to hold for agents.

Key terms

• MCP server: An MCP server is a tool-exposing service that publishes actions, data, or prompts for an AI client to use. In security terms, it becomes a new access boundary because every advertised capability can be invoked by an agent if policy does not restrict discovery and execution.
• Delegation chain: A delegation chain is the sequence of identities and tokens that shows who initiated an action and which actor executed it. For AI agents, that chain matters because accountability depends on preserving the link between the human subject, the agent actor, and the downstream tool.
• Embedded policy decision point: An embedded policy decision point is an authorisation control placed close to the action being taken, rather than only at a central gateway. In agentic systems, it helps ensure that each risky tool call is checked in context, with the current actor, scope, and resource state.

Deepen your knowledge

MCP server identity, delegated access, and Zero Trust policy enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building agent governance around the same problems, it is worth exploring.

This post draws on content published by Cerbos: AI agents meet Zero Trust through MCP and delegated identity. Read the original.