TL;DR: AI agents and Model Context Protocol are pushing enterprises toward identity-aware tool access, but static API keys, broad service accounts, and weak authorization models still dominate MCP implementations, according to Cerbos. Zero Trust for agents now depends on short-lived delegated credentials, fine-grained policy checks, and auditable on-behalf-of flows rather than shared secrets.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “MCP and Zero Trust: Securing AI agents with identity and policy”.
By the numbers:
- AI agents dominated the conversation at KubeCon North America 2025, with every other conversation focused on agentic systems.
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.
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.
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.
Practitioner guidance
- Define agent identities before tool exposure Assign each AI agent a unique identity and separate it from the human user and the host application.
- Replace shared secrets with scoped delegation Move away from static API keys and broad service accounts.
- Filter tool visibility by identity and context Expose only the tools, resources, and parameters that a given agent should see.
Bottom line: AI agents connected through MCP need their own identities, because shared secrets and undifferentiated sessions collapse the boundary between user, agent, and tool.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server identities and Zero Trust for AI agents