scope402
Payment is not Auth. x402 proves an agent paid. Scope402 proves what that payment lets the agent do.
Demo
About
Payment is not authorization. x402 gives AI agents a native way to pay for services, but successful payment still leaves an important question unanswered: what exactly did the agent buy permission to do? Giving an autonomous agent a reusable API key or broad credential after payment creates unnecessary authority—especially when that agent can make repeated calls or delegate work to other agents. Scope402 turns an x402 payment into bounded permission. Before paying, the agent can inspect the exact authority being offered: the resource, allowed actions, call budget, expiry, and agent identity. After settlement, it receives a signed capability enforcing those limits. The agent can use that capability itself or delegate a strictly smaller capability to another worker without sharing its wallet or root credential. We built two proofs of the same primitive: AuditLab lets an agent pay for repository analysis and receive limited follow-up access. Tessera lets a principal agent purchase a region of a shared world and delegate a smaller region to another agent. Valid actions succeed; wrong-key, replayed, expired, and out-of-scope actions are rejected. Our thesis is simple: x402 can be the payment layer for agent commerce. Scope402 adds the permission layer that comes after payment.
How it's made
Scope402 uses x402 v2 with real native HBAR settlement on Hedera testnet through Blocky402. The key design choice is that the payment terms and permission terms are bound before the agent signs. A merchant first returns an HTTP 402 quote containing the payment requirement plus a Scope402 policy describing the exact subject, resource, tools, call budget, expiry, and policy hash. The agent validates those terms and explicitly approves payment. Once Hedera settlement succeeds, the merchant issues a signed capability carrying the same payment and policy lineage. Every later protected action is independently signed by the agent. Our authorization kernel checks the subject key, resource, tool, arguments, expiry, replay counter, remaining budget, and original payment lineage before allowing the underlying operation. Authorization and the merchant action are committed atomically in PostgreSQL, so failed or unauthorized requests cannot partially mutate the resource or incorrectly consume permission. We also implemented capability delegation. A principal agent can sign authority for a different P-256 worker key, but the child capability must remain inside the parent's resource, tool set, lifetime, and remaining call budget. Delegation can reduce authority, never expand it. AuditLab and Tessera both use this same authorization kernel, demonstrating that Scope402 is infrastructure rather than application-specific access control. External agents can integrate through the TypeScript reference client or documented HTTP/OpenAPI interface: inspect resources, prepare a quote without spending, approve payment, perform authorized work, and delegate narrower authority to another worker. The browser is only an inspection surface; payment keys and capability signing keys remain outside it.