Foundations
The delegation landscape
Auth51 isn’t the only work on identity and delegation. There are plenty of other capable competitors. But once you see what each of these systems does well, the gap they all share stands out. None of them bind a token to which agent is acting and what single action it’s taking.
Scope-limited consent
The authorization-code grant is already quite narrow. A user approves a set of scopes, and a leaked token is limited to them. But scopes are predefined and static. They express a capability, not which agent invoked it or why this action is happening now. For a deterministic app, that’s enough. For an agent choosing its own path at runtime, a coarse scope can’t represent intent.
Machine-to-machine credentials
The client-credentials grant lets a non-human client obtain a token for its own identity, the backbone of backend service auth. When one client application houses an orchestrator and many autonomous agents sharing one credential set, the token identifies the application, and the agents inside it are indistinguishable. That’s the “no per-agent identity” crack from the first Foundations page.
Actor chains via token exchange
Token Exchange (RFC 8693) adds the act claim to record “A acting for B,” nested for longer chains. It is the closest standard analogue to what Auth51 does. The difference is enforcement: RFC 8693 records the chain and leaves semantics to the implementer, so a resource server still receives a bearer token and must parse the chain itself. Auth51 hashes the delegation path into the token and validates it at mint. (Covered in depth in Token exchange.)
GNAP’s richer negotiation
The Grant Negotiation and Authorization Protocol proposes fine-grained, dynamically negotiated access and first-class sub-grant objects for onward delegation, genuinely more expressive than OAuth here. It’s also early and not yet widely deployed, and like the others it models delegation between clients, not between non-deterministic agents with per-action intent.
Workload identity: SPIFFE/SPIRE and cloud IAM
SPIFFE/SPIRE issues cryptographically verifiable identities to workloads (an X.509 SVID bound to a specific service), and cloud IAM systems (AWS IAM Roles, Azure Managed Identity, GCP Service Accounts) issue service-level credentials. Both are excellent at “which service is this,” and both stop at the service boundary: they can’t distinguish multiple agents running inside one workload, and they verify identity, not the intent of a non-deterministic action.
Note
▶Zero-Trust and AI-security work, briefly
Two nearby areas of work fit alongside this. Zero-Trust architectures (NIST SP 800-207, BeyondCorp, CISA’s maturity model) give the right principles, per-request evaluation and short-lived access, but their current implementations verify who is calling (client identity), not what the request intends. Auth51 slots into that model rather than replacing it; see Zero-Trust alignment.
AI-security approaches (prompt-injection guards, output validators) harden the model side and are complementary rather than competing: they reduce how often an agent is subverted, while Auth51 bounds what a subverted agent can do. Defense in depth wants both. The full comparison and threat analysis live in arXiv 2509.13597.