/ How it fits
Agent Registration
vs. Delegated Authority.
The agent authorization stack has three distinct layers. Each solves a different problem. They are complementary, not competing.
| Layer | Tools | Problem it solves |
|---|---|---|
| 1. Registration | auth.md · WorkOS · OAuth | How does an agent sign up with a service and obtain credentials — without a human clicking through browser flows? |
| 2. Delegation proof | Ratify | Did a specific human delegate authority to this specific agent, for this specific action, right now — provably, offline, with no vendor in the path? |
| 3. Policy decision | WorkOS FGA · OPA · Zanzibar | What is this proven agent allowed to do inside your application, given your resource model? |
Ratify is the middle layer. It does not replace registration — agents still need credentials to call APIs. It does not replace policy engines — your application still decides what proven scopes mean internally. Ratify answers the question neither layer handles: did a specific human delegate authority to this specific agent, for this specific action, right now?
That answer is a signed, peer-verifiable proof that travels with the agent. Anyone can check it in under a millisecond, offline, with no vendor in the path. No live API call, no JWKS lookup, no policy server round-trip.
| Capability | Ratify | Registration / Policy layers |
|---|---|---|
| Trust model | Cryptographic verification | Bearer token / HTTPS policy call |
| Online dependency at verify time | None — offline in <1ms | Requires live server call |
| Multi-hop delegation chains | Native — chain of signed certs | Not standardized / per-vendor |
| Replay defense | Challenge-response (liveness) | Token expiration only |
| Channel | Voice, video, API, Physical AI | Primarily HTTP / web |
| Post-quantum | Hybrid Ed25519 + ML-DSA-65 | Classical RSA / ECDSA |
Bearer token characteristics per RFC 6750 and OAuth 2.0 per RFC 6749. Token Exchange (sub-delegation via JWT) is defined in RFC 8693 but provides no cryptographic delegation chain, scope-ceiling enforcement, or physical constraint model.
The sub-delegation problem
In a multi-agent workflow, your agent might hire a specialist agent to perform a task. Registration-layer credentials have no way to represent this chain of trust. Ratify allows your agent to sign a sub-delegation certificate, passing a subset of its authority to the specialist. The verifier can then cryptographically trace the authority back to the original human — across every hop, with scope-ceiling enforcement at each link.
Beyond the browser
AI agents aren’t just in browsers. They are in Zoom calls, on phone lines, and in physical robots. Registration-layer flows were designed for HTTP — they require a server to call. Ratify uses a single bundle format small enough for SIP headers and robust enough for physical actuation. The verifier needs only the principal’s public key. No server call. No network hop. That is what makes Ratify deployable in offline environments — drones, vehicles, edge inference — at the moment of action.
How the layers work together
A well-architected agent system uses all three. An agent registers with a service via auth.md and receives credentials. The human who deployed that agent signs a Ratify delegation certificate scoped to the actions the agent is allowed to take. At action time, the service verifies the Ratify proof bundle — offline, in under a millisecond — before running business logic, which may further consult a policy engine for application-level decisions. Each layer does exactly one job.