Cryptographic proof that an AI agent is authorized to act — traced back through the organization that deployed it. The first governance-backed implementation of the Verifiable Intent specification.
When an AI agent acts on behalf of a person, every party in the transaction faces the same question: is this agent actually authorized to do what it's doing?
Verifiable Intent answers that question with cryptography instead of trust. The open specification — a new, standards-based trust paradigm for agentic commerce, from Mastercard, co-developed with Google — creates a layered credential chain that binds an agent's actions to a specific, signed scope of authority. A merchant doesn't have to take the agent's word for it. They can verify the math.
The mechanism is SD-JWT: Selective Disclosure JSON Web Tokens. Each layer of the credential chain cryptographically commits to the layer above it, creating a tamper-evident record from the identity credential through the mandate to the final transaction presentation.
Three layers do three jobs. Layer 1 establishes who the agent is — a credential issued by a provider, binding the agent's identity to a cryptographic key. Layer 2 establishes what the agent may do — a mandate signed by the authorizing human, with specific constraints on spend, merchants, and product categories. Layer 3 proves the agent acted within bounds — a verifiable presentation submitted at the point of transaction.
If the agent tries to exceed its mandate, the credential math fails before the transaction reaches the payment network. Authorization isn't a policy document. It's an equation.
Verifiable Intent proves an agent is authorized. Identity Architecture proves who authorized it, under what governance framework, and with what behavioral specifications. This server is where the two chains meet.
Cryptographic delegation chain from identity credential through mandate to transaction presentation. Each layer signs the next.
Eight machine-verifiable constraint types bound the agent's scope — amount ranges, merchant allowlists, budget caps, product restrictions, recurrence terms.
Selective disclosure ensures merchants see cart details and payment networks see payment details. Neither sees the other's data.
Who issued the credential. What organization the agent belongs to. What behavioral specifications govern its decisions. Whether the agent's governance posture has been independently verified.
Signed document chain from Company Constitution through Soul Document to Agent Passport. Every credential traces to the organizational identity root.
The Soul Document specifies how the agent reasons, communicates, and exercises judgment. The Passport carries the constraint envelope that generates mandate parameters.
Heartbeat reports measure behavioral drift against specification. An agent that deviates from its defined identity triggers governance alerts before it reaches a transaction boundary.
The Passport serial is the join key. A verifier who receives a Verifiable Intent credential can trace it back through the governance chain to the organization — not just "is this authorized?" but "authorized by whom, governed how?"
The governance chain is verified by the Applied Identities Platform. The credential chain is verified by this server. Query both through the public chain verification endpoint to get a single, unified status for any registered agent.
Two verification systems, one join key. The governance chain ends at the Passport. The credential chain begins there. A single query returns both.
Agentic commerce is being built across multiple open protocols. Each handles a different concern. Verifiable Intent handles credential proof. The checkout and payment protocols handle transaction mechanics. Identity Architecture handles organizational governance. They compose — they don't compete.
Aligned with Google's Agent Payments Protocol (AP2). Defines checkout endpoints, lifecycle, and roles. Leaves the credential format open — Verifiable Intent provides a concrete implementation for that open slot.
Transport
REST-based checkout with Shared Payment Tokens via PSPs. SPTs enforce what the payment rails will process. Verifiable Intent proves what the user authorized. Different layers of the same problem — complementary, not competing.
Transport
The credential format layer. SD-JWT delegation chains with constraint enforcement and selective disclosure. Protocol-agnostic — rides alongside UCP, ACP, or any other transport. Proves the agent is authorized.
Credential
The layer no other protocol addresses. A signed document chain from organizational identity root through agent behavioral specification to operational authorization. Verifiable Intent proves the credential math. Identity Architecture proves who stands behind it.
This server bridges both: every Verifiable Intent credential issued here carries an attestation linking back through the Passport to the governance chain. A verifier gets authorization proof and organizational accountability in a single verification flow.
GovernanceCredential
Independent implementation. This server is built by Applied Identities against the open Verifiable Intent specification (v0.1-draft, Apache 2.0 license). It is not affiliated with, endorsed by, or operated on behalf of Mastercard or any other organization involved in the specification's development. It is a test credential provider — it issues real credentials using real cryptography against the published specification, but it does not process financial transactions or connect to production payment networks.
A complete credential provider implementation — issuance, mandate creation, verification, and constraint enforcement — following the open Verifiable Intent specification.
Register an agent with governance attestation, then issue an SD-JWT identity credential binding the agent to an ES256 key pair. The credential carries the agent's passport serial, governance tier, and chain references as selectively disclosable claims.
Create mandates in both modes. Immediate mandates carry final values for human-confirmed transactions. Autonomous mandates carry constraint envelopes — amount ranges, merchant allowlists, product restrictions — and bind to the agent's key for delegation.
Submit paired L3a and L3b presentations for full-chain verification. The server validates every layer: L1 issuer signature, L2 sd_hash binding, L3 cross-binding, constraint satisfaction, temporal validity, and key confirmation throughout.
The full constraint vocabulary from the Verifiable Intent specification: allowed merchants, line item restrictions, payee controls, amount ranges, cumulative budgets, recurrence terms (both merchant-managed and agent-managed), and payment-checkout cross-references.
A single public endpoint returns both the Verifiable Intent credential chain status and the governance chain cross-reference for any registered agent. One query, two verification systems, unified result.
Built directly against the published specification using standard cryptographic libraries. ES256 signing, SHA-256 hashing, SD-JWT serialization per RFC 9901, base64url encoding per RFC 4648 §5. No proprietary extensions.
You need your agents to transact on behalf of your organization with cryptographic proof of authorization — not just an API key and a prayer.
The governance bridge means the credential chain doesn't stop at the agent. It traces back through the Passport to the Soul Document to your Constitution. The merchant doesn't just know the agent is authorized. They can verify who authorized it.
Agent-initiated transactions are coming regardless. The question is whether you can distinguish a governed agent operating within a cryptographic mandate from an unaccountable script with a stolen card number.
Verifiable Intent verification gives you that distinction. The constraint envelope tells you exactly what the agent is allowed to buy, how much it can spend, and who stands behind it.
The specification is open. The reference implementation is Python. This server is a native Node.js implementation you can run against, build on, or use as a test issuer while you develop your own Verifiable Intent integration.
The JWKS endpoint is public. The API accepts standard Bearer tokens. The chain verification endpoint requires no authentication.
RESTful endpoints for credential issuance, mandate creation, and verification. Bearer token authentication with role-based access: issuer, agent, verifier, or admin.
// Register an agent with governance attestation POST /api/v1/agents/register // Issue an L1 SD-JWT identity credential POST /api/v1/credentials/l1/issue // Create an L2 mandate (immediate or autonomous) POST /api/v1/credentials/l2/create // Submit and verify L3 presentations POST /api/v1/credentials/l3/verify // Full chain verification — credential + governance (public, no auth) GET /api/v1/verify/chain/:agentId // Issuer public keys GET /.well-known/jwks.json
Real implementations. Real transactions. Every action traceable to an organizational governance chain.
An AI agent autonomously purchases a Messari research dataset via x402 — with every step governed by a verifiable identity chain.
An AI agent buys raw intelligence, processes it through a governed team, and sells enhanced data products — all autonomously, all on-chain, every transaction traceable to an organizational governance chain.
One organization, all four commerce roles, every link provable. Merchant, verification, agent, and accounting — the complete organizational surface area of a transaction.
An AI agent’s governance chain registered on a public blockchain registry and independently verifiable by anyone — three tiers of disclosure for three audiences, no trust assumption required.
Verifiable Intent is how agents prove authorization. Identity Architecture is how organizations prove accountability. This server is where the two chains meet.