/ Definition
AI agent authorization
needs to be portable.
AI agent authorization is the missing layer between IAM, identity providers, agent transports like MCP and A2A, and policy engines. It answers one action-time question those systems do not answer by themselves: what authority did this principal delegate to this agent, for this action, right now?
Ratify Protocol makes that answer a signed delegation proof. The proof travels with the agent, so any receiving party can verify it offline, in milliseconds, with no vendor in the path.
The stack, in plain English
IAM, identity, and registration
Okta, Auth0, WorkOS AuthKit, Microsoft Entra, Google Workspace, OAuth, OIDC, SAML
Establish who a principal or registered client is.
Transport and workflow
MCP, A2A, REST, gRPC, agent frameworks
Move tool calls, messages, and agent-to-agent work through the system.
Portable authorization proof
Ratify Protocol
Prove the caller had delegated authority to make this specific call before the transport executes it.
Local policy decision
OpenFGA, Zanzibar, OPA, application policy
Decide what the proven scopes mean inside a specific product or resource model.
What your existing stack still does
IAM / SSO
Okta, Auth0, WorkOS AuthKit, Microsoft Entra, Google Workspace, OAuth, OIDC, SAML
Still does: Authenticates people and organizations, manages sessions, and enforces enterprise access.
Ratify adds: A portable proof that one of those principals delegated bounded authority to an agent.
Agent transport
MCP, A2A, REST, gRPC, agent frameworks
Still does: Moves tool calls, messages, tasks, and agent-to-agent handoffs.
Ratify adds: A proof attached to the call so the receiver can verify authority before execution.
Policy engines
WorkOS FGA, Auth0 FGA, OpenFGA, Zanzibar, OPA
Still does: Interprets local resource rules inside one application or organization.
Ratify adds: A cryptographic fact for the policy engine to reason over: who delegated what to which agent.
Why bearer tokens were enough for web apps
and not enough for agents.
Web apps
Why tokens worked: A human was usually present, the app called one service at a time, and a bearer token mostly represented a session between one client and one API.
What agents change: An agent may act later, across many tools, without the human present, and may delegate subtasks to other agents.
API integrations
Why tokens worked: The integration was known ahead of time, configured by developers, and usually stayed inside one vendor or account boundary.
What agents change: Agentic workflows are dynamic: a tool call can cross vendors, organizations, channels, and physical systems at runtime.
Audit and compliance
Why tokens worked: Logs could often reconstruct what a user or app did after the fact, because the workflow was predictable and server-centered.
What agents change: Receivers need a pre-action proof: who authorized this agent, what was it allowed to do, and when did that authority expire?
Bearer tokens still matter. They are just not the native trust primitive for agentic work. A bearer token says, “the holder can use this credential.” Ratify says, “this principal delegated this authority to this agent for this action, and anyone can verify that before execution.”
Why this is not “yet another protocol”
MCP, A2A, REST, and gRPC are how work moves. Okta, Auth0, WorkOS AuthKit, Microsoft Entra, Google Workspace, OAuth, OIDC, and SAML help establish accounts, sessions, clients, and credentials. Policy engines decide what a proven subject can do inside one application.
None of those gives the receiving party a portable, signed proof that says: this human or organization delegated this exact authority to this exact agent, for this exact action, before the action happened.
That is the primitive Ratify adds. It is the proof layer for agentic workflows: small enough to attach to an MCP tool call, strong enough for regulated audit, and portable enough for another company to verify without trusting your SaaS account or calling your vendor.
What a verifier checks
- 1The proof is signed by the authorizing principal.
- 2The agent signs a fresh verifier-issued challenge.
- 3The delegation has not expired.
- 4The requested action is inside the delegated scope.
- 5Revocation and constraints pass for the verifier's environment.
What Ratify is not
Ratify is not an IAM system, identity provider, agent directory, OAuth/OIDC/SAML server, MCP server, A2A replacement, or policy engine. IAM establishes principals and sessions. MCP and A2A move agent work. Policy engines interpret local rules. Ratify proves delegated authority in a portable format that a verifier can check before an agent acts.