/ FAQ
Ratify Protocol is an open cryptographic trust protocol that lets any party verify, in under a millisecond and without a central authority, that an AI agent was authorized by a specific human (or another agent), is acting within a specific scope, and has not exceeded its expiration. Every signature is hybrid Ed25519 + ML-DSA-65 (NIST FIPS 204). JSON wire format. No blockchain. No tokens. No central issuer.
Ratify uses cryptography, but it is not a cryptocurrency product. There is no coin, no token, no wallet, and no chain dependency. It is pure asymmetric cryptography—signed certificates, revocation, and verification—designed for the latency and scale requirements of the agent economy.
OAuth is designed for user-to-server authorization. It is bearer-token based, which makes it brittle under replay attacks and difficult to sub-delegate. Ratify is cross-party, signature-based, and supports multi-hop sub-delegation. Ratify also survives replay through its challenge-response mechanism and is channel-agnostic (voice, video, API, and Physical AI all use the same bundle format).
Policy servers answer 'is this subject allowed to do that?' over an HTTPS call — your gateway asks the vendor, the vendor replies yes or no, and you trust the reply. The vendor becomes the trust anchor; verification requires a live network call; the receiving party hasn't actually verified anything cryptographically. Ratify is structurally different: a signed delegation cert travels with the agent, and anyone with the principal's public key can verify it in under a millisecond, offline, with no vendor in the path. The two are complementary — Ratify proves who authorized an agent within what scope, and a policy engine can decide what those proven scopes mean inside your application. We expose this in the SDK via the PolicyProvider hook (SPEC §17.2).
Agents operate in contexts where a human is not present at the moment of the transaction. Legacy systems rely on human-in-the-loop auth (like 2FA or OAuth redirects). Ratify allows a human to delegate authority to an agent ahead of time, which the agent can then prove cryptographically at the point of action.
Physical AI refers to embodied agents like delivery drones, warehouse robots, autonomous vehicles, and infrastructure actuators. Ratify provides a canonical way to verify authorization for these agents in the real world, often using geo, time, and speed constraints built directly into the delegation certificate.
Yes. v1 of the protocol uses hybrid signatures, combining Ed25519 with NIST-standardized ML-DSA-65 (FIPS 204, post-quantum). Both component signatures must verify. This ensures that even if a cryptographically relevant quantum computer is developed, authorization bundles signed today remain unforgeable.
Yes. The Ratify Protocol specification is open under CC-BY-4.0, and our reference SDKs (Go, TypeScript, Python, Rust) are licensed under Apache-2.0. We build the managed infrastructure (hosted verifiers, audit logs, revocation) that makes the protocol enterprise-ready.
Two audiences. Enterprise IT and security teams who need to authorize AI agents acting on behalf of their employees and customers under compliance constraints (SOX, FINRA, NYDFS, HIPAA, EU AI Act). And AI agent platform developers who embed the SDK so their agents are verifiable wherever they act.
No. The protocol and SDKs (Go, TypeScript, Python, Rust) are free forever under Apache-2.0. Identities AI sells Ratify Verify — the managed control plane with hosted revocation, audit archive, and policy enforcement — to enterprises deploying agents at scale.
The Ratify Protocol is the open, free, peer-verifiable cryptographic primitive. Ratify Verify is the managed control plane Identities AI sells on top of it — hosted revocation push, no-code policy, compliance-grade audit ledgers with chained verification receipts, and SSO-bound anchor resolution. Verify wires into the SDK's provider hooks (RevocationProvider, PolicyProvider, AuditProvider, AnchorResolver). Verify is in private alpha; the waitlist is open at identities.ai/coming-soon.
Each principal publishes a signed revocation list — either themselves or via a registry acting on their behalf. Verifiers cache the list with a short TTL and fail closed on sustained unreachability. The protocol's RevocationProvider hook (SPEC §17.1) is the integration point; Ratify Verify provides a hosted revocation push so updates propagate to every verifier in the network within seconds.
A VerificationReceipt is a hybrid-signed (Ed25519 + ML-DSA-65) attestation that a specific ProofBundle was verified at a specific time with a specific outcome. Receipts chain by prev_hash, so missing or backdated entries are detectable — giving you a tamper-evident audit ledger by construction, without a separate immutable-storage service. Receipts are optional; the protocol does not auto-issue them. Added in v1.0.0-alpha.7 (SPEC §17.5).
Through the AnchorResolver provider hook (SPEC §17.8). On every successful verify, the resolver maps the verified human_id back to the external Anchor — typically your SSO subject, an email, or a government ID — that was registered when the HumanRoot was minted. Downstream audit providers observe identity-bound receipts. Resolver errors are non-fatal, so directory outages don't break verification.
/ Get started
We are currently in private alpha, working with select design partners to establish the identity layer for the agent economy.
Enterprises
Secure your agent interactions across voice, video, and API.
Platforms
Provide verifiable identity to every agent on your platform.