Authorization Libraries Built for Agent-to-Agent Permission Models

Authorization systems built for humans assume a person sits down, logs in, does some bounded amount of work, and logs out. Session tokens exist because sessions have edges: a start, a middle, an end, and an idle timeout that catches the case where someone walked away from their desk. None of that holds when the principal making the request is an agent. An agent can call hundreds of API endpoints in the time it takes a person to read this sentence, and it does so without a timeout clock running down, exercising whatever access it inherited at full machine speed. The mismatch is categorical. It is categorical.

Role-Based Access Control was the first attempt to formalize permissions beyond raw access lists, and it works fine as long as the number of distinct roles stays small and mostly static. Agent workloads blow that assumption apart. Model a support agent's permissions properly, accounting for customer tier and resource type, and the role count multiplies fast enough to become unmanageable in practice, according to WorkOS's analysis of fine-grained authorization for agent systems. Every new agent type, every new resource category, every new combination of the two adds another role to a table that was never meant to scale past a few dozen entries.

Attribute-Based Access Control fixes some of this by evaluating conditions rather than enumerating roles, but it still assumes a request arrives as a discrete, bounded thing from a principal whose identity is settled before the request is evaluated. It has no native concept of a request that is itself the tail end of a delegation chain, spawned three hops upstream by a different agent acting on behalf of a different task.

It was still designed for human principals reaching into static resources through well-defined API surfaces. It has no native answer for the case where a result is synthesized from several individually authorized retrievals, and the synthesis itself exposes something none of the individual accesses would have. That gap is not a bug to patch. It is the reason a new category of infrastructure had to get built.

The four structural problems that agent-to-agent systems introduce

Tallam's analysis shows that authorization propagation across multi-agent workflows produces four distinct failure modes, none of which classical models were ever built to catch. Treating these as one fuzzy problem called "agent permissions" is how teams end up patching symptoms instead of designing for the actual failure surface. Each one needs its own primitive.

Transitive delegation is the most intuitive to describe and the easiest to get wrong in production. When an orchestrator agent spawns a sub-agent, the lazy answer is to hand the sub-agent the same permissions the orchestrator holds. That answer is wrong on its face: least-privilege design demands the sub-agent's scope narrow at every hop, and no classical authorization model enforces that narrowing as a structural requirement rather than a developer's good intention.

Aggregation inference is the counterintuitive one, and it deserves more than a passing mention. Picture Agent A pulling a customer's billing history, Agent B pulling that same customer's support tickets, and Agent C combining both into a churn-risk summary. Every individual retrieval was authorized. The combination might reveal something, a pattern of complaints tied to a pricing change, say, that neither dataset disclosed on its own, and that the requester was never cleared to see. Authorization models built around checking access to a single resource at a single point in time have no vocabulary for evaluating what a combination reveals, because the combination is not a resource anyone declared a policy about.

Temporal validity breaks the assumption that authorization state holds still. A multi-step agent workflow can run long enough that permissions change mid-flight, and TTL-based token expiry, the standard fix for stale credentials, fails at the speed agents actually execute at. Parakhin's 2026 work offers a formal proof of exactly this failure mode.

Ibrahim and Li (Huawei Heisenberg Research Center, June 2026) formalize attenuation as a chain-level invariant: as delegation passes down a chain, scope must narrow, never stay flat or expand. Ibrahim and Li, working out of Huawei's Heisenberg Research Center, formalized this in June 2026 as a chain-level invariant they call attenuation, and they show that OAuth's fixed-content tokens have no way to express it across dynamic, recursive delegation chains. A token issued once, with a fixed scope baked in, cannot narrow itself as it passes hands. That single limitation turns out to be the hinge the rest of this piece swings on.

Where existing infrastructure breaks first in the delegation chain

OAuth authenticates that last call just fine. What it cannot do is show how the specialist got its authority, who granted it, or what constraints were supposed to travel with it. The chain is invisible to the protocol securing it.

Bearer tokens make the problem worse by design, not by accident. Handing a bearer token to another agent copies whatever authority is baked into that token wholesale; nothing about the handoff naturally shrinks the access to match the narrower task the second agent was actually asked to do. A token built for a broad task becomes a master key the moment it's forwarded.

Agent-to-Agent protocol cards compound the lack of a verifiable, attestation-bound identity. An A2A agent card is a self-declared identity with no attestation binding it to anything verifiable, and the protocol hands credential management entirely to whoever implements it, which leaves card tampering, impersonation, and replay attacks as live risks unless someone bolts on additional controls. The protocol describes the shape of a conversation between agents. It says nothing about whether the agent on the other end is who its card claims.

