# Ratify Protocol

> An open protocol for portable authorization of AI agents. A principal signs a
> scoped, expiring delegation bound to one agent's public key. The agent presents
> that delegation with a fresh proof that it holds the key. Any receiving system
> verifies the delegation chain locally and returns a deterministic status.

Ratify Protocol is published by Identities.AI, Inc. The specification is CC-BY-4.0 and the
reference SDKs are Apache-2.0.

## What it is for

A receiving system (an API, MCP server, A2A agent, voice or meeting agent, or a
physical system) executes actions requested by agents it does not operate.
Ratify gives that receiver a protocol-defined, principal-signed delegation chain
bound to the presenting agent key and narrowed across every hop. It complements
access tokens and local policy by standardizing portable evidence the receiver
verifies against its own trust anchors and revocation policy before the action
runs.

## The model: Delegate, Present, Verify

- Delegate: a principal signs a certificate naming the agent's public key, an
  allowed scope, constraints (geographic, temporal, rate, amount, resource/path), and an expiry.
  Sub-delegation requires an explicit `identity:delegate` grant; wildcards never
  confer it.
- Present: the proof travels with the agent. 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 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.
- Verify: the receiver checks hybrid signatures, delegation continuity, the
  sub-delegation gate, scope intersection across every hop, constraints against
  supplied context, challenge freshness, and revocation per its own policy.

## Verification results

The verifier returns a closed set of statuses, including `authorized_agent`,
`scope_denied`, `expired`, `revoked`, `constraint_denied`,
`constraint_unverifiable`, and `invalid`. Structural and cryptographic failures
return `invalid` with a machine-readable reason prefix such as `bad_signature`,
`key_mismatch`, or `stale_challenge`.

## Facts, as of protocol 1.0.0-alpha.16

- Every signed object carries hybrid Ed25519 and ML-DSA-65 (FIPS 204)
  signatures; both must verify.
- 79 canonical conformance fixtures. Each pins the canonical
  signing bytes and the expected verdict; an implementation passing all
  79 is byte-for-byte interoperable with the reference.
- Reference SDKs: Go, TypeScript, Python, Rust, and C/C++.
- Verify latency: 0.36 to 0.83 ms in the
  compiled verifiers (Go, Rust, C) at chain depths 1 to 3 on an
  Apple M2 Pro, measured 2026-07-25. TypeScript is
  7.4 to 14.9 ms for a full chain
  verification; session tokens reduce repeated interactions to one hybrid
  signature check per turn.
- Verification requires no call to Ratify or any vendor, provided the verifier
  already holds its trust anchors and sufficiently fresh revocation state.

## Boundaries, stated plainly

- Status: open-source alpha. No independent security audit has been performed,
  and no independent production deployment has been publicly established.
- Ratify does not prove that a root key belongs to a particular real-world
  organization. Trust anchors are an explicit deployment decision by the
  verifier.
- Ratify does not prove that facts supplied about the physical world are true,
  that a validly authorized action is wise or compliant, or that an agent is
  non-malicious.
- Local verification does not mean revocation data never needs refreshing.
  High-risk deployments should fail closed when fresh revocation state is
  unavailable.

## How it relates to adjacent work

Ratify is designed to compose with, not replace, identity providers, OAuth
(including token exchange and DPoP), Okta Cross App Access, MCP, A2A, and policy
engines. Those systems establish who a principal is, grant and carry access, and
decide local rules. Ratify carries the portable evidence of delegated authority
across trust boundaries so a receiver in another organization can verify it
independently.

## Writing

Technical notes and case studies from the protocol team, covering portable
delegated authority, verification, and integrations across agent trust
boundaries. The index lists every published note; the feed carries new ones.

- Writing index: https://ratifyprotocol.com/writing
- Writing feed (RSS): https://ratifyprotocol.com/writing/feed.xml

## Links

Specification and benchmark links are pinned to the reviewed release. The
repository default branch tracks the next release and will not match the facts
above.

- Site: https://ratifyprotocol.com
- Writing: https://ratifyprotocol.com/writing
- Labs and executable references: https://ratifyprotocol.com/labs
- Developer integration guide: https://ratifyprotocol.com/developers
- Security model and limits: https://ratifyprotocol.com/security
- AI agent authorization: https://ratifyprotocol.com/ai-agent-authorization
- A2A delegation: https://ratifyprotocol.com/a2a-delegation
- Specification (1.0.0-alpha.16): https://github.com/identities-ai/ratify-protocol/blob/v1.0.0-alpha.16/SPEC.md
- Repository: https://github.com/identities-ai/ratify-protocol
- Documentation: https://docs.identities.ai
- Benchmarks and methodology (1.0.0-alpha.16): https://github.com/identities-ai/ratify-protocol/blob/v1.0.0-alpha.16/docs/BENCHMARKS.md
- Package: `npm install @identities-ai/ratify-protocol`

## Attribution

Ratify Protocol™ and the Ratify logo are trademarks of Identities.AI, Inc. U.S. patent application pending.