Zero Trust Architecture Applied to AI Agent Networks

Securing OAuth credentials for AI agents making tool calls means giving every agent its own short-lived, cryptographically verifiable identity (not a shared API key or a borrowed human session), scoping its access at the tool-call level rather than the system level, and enforcing those policies outside the agent itself so a compromised agent can't talk its way around them.

Classic zero trust and AI agents acting over MCP-connected infrastructure

Most security teams already run a zero trust program. None of it was built to handle what an AI agent actually does, and that gap is why agents keep slipping through controls that look, on paper, like they should catch them.

Classic zero trust rests on three assumptions: identities are stable enough to onboard, review, and offboard on a human schedule; access can be scoped in advance through a role; and a login event is the moment that matters most for verification. AI agents break all three at once. They're ephemeral, often spun up and retired within hours, with no joiner-mover-leaver lifecycle for traditional IAM to track. A hijacked agent still looks like an agent doing its job.

MCP has become the wiring that connects agents to databases, APIs, file systems, and cloud services through one standard interface, and it was built without mandatory authentication or authorization baked in. So the gap here isn't a missing policy document somewhere in a compliance binder: it's architectural, since the controls enterprises already run are watching for strange login patterns, while agents are already chaining calls across cloud, SaaS, and on-premise systems with nothing checking what they're allowed to touch along the way.

The MCP threat surface and ungoverned agent identity

None of this is theoretical. The authentication gap in MCP, combined with how fast the protocol got adopted, has produced a wide attack surface, and confirmed vulnerability classes have already turned up in production systems.

Start with authentication failures, the most direct result of ungoverned identity. A critical flaw in nginx-ui, tracked as CVE-2026-33032 with a CVSS score of 9.8, let attackers bypass authentication on the MCP message endpoint. Microsoft's @azure-devops/mcp npm package carried a similar flaw, discovered on April 3, 2026: a missing authentication layer on a server that handled Azure DevOps work items, repositories, and pipelines let an attacker pull configuration details, API keys, and authentication tokens without presenting any valid credentials at all (CVE-2026-32211, CVSS 9.1).

The second pattern is supply chain abuse, which exploits a model where trust gets granted just because a server says it deserves it. "ContextCrush," disclosed in March 2026, showed something related but distinct: a read-only MCP server exposing nothing but narrow, seemingly safe tools can still deliver attacker instructions to an agent. That finding undercuts a common assumption, that narrowing what tools a server exposes is enough to contain the risk.

Research into skillset networks backs this up structurally. Authentication and authorization are two separate problems in MCP, by design, and solving one does nothing for the other.

Why MCP authentication is mandated but authorization remains optional

The July 28, 2026 revision to the MCP specification is the biggest security update the protocol has seen, and it introduces real OAuth 2.1 requirements where none existed before.

The new spec requires an MCP server to implement OAuth 2.0 Protected Resource Metadata under RFC 9728. It requires an MCP client to send the resource parameter defined in RFC 8707 on both authorization and token requests, and it requires the server to reject any token that wasn't issued specifically for it. A server can no longer take the token it received from a client and hand that same token to an upstream API. If a server needs to act on a user's behalf downstream, it has to use a delegation mechanism like OAuth token exchange rather than forwarding the user's original credential.

These are real improvements, and they close off some of the exact failure modes described above. But authorization itself stays optional. A server can follow every one of these requirements to the letter and still choose to require no authorization at all, and it will remain fully spec-compliant. The spec raises the floor for servers that choose to build authentication in, but it can't force every server in an MCP ecosystem to do so, which leaves that optional status as the structural problem the rest of this piece has to work around.

The consequence for security teams is direct. Platforms like Runlayer implement policy enforcement and real-time validation across MCP sessions, extending the core zero trust ideas, verify explicitly, enforce least privilege, assume breach, to agents that are ephemeral and chain tool calls by nature.

Applying "verify explicitly" to agent identity: why shared credentials and static secrets fail

