Zero Trust says "never trust, always verify." But verify what, exactly, when the requester is an autonomous agent that spawns sub-agents, delegates credentials, and makes 1,500 API calls per prompt? Identity-based security was designed for humans. The agent economy needs something fundamentally different.
If you've spent any time in enterprise security, you know Zero Trust. Verify every request. Authenticate every user. Trust no network segment implicitly. It's the dominant security paradigm for good reason — it replaced the broken "castle and moat" model that assumed everything inside the perimeter was safe.
But Zero Trust was built for a world where humans sit at keyboards, devices have certificates, and access patterns are predictable. AI agents break every one of those assumptions. And the security industry hasn't caught up yet.
What Zero Trust Actually Assumes
Before we can talk about where Zero Trust breaks, we need to be precise about what it assumes. The NIST SP 800-207 Zero Trust Architecture standard defines five core tenets. Every one of them has an implicit dependency on human-scale behavior:
1. All resources are accessed in a secure manner regardless of network location. This works. Agents use APIs over HTTPS. No issue here.
2. Access is granted on a per-session basis. Implies sessions have bounded duration and scope. A human session lasts minutes to hours. An agent session might spawn 50 sub-agents in seconds, each needing different access levels. What's a "session" when the requester can clone itself?
3. Access is determined by dynamic policy. Policy evaluates identity, device posture, behavioral patterns, and risk signals. But agents don't have "device posture." Their behavioral patterns are non-deterministic — the same agent prompt can produce wildly different API call sequences. And identity is the weakest signal of all because agents delegate constantly.
4. The enterprise ensures all resources are in their most secure state. Assumes the enterprise controls the endpoints. In the agent economy, your API serves agents you've never seen before, running on infrastructure you don't manage, with capabilities you didn't grant.
5. Authentication and authorization are strictly enforced before access. This is where Zero Trust's assumptions shatter completely for agents. Let's dig into why.
The Identity Problem: Who Is an Agent, Really?
Zero Trust's entire enforcement model revolves around identity. Verify the user. Check their role. Evaluate their device. Make an access decision. The assumption is that identity is stable, verifiable, and meaningful.
AI agents demolish this assumption in three ways:
Agents Delegate — Identities Don't
When a human uses an application, they authenticate once and the application acts on their behalf within defined OAuth scopes. The delegation chain is short: human to application to API. Zero Trust can verify each link.
An AI agent orchestrating a complex task might delegate to five sub-agents, each of which delegates to three more. That's a delegation chain five levels deep with 15+ entities making API calls. Each sub-agent needs different permissions. The parent agent needs to constrain what its children can do. And the API receiving the request needs to verify the entire chain.
Traditional identity systems don't model this. RBAC gives you roles. ABAC gives you attributes. Neither gives you delegated authority that attenuates at each level. You can't express "this agent has a $100 budget, and it can give sub-agents portions of that budget, but the total can never exceed $100" in an IAM policy.
Agent Identity Is Ephemeral
A human employee has an identity that persists for years. Their access patterns develop over time, allowing behavioral analysis and anomaly detection. An AI agent might exist for 30 seconds — spun up to handle a single task, then terminated. There's no behavioral baseline to compare against. There's no device posture to evaluate. There's barely an identity at all.
Zero Trust's continuous verification model assumes it can learn what normal looks like for each identity. For ephemeral agents, every access is the first access. Every request is an anomaly by default.
Identity Does Not Equal Authority
This is the deepest problem. Zero Trust answers "who are you?" and then maps that identity to permissions. But for agents, the right question isn't "who are you?" — it's "what are you allowed to do, right now, with what budget, for what purpose?"
An agent's authority should be defined by its token, not its identity. The token says: you can call these endpoints, spend up to this amount, until this time. It doesn't matter who you are. It matters what you hold.
This is the fundamental shift from identity-based to capability-based security. And it's not a minor tweak to Zero Trust — it's a different paradigm entirely.
The Scale Problem: Zero Trust Can't Keep Up
Even if you could solve the identity problem, Zero Trust has a scale problem with agents that's fundamentally architectural.
Zero Trust evaluates every request against a centralized policy engine. Okta, Azure AD, Google BeyondCorp — they all work this way. Request comes in, policy engine evaluates identity + context + risk, returns allow/deny.
Now consider an agent swarm. A research agent spawns 20 sub-agents to gather data from different sources. Each sub-agent makes 50 API calls. That's 1,000 policy evaluations in seconds. Each evaluation requires identity lookup, role resolution, contextual risk assessment, and policy computation.
This isn't a throughput problem you solve with bigger servers. It's a latency problem. Every API call waits for the policy engine to respond. At human scale — a user making 10 requests per minute — the latency is invisible. At agent scale — 1,000 requests in 5 seconds — it's a bottleneck that degrades the entire system.
Capability-based tokens eliminate this bottleneck entirely. The token is the policy decision, pre-computed and cryptographically sealed. Validating a macaroon token is a local operation — check the HMAC chain, verify the caveats haven't been violated, done. No round-trip to a policy engine. No identity lookup. The authorization decision was made when the token was minted.
The Budget Problem: Zero Trust Has No Concept of Cost
Here's where the gap becomes a chasm. Zero Trust is a security framework. It answers: "Is this request authorized?" It does not answer: "Can this requester afford this request?"
For humans, this distinction didn't matter. A human making API calls generates costs that correlate with their work patterns — predictable, bounded, reviewable. An AI agent with valid credentials can burn through $50,000 in API costs in an afternoon. It's fully authorized by Zero Trust standards. It also just bankrupted your department's quarterly budget.
This isn't a theoretical risk. It's happening right now. Companies deploying AI agents are discovering that traditional security gives them a binary answer — access or no access — when what they need is a continuous answer: access within these economic constraints.
Zero Trust practitioners might argue that rate limiting can address this. But rate limits are crude instruments. They cap volume, not cost. An agent making 100 calls to a $0.01 endpoint is very different from 100 calls to a $5.00 endpoint — same rate, 500x cost difference. You need budget enforcement that understands economics, not just traffic patterns.
Capability-Based Security: The Agent-Native Alternative
If identity-based security fails for agents, what replaces it? The answer comes from a concept that's older than Zero Trust: capability-based security.
In capability-based systems, access is controlled by tokens that carry permissions, not by identities that map to permissions. The distinction is subtle but transformative.
Macaroons: Capabilities Made Practical
Macaroon tokens are the practical implementation of capability-based security for APIs. Developed by Google Research in 2014, macaroons are bearer tokens with a unique property: anyone holding a macaroon can create a more restricted version of it, but nobody can create a less restricted version.
This property — called attenuation — solves the agent delegation problem elegantly:
# Enterprise admin mints a root token
Token: team-research-q2
budget: $10,000
scope: /api/v1/*
expires: 2026-06-30
# Orchestrator agent attenuates for sub-agent
Token: research-subtask-47
budget: $500 <- can only reduce, never increase
scope: /api/v1/search <- can only narrow, never widen
expires: 2026-04-04 <- can only shorten, never extend
# Sub-agent attenuates further for its own child
Token: search-worker-12
budget: $50
scope: /api/v1/search?source=arxiv
expires: 2026-04-03T18:00:00Z
# At every level: the child can NEVER exceed the parent's authority
This is what safe delegation looks like. The parent agent gives its child exactly the authority needed — no more — and it's mathematically impossible for the child to escalate. The budget constraint is cryptographically enforced, not policy-enforced.
What Agent-Native Zero Trust Actually Looks Like
This isn't about throwing away Zero Trust. The "never trust, always verify" philosophy is sound. What changes is how you verify and what you verify:
Verify the token, not the identity. When an agent presents a macaroon, verify its HMAC chain back to the root. Check that every caveat is satisfied. This tells you exactly what the bearer is allowed to do — regardless of who they are.
Enforce budgets at the gateway. Every API call has a cost. The gateway tracks cumulative spend against the token's budget caveat. When the budget is exhausted, access stops — instantly, automatically, with no human intervention.
Audit the chain, not the session. Traditional audit trails track user sessions. Agent audit trails need to track delegation chains — who minted the token, who attenuated it, what was spent at each level.
Make policy decisions at mint time. Instead of evaluating policy on every request, encode the policy decision into the token when it's minted. The runtime check becomes: "is this token valid and within its constraints?" — a local, fast, scalable operation.
The Practical Migration: Zero Trust to Agent-Native Security
If you're running Zero Trust today, you don't rip it out. You layer agent-native security on top for the workloads that need it:
Phase 1: Observe. Deploy a gateway in observe mode alongside your existing Zero Trust stack. Let human traffic continue through your identity provider. Route agent traffic through the gateway. You now have visibility into what agents are doing and what they're costing you — data your Zero Trust tools can't provide.
Phase 2: Token-gate agent traffic. Start minting macaroon tokens for your agents with budget constraints. Agents that exceed their budgets get cut off automatically. You still verify identity at the human level (who minted the token), but runtime enforcement is capability-based.
Phase 3: Enable delegation. Allow orchestrator agents to attenuate tokens for sub-agents. Multi-agent workflows operate with proper economic boundaries at every level, without your security team manually provisioning identities for ephemeral sub-agents.
Phase 4: Open external access. If you want external agents to consume your APIs, add L402 payment support. Now any agent on the internet can pay for access without your sales team being involved. Zero Trust stays in place for your internal users. Capability-based security handles the agent economy.
The Bottom Line
Zero Trust was a generational improvement over perimeter security. It correctly identified that network location is a terrible proxy for trust. But it replaced "trust the network" with "trust the identity" — and identity is just as unreliable when your requesters are ephemeral, autonomous, and multiplying.
The next evolution isn't "better Zero Trust." It's recognizing that for machine-to-machine interactions, what a requester holds matters more than who a requester is. Capability tokens that carry permissions, budgets, and expiration — verifiable locally, delegatable safely, attenuatable mathematically — are how you secure a world where agents outnumber humans 1,000 to 1.
Zero Trust got us here. Capability-based security takes us where we're going.
SatGate adds capability-based security and budget enforcement to any API — without replacing your existing identity stack. Open source on GitHub.
Top comments (0)