The scale of the exposure is not hypothetical. A security scan of internet-exposed MCP servers found that every server in the verified sample had no authentication at all. That is not a rounding error in a niche corner of the ecosystem; it's the default state of a protocol that's being adopted fast. A2A became a hosted project of the Agentic AI Foundation on August 17, 2026, signaling the protocol is graduating from side project to shared infrastructure. The identity verification gap, though, stays exactly where it was, sitting in the lap of whoever implements the spec.

What invocation-bound and task-scoped token designs do differently

Two research proposals, developed independently, land on the same structural fix. Authorization has to travel with the invocation itself, carried inside the call, rather than asserted by whoever happens to be holding a token at the moment they use it. That's a small-sounding shift in wording that turns into a large shift in what the token can prove.

Prakash's 2026 proposal, Invocation-Bound Capability Tokens, fuses identity, attenuated authorization, and a provenance record into one append-only chain. The token doesn't just say "this holder can do X." It says who granted the authority, at what point, with what narrowing applied, and it keeps that history attached as the token moves.

The design also holds up under attack. Across 600 adversarial attempts, the chained model rejected all of them, and two specific attack types, delegation depth violation and audit evasion, were only catchable because the chain carried its own history; a plain unsigned or single-hop JWT setup couldn't have detected either.

Sharma et al.'s 2026 proposal, PAuth, attacks the same problem from a different angle, challenging OAuth's assumption that scope should be tied to an operator rather than a task. PAuth builds "envelopes" that scope authorization to what a specific task actually requires.

Both designs treat delegation as a contractual transfer of narrowed authority, not a static grant of consent handed over once and trusted forever, which lines up with the attenuation framework Ibrahim and Li formalized the same year. Neither one is a complete answer: token-chain approaches are harder to revoke mid-workflow, and they don't touch aggregation inference at all, a limitation Tallam's 2026 work acknowledges directly. The reasonable response is that these designs were built to solve the delegation-chain sub-problem specifically, and they're meant to sit alongside a policy enforcement layer that handles what they can't.

How dependency-graph policy enforcement addresses what token chains cannot

Token chains solve provenance. They don't solve the question of what happens when a model just decides, in the middle of reasoning through a task, to ignore the policy it was told to follow. Embedding rules into a system prompt provides no enforcement guarantee whatsoever, and a system relying on prompt-level policy is exposed to violations any time the model reasons its way around the instruction or someone manipulates the prompt directly. Instructions alone are advisory.

Policies get written in a Datalog-derived declarative language expressed as declarative rules that account for transitive information flow and cross-agent provenance. A reference monitor sits outside the model, intercepting every action and blocking violations before they execute. Enforcement doesn't depend on whether the model reasoned correctly. It depends on the graph.

The results are the sharpest evidence in the whole research set. On customer service tasks, PCAS lifted policy compliance to 93% across frontier models, with zero policy violations recorded across instrumented runs. Set beside a prompt-only baseline where nothing structural stops a violation, this means knowing the monitor will catch a violation instead of merely hoping the model behaves.

The dependency graph does something token chains structurally cannot: it produces a causal audit trail showing not just that Agent C touched a combined result, but exactly which upstream retrievals fed into it and under what authorization state each one held at the time. The obvious pushback is that PCAS requires policies compiled statically, which seems to sit awkwardly next to how dynamic and emergent agent behavior actually is. But the monitor operates outside the model and intercepts actions regardless of how the model got there, so the enforcement layer doesn't need to be recompiled every time the model's reasoning path changes. It just needs to see the action. PCAS (Policy Compiler for Agentic Systems) was proposed by Palumbo et al.. PCAS (2026) models agentic system state as a dependency graph capturing causal relationships among events (tool calls, tool results, and messages), rather than treating each action as an isolated authorization decision.

Current offerings from relationship-based access control engines built on one well-known authorization model (OpenFGA, SpiceDB, Permify)

The three most widely deployed Zanzibar-style engines all handle the policy decision point competently. None of them natively model delegation chains, temporal validity, or aggregation inference, and that gap runs through all three equally.

OpenFGA came out of Auth0 and Okta, now lives as a CNCF incubating project, and offers a flexible authorization model DSL with check, list, and expand APIs that saw wide adoption through 2025. SpiceDB stays closest to Google's original Zanzibar paper in its schema language, ships a Watch API for cache invalidation, and gives strong consistency guarantees; it handles delegation by representing it as relationship data rather than a bearer token, which sidesteps forwarding a token along with its full authority intact. Permify targets developer experience directly, with its own schema language, built-in data filtering, and a visual playground for testing permission logic before shipping it.