Verify explicitly comes first among the zero trust pillars because identity is what every other control stands on, and it's also the pillar most enterprises haven't actually extended to their agents yet. For an AI agent, this means holding a unique, cryptographically verifiable identity, not a shared API key, not a human's delegated login, not a service account whose password gets rotated once a year if anyone remembers.

The common shortcut, running agents as proxies under a human's own access credentials, breaks the basic requirements of auditing, traceability, and non-repudiation. iProov's analysis puts it directly: this practice "breaks auditing, traceability, and nonrepudiation requirements, significantly elevating the risk of overpermissioning, and the impact of credential compromise and account takeover." When agents share credentials or ride on a user's session, nobody can answer the simplest incident-response question of which agent did this. Audit logs stop making sense, and access reviews lose their purpose.

Static credentials make the problem worse at scale. The SANS 2026 State of Identity Threats & Defenses Survey found that 92% of organizations fail to rotate machine credentials on a 90-day cycle, leaving the credentials most agents run on long-lived and exposed far longer than they should be. The architectural fix is workload identity, with SPIFFE as the leading model: each agent gets a short-lived identity document, an SVID, issued based on its actual environment and workload attributes. One architecture, EHV, extends the identity-verification model of NIST SP 800-207 into what it calls agentic action verification, naming the specific failure it closes as "trusted identity, untrusted action": holding a valid credential does not, by itself, authorize any particular action. Platforms built for MCP environments, including Runlayer, operationalize this with built-in OAuth, SSO, and SCIM support alongside just-in-time credentials, giving each agent its own verifiable identity rather than asking IT teams to bolt SPIFFE onto every MCP server by hand.

Applying "least privilege" to agents that decide their own tool scope at runtime

Least privilege is the hardest of the four pillars to apply to agents, because the access an agent needs isn't knowable ahead of time the way a human job role is.

Portnox's analysis of zero trust for AI makes the point concretely: an agent built to summarize support tickets doesn't need read or write access to a production database, yet a role labeled broadly as "data access" tends to hand over far more than that one task calls for. Multi-agent systems compound the issue. An agent can claim capabilities it doesn't actually have, or capabilities well beyond its intended scope, and the orchestrator will act on the claim as though it were fact.

Fix authorization tool by tool: tie it to intent and check it at the moment of the call. Granting access to run one specific, read-only query against a scoped dataset is a meaningful, auditable control. Granting access to "the data platform" is not. In practice, this is what Runlayer's tool-call-depth policy enforcement and just-in-time credential model are built for: access scoped to the current task, granted only when needed, and revoked automatically once the task ends, rather than standing permissions sitting open indefinitely.

Applying "assume breach" to agents that process external data as part of their function

For a human user, assume breach is usually a statement about the network perimeter. For an AI agent, it means something closer to a fact of daily operation: agents read outside, potentially adversarial data as a normal part of their job, so a compromised agent and a working agent can look identical from the outside.

Prompt injection is the clearest version of this risk. A related failure, intent drift, happens when an agent starts a task with legitimate authorization and, through a sequence of individually plausible tool calls, ends up taking an action its operator never actually approved.

The EHV architecture gives this pillar a concrete, enforceable shape. It authorizes every action against current policy at the moment that action executes, not once at the start of the session, closing the "trusted identity, untrusted action" gap directly: a valid credential authorizing an agent doesn't mean every action that agent takes is automatically authorized too. Structural containment backs this up. This is the layer where real-time detection for tool poisoning, prompt injection, and intent drift matters, and it's where Runlayer's monitoring sits: detecting these MCP-specific threats as they happen, with tamper-proof audit logs and full OTEL tracing providing the forensic record that lets a security team reconstruct what a compromised agent did and where.

Applying "continuous validation" to agents whose trust level must change when the agent changes

Continuous validation is the pillar organizations tend to skip, and skipping it raises costs fastest, visible as soon as an agent's trust level needs to change. Trust in an agent can't be a property you set once at login. It has to be recalculated whenever the agent itself materially changes, because an agent running a new model, a new system prompt, or a newly connected tool is functionally a different entity than the one that was originally approved.

