AI Agent Authorization: Verifying Delegated Authority Across Trust Boundaries

Authentication answers who a party is. Authorization answers what that party may do. Delegated authority is the part agents make urgent: the agent is not the principal, it is acting for one, and the receiving system has to decide whether that delegation actually happened and actually covers this action.

Inside one organization, the identity provider, token issuer, and policy engine often share enough context to make authorization workable. Across an organizational boundary, that context may not travel with the agent. When an agent operated by someone else calls your API, your MCP server, or your physical system, you are the party carrying the risk of executing, and you may have no shared infrastructure with whoever authorized it.

OAuth tokens can be signed, scoped, introspected, exchanged, and bound to a presenting key. Token exchange can represent actor chains. Cross App Access uses ID-JAG to carry signed identity and authorization context into an exchange for a resource-specific access token. These are meaningful controls, and Ratify is not a replacement for any of them.

What they do not necessarily give an external receiver is a principal-signed delegation chain binding this authority to this agent key, narrowed at every hop, with verification semantics the receiver can implement independently. Ratify standardizes that additional artifact, so the evidence travels with the request and the receiver evaluates it against its own trust anchors and its own policy.

A principal signs a certificate naming the agent’s public key, an allowed scope, constraints such as geographic, temporal, rate, or amount limits, and an expiry. Sub-delegation is not implicit: it requires an explicit identity:delegate grant, and wildcards never confer it, which is what keeps authority from widening as it passes between agents. A2A delegation walks a multi-hop chain through the canonical fixtures. Every signed object carries hybrid Ed25519 and ML-DSA-65 (FIPS 204) signatures, and both must verify.

At the boundary the receiver issues a fresh challenge and the agent countersigns it with the delegated key. Where the receiver keeps an issuance record, so that each challenge is accepted at most once, a copied delegation cannot be replayed as a bearer credential. Without that record, freshness alone bounds replay to the challenge window rather than eliminating it, and the specification says so directly: stateless cryptographic verification on its own is not replay-safe task acceptance.

The receiver checks the hybrid signatures, the continuity of the chain, the sub-delegation gate, scope intersection across every hop, the constraints against the context it supplies, challenge freshness, and revocation according to its own policy. It returns a deterministic status from a closed set, including authorized_agent, scope_denied, expired, revoked, constraint_denied, and invalid.

That verification does not require a call to a Ratify service, provided the receiver already holds its trust anchors and revocation state that is fresh enough for its own risk policy. That qualification is the honest form of the claim, and high-risk uses should fail closed when sufficiently fresh revocation state is not available.

Measured on the documented Apple M2 Pro baseline in July 2026, the compiled verifiers in Go, Rust, and C complete a full chain verification in 0.36 to 0.83 ms at chain depths one to three. The TypeScript verifier is 7.4 to 14.9 ms for the same work. Both figures and their method are in the published benchmarks.

Ratify is designed to interoperate with identity providers, token systems, and policy engines rather than replace them. These layers can carry signed credentials and authorization context. Ratify adds a protocol-defined delegation chain originating with the principal, narrowed across each hop, bound to the presenting agent key, and evaluated by the receiver using deterministic verification semantics.

• The presented delegation chain is cryptographically valid.
• Each delegation is continuous with the next subject and key.
• The requested scope and the encoded constraints are satisfied by the context the verifier supplies.
• The proof is inside its validity period and satisfies the verifier's own freshness and revocation policy.
• The presenting agent proves possession of the delegated key using the verifier's challenge.

These limits are part of the specification rather than caveats bolted on afterwards. A receiver that does not account for them is not using the protocol correctly.

• That the root key belongs to a particular real-world organization or person. That comes from the verifier's trust anchors, not from the protocol.
• That facts the verifier supplies about the physical world are true.
• That a validly authorized action is wise, harmless, compliant, or permitted by local rules.
• That revocation data never needs refreshing. Verification runs locally; revocation state still has an age.
• That an agent is not malicious. Constraints narrow the blast radius, and that is all they do.

Ratify Protocol is an open protocol published by Identities.AI, Inc. The current reviewed release is 1.0.0-alpha.15, which is alpha. There are 63 canonical conformance fixtures. Each pins the canonical signing bytes and the expected verdict, and the reference SDKs (Go, TypeScript, Python, Rust, and C/C++) reproduce both, so an implementation that passes all 63 is byte-for-byte interoperable with the reference.

The specification is the normative source for everything described here. The repository holds the fixtures, the SDKs, and the benchmark method, so any claim on this page can be run rather than taken on trust.