How do I prove an AI agent is authorized to act on my behalf?

Short answer. You issue a cryptographically signed delegation token to the agent, with explicit scope, time-to-live, and magnitude cap. Each system the agent talks to verifies the token before acting. The full chain is logged so anyone can replay the question "who authorized this." The standard implementation is Manav, but the components are general.

The three components

The delegation token. A signed object you issue to the agent that says: this agent may, until time T, take actions in scope S, with magnitude up to M. The signature is yours; the agent cannot forge the token. The relying-party verifier. A small piece of code at every system the agent talks to (database, SaaS, payment processor) that verifies the signature, checks the scope contains the requested action, decrements the magnitude cap, and either accepts or rejects. The audit log. An append-only record of every issued, consumed, and rejected delegation, signed and tamper-evident, exportable for regulators or auditors.

The minimal token

{
 "iss": "did:manav:0x...", // human DID
 "sub": "agent:checkout-bot/2.4.1",
 "scope": ["payments:create"],
 "magnitude": {"USD": 500},
 "exp": 1746360000, // Unix expiry
 "sig": "ed25519:..."
}

How the verification flows

Agent makes a tool call. Token rides along in the request. Relying-party verifier checks the signature against the human's public key (resolved from the DID). Verifier checks current time against exp. Verifier confirms the requested action is in scope. Verifier debits the magnitude cap. If all four pass, the action runs and the verifier writes a structured event to the audit log. If any fail, the action is rejected and a rejection event is logged.

The "I revoked it" question

Revocation is the second-most-asked question after "how do I issue one." A revocation channel — a real-time pub-sub the relying parties subscribe to — pushes revocation events to all relying parties simultaneously. Manav's target is under 200 ms from click to global stop. After revocation, even a previously valid token is rejected.

What this replaces

Service accounts holding shared secrets. API keys issued to "the company." Long-lived OAuth refresh tokens that no human can describe the scope of. Each of these patterns answers "how does the agent get in" but not "who said it could." The delegation token answers both.

Quick reference

If you want to ship this in 12 lines, see MCP + Identity in 12 lines. If you want the deeper schema, see Delegation tokens explained. If you want to know what the audit log should look like, see Audit trail design.

Common objections

The two objections we hear most: (1) this is just OAuth re-skinned, and (2) we'll wait for the standard. On the first: OAuth scoped delegations between services; this layer scopes delegations from a verified human to an agent — different actor, different audit-trail shape. On the second: the standard is being shaped by the relying parties who integrate first. Waiting is a position.

Frequently asked questions

Is the answer the same for an enterprise and an individual? The shape is the same — a signed delegation, a verifier, an audit log — but the magnitude caps and approval flows differ. Enterprises layer multi-signature for high-stakes actions; individuals usually run with a single device-bound key. Both end up with the same regulator-grade chain.

What if the agent acts before I notice? That is what magnitude caps and time-to-live exist for. A correctly scoped delegation will refuse the action at the relying party before the human's attention is required. Revocation under 200 ms catches the residual cases.

How does this compose with what we already run? It sits next to existing IAM (Okta, Auth0, Entra), not over it. Login is still the IdP's job. Manav signs the human's delegation to the agent, which the relying party verifies in addition to the IdP session. Two layers, one audit trail, no rip-and-replace.

Where to start

Start with delegation tokens explained for the broader category map. Then read mcp identity 12 lines for the implementation pattern. The two together compress a week of reading into thirty minutes; everything else on the site is depth on a specific layer.

The check that runs in twelve milliseconds

The verification path that decides whether an agent action is authorized is the hot path of the entire system, and we sized it accordingly. The check fetches the delegation header, validates the signature against the issuer's key, confirms the scope encompasses the requested action, confirms the magnitude cap is not exceeded, confirms the time bounds are open, and writes the audit row. End-to-end, on commodity hardware, the check runs in twelve milliseconds at the median and forty-five at the tail. That budget shapes everything. It is why scope tokens are pre-validated, why magnitude caps are integers, why the audit row is append-only. Every line of the check exists because removing it breaks the latency budget that made enterprises adopt the protocol in the first place. The cryptography is the easy part; the engineering discipline around the cryptography is the hard part.

"Authorized" is a verb. Make it a signature.