The triggers for recalculating trust are broader than anything classic zero trust was designed to track: a change to the model, the system prompt, connected tools, data sources, integrations, the deployment environment, or the business purpose the agent serves. Portnox frames this sharply: a token issued at noon doesn't entitle an agent to broad access at midnight if its posture, location, or behavior has shifted in between.

A forensic problem most enterprises haven't solved produces this: when an agent acts on a user's behalf, figuring out which actions reflected the user's actual intent, which were autonomous agent decisions, and which were the product of a prompt injection is genuinely hard after the fact. TrustAgentNet's research applies a similar idea to multi-agent networks specifically, using a two-tier blockchain structure: a global Chain of Skillsets governs the lifecycle of skillset metadata with off-chain auditing and on-chain cryptographic consensus, while short-lived Chains of Collaboration get spun up dynamically for each task, so every delegation between agents is logged and traceable to its source. Continuous validation becomes operational here: a platform giving security teams a single pane over every MCP connection, skill, and agent, with identity tied to every action and policy enforced at the depth of each individual tool call, is what makes it something a team can actually run day to day.

Rebuilding governance and compliance for agents that existing frameworks assumed a human would operate

Every major AI governance framework in wide use today, NIST AI RMF, ISO/IEC 42001, the EU AI Act, quietly assumes a human sits in the loop somewhere. So none of their compliance requirements transfer automatically to a fleet of autonomous agents unless someone deliberately extends them.

NIST AI RMF 1.0, released in January 2023, organizes its approach around Govern, Map, Measure, and Manage, a useful lifecycle taxonomy, but it offers no mechanism to enforce anything at the moment code actually executes. ISO/IEC 42001 sets up a certifiable AI management system, but it inherits the PDCA audit cycle, which EHV's analysis puts at fourteen days or more of governance latency, far too slow to govern something executing at agent speed. The EU AI Act requires risk classification and conformity assessment for high-risk AI under Annex III, and automatic logging under Article 12, requirements that per-agent identity, just-in-time credentials, and tamper-proof audit logs satisfy directly once they're in place. Singapore's Infocomm Media Development Authority launched the first governance framework written specifically for autonomous AI agents on January 22, 2026, at Davos, and the fact that this needed its own separate framework says something on its own: every prior major framework was built with the assumption that a person operates the AI system in question.

This is no longer a purely regulatory concern. Tamper-proof audit logs, full OTEL tracing, and SCIM-based identity integration, the kind Runlayer provides, are what let a procurement team or auditor see demonstrable, per-agent governance.

A zero trust architecture for agent networks, end-to-end

None of this calls for a brand-new security framework built from scratch. It's an extension of the identity, authorization, monitoring, and lifecycle controls that already govern human users and devices, applied to agents as their own distinct identity population with their own requirements.

Four control planes need to work together. Identity means every agent holds a unique, cryptographically verifiable identity, SPIFFE/SVID or an equivalent, with a named owner and a documented lifecycle state, no shared credentials and no borrowed user sessions, with multi-step delegation tracked through OAuth 2.0 Token Exchange and the act claim. Lifecycle governance means recalculating trust on every material change to an agent, model, prompt, tools, data sources, environment, or purpose, with a continuously maintained agent inventory and enforcement sitting at the platform layer rather than relying on MCP spec compliance alone, since optional authorization in the spec makes that compliance insufficient by itself.

Runlayer's platform maps onto all four planes at once: enablement through access to over 18,000 MCP servers with built-in OAuth and fast agent setup, control through a single view across every MCP connection, skill, and agent with SSO, SCIM, and just-in-time credentials enforced at tool-call depth, and security through real-time detection of MCP-specific threats paired with tamper-proof audit logs and full OTEL tracing. Together, that gives a security team the enterprise path to this architecture without stitching together a pile of separate point tools. The underlying shift this asks of security and IT teams is a change in posture more than a change in tooling: building the infrastructure that makes agentic AI adoption possible across the company, rather than the obstacle course that slows it down, on the premise that the secure way to run agents and the easy way to run them should end up being the same path.