None of this changes the structural ceiling. All three engines were designed around human principals reaching into static resources, and none of them natively handles a synthesized output where a combination of individually authorized accesses adds up to something unauthorized, nor a mid-workflow change in authorization state. That's a statement about what problem they were built to solve, which was never this one. It's a statement about what problem they were built to solve, which was never this one.

For a team trying to build toward agent-native authorization today, SpiceDB's relationship-data approach to delegation is probably the most compatible starting point for layering IBCT-style provenance on top of, and its Watch API already provides the real-time invalidation mechanism that temporal validity enforcement will need. That's a foundation, not a finished product. AuthZed Materialize reached general availability on September 10, 2026, for AuthZed Dedicated, precomputing transitive relationships for deeply nested permission graphs where live traversal becomes the bottleneck, directly relevant to deep agent delegation chains.

Production platforms that combine these primitives today

Production agent authorization in 2026 has converged on a rough pattern: two identities plus a delegated context, meaning the agent's identity, the user's identity, and a task-specific authorization context evaluated fresh at runtime, with platforms stitching together fine-grained authorization, token delegation, and audit logging to approximate it.

WorkOS's Fine-Grained Authorization product is the clearest example of this pattern in commercial deployment. It extends past flat RBAC into hierarchical, resource-scoped access control with native ties into enterprise identity providers. Consistency is configurable rather than fixed: FGA is eventually consistent by default, but a bounded-staleness protocol, the Warrant Token, lets a client request immediate consistency on a specific request, which matters the moment permissions change mid-workflow. Agents and service accounts as first-class subject types are on the way, building on groups, organization memberships, and users already supported, which means teams can adopt the model incrementally instead of ripping out an existing RBAC system to make room. WorkOS's own blog states that authorization decisions get complete audit tracking.

Arcade.dev shows up in the same 2026 roundup as a platform combining an action runtime, delegated context, per-action permission intersection, a token vault, hosted tool execution, and audit logging in one package. It gets less documentation in the available research than WorkOS FGA does, but the shape of the offering points at the same underlying pattern.

The honest read on where this leaves practitioners: platforms combining fine-grained authorization for the policy decision, delegated context traveling with the task, and audit logs recording the chain get close to what agent-native authorization requires. None of them yet implement the full stack of IBCT provenance binding plus PCAS-style dependency-graph enforcement in a single production offering. Platforms built around a policy engine that enforce fine-grained authorization that way rather than through static token content run into the same underlying constraint here: a token's contents alone can't express the dynamic scope narrowing or the multi-hop delegation chain an agent workflow generates. Invocation-bound designs get around this by treating authorization as a claim verified at the moment of the call itself, which is the same conceptual move that took delegated authorization systems from static role tables to rules evaluated fresh at request time. The research frontier is running a step ahead of what any single vendor ships today, and an architecture that gets locked in around whatever's available this quarter risks missing that gap. Sub-50ms authorization checks, with p95 latency under 50ms, are designed for high-frequency agent operations.

The standards layer being built to make agent authorization interoperable

MCP and A2A both shipped without verified agent identity, and that gap is now getting worked on at the standards level, though the work is still early and the space between what the drafts propose and what's actually deployed remains wide.

This draft identifies gaps and guides future standardization rather than mandating a complete solution. Four related drafts published earlier in 2026 chip away at individual pieces of the same puzzle: AIMS from Kasselman and colleagues, WIMSE itself from Ni and Liu, an Agentic JWT format from Goswami, and a SCIM extension for agent provisioning.

The Cloud Security Alliance took a parallel run at the problem with its Agentic AI IAM framework, which argues that agent identity credentials need to carry verifiable provenance, reputation, purpose, and capability, not just a name and a key. That framework responds directly to the risks this piece has been tracing all along: identity spoofing, credential reuse turned into privilege escalation, and agents chaining delegations together to land somewhere they were never authorized to reach. MCP, for its part, has adopted OAuth 2 as its authentication layer.

None of this closes the gap by itself. Standards documents describe where the ecosystem needs to go; they don't retrofit authentication onto the MCP servers already running without it. But for anyone deciding what to build an agent authorization architecture around, the direction of travel matters as much as the current state: delegation chains, scope attenuation, and verifiable provenance are becoming the vocabulary the whole field is converging on, and an architecture built around that vocabulary now will outlast whichever specific library happens to be popular this year.