Ratify Protocol Security

• The delegation chain is cryptographically valid.
• Each delegation continues to the next subject and key.
• The requested scope and encoded constraints are satisfied by receiver context.
• The proof is within its validity period and meets the verifier freshness policy.
• The presenting agent proves possession of the delegated key.
• Revocation state meets the verifier’s configured age and availability policy.

A valid proof does not establish that the root key belongs to a particular real-world person or organization. Trust anchors are chosen by the receiver. It also does not establish that external facts are true, that an action is compliant, or that an agent is benevolent. Those decisions remain with the receiving application.

Verify at the action boundary, not only when a workflow starts. Bind the proof to the exact operation, audience, resource, and verifier challenge. Recheck authority after pauses, retries, delegation hops, or other events that could change whether the action remains valid.

Compiled reference verifiers are benchmarked at under a millisecond on the reviewed baseline, but your deployment should measure its own complete verification path and revocation policy.

Ratify Protocol is open-source alpha software. It has not undergone an independent security audit, and no independent production deployment has been publicly established. Review the repository before relying on it for consequential actions.

Security reports for the website or reference implementations should be sent to security@ratifyprotocol.com. Identities.AI, Inc. will acknowledge a report and coordinate a response.