Agent Commerce · Authorization
Delegated Authorization
Principals grant AI agents permission to spend money within defined limits. Every delegation grant is cryptographically signed — and bound to every transaction receipt it authorizes.
Delegated authorization is what separates autonomous spending from unauthorized spending. Without it, AI-initiated payments have no traceable link to human intent. With it, every transaction is grounded in a verifiable authorization chain.
Properties of a delegation grant
The delegation grant specifies exactly what the agent is permitted to do: which categories, which counterparties, which rails, and what maximum amounts. The policy engine enforces scope at evaluation time.
The delegation grant is signed by the principal at creation time. The signature is cryptographically bound to the agent's KYA attestation — establishing an unbreakable link between intent and identity.
Every delegation grant has an explicit validity window. Grants expire automatically — the agent cannot continue spending after the authorization window closes without a new grant from the principal.
A principal can revoke a delegation at any time. Revoked delegations are blocked at the policy evaluation layer — in-flight requests that pass the revocation check before execution still produce a revocation audit record.
In multi-agent workflows, an orchestrating agent may delegate a subset of its authorization to a sub-agent. Nested delegation chains are fully recorded — each link is bound to its parent grant.
Every signed receipt references the delegation grant ID that authorized it. This creates a direct, auditable link from the transaction back to the principal intent — without requiring access to internal systems.
Delegation grant record
A delegation grant is a signed, structured record — not a session token. It persists independently of the agent session and is referenced by every receipt it authorizes.
{
"delegation_id": "del_01j9k2m...",
"principal_id": "org_acmecorp",
"agent_id": "agent_01j9k2m...",
"granted_at": "2026-04-22T10:00:00Z",
"valid_until": "2026-07-22T23:59:59Z",
"scope": {
"max_transaction_usd": 500,
"daily_limit_usd": 2000,
"allowed_categories": ["api-credits", "dataset-purchase"],
"allowed_counterparties": ["vendor_*"],
"rails": ["stripe", "usdc-base"]
},
"parent_delegation_id": null,
"revoked": false,
"principal_signature": "ed25519:MEYCIQDx...",
"kya_attestation_id": "kya_01j9k..."
}The principal_signature covers the full canonicalized grant payload. Any modification to scope or validity after signing invalidates the signature — making scope tampering immediately detectable.
Delegated authorization in the transaction lifecycle
The principal specifies the agent, scope, and validity window. The grant is signed and stored — producing a delegation_id the agent will carry into every subsequent transaction.
When the agent initiates a payment, it presents its agent_id and delegation_id. The policy engine validates that the grant is current, not revoked, and that the requested spend is within scope.
If the policy passes, an authorization record is created that references the delegation_id. The authorization is the gate — execution cannot proceed without it.
The signed receipt includes the delegation_id. Any party verifying the receipt can trace it back to the grant — and from the grant back to the principal — without platform access.
Delegation grant properties at a glance
| Property | Behavior | Verifiable? |
|---|---|---|
| Delegation record | Signed at grant time by principal | Yes — Ed25519 |
| Agent can act without principal present | Yes — within scope | Yes — KYA + delegation verified at policy eval |
| Scope changes require | New delegation grant | Old grant revoked, new grant issued |
| Revocation effect | Immediate — policy blocks all subsequent requests | Revocation event recorded in audit log |
| Receipt binding | Every receipt references delegation_id | Traceable to principal without platform access |
| Nested delegation | Sub-agent gets subset of parent scope | Parent grant ID recorded in child grant |
Every agent transaction, cryptographically receipted.
Agent Commerce issues Ed25519-signed receipts for every autonomous payment. Policy-gated authorization, tamper-evident records, and public verification — no vendor contact required.
- 1Authorize via policyDefine spend rules. Agents operate within them.
- 2Receive a signed receiptEd25519-signed proof for every transaction.
- 3Verify publiclyAny party can verify the receipt without contacting you.