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 — developed by Mastercard and published in March 2026 — 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.
Every VI implementation issues credentials. Only this one traces those credentials back through a governance architecture to the organization that authorized the agent in the first place. Two verification chains, one join key.
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.
A complete credential provider implementation — issuance, mandate creation, verification, and constraint enforcement — following the open VI 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 VI 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 VI 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 VI 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.
VI 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 VI 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 — VI + governance (public, no auth) GET /api/v1/verify/chain/:agentId // Issuer public keys GET /.well-known/jwks.json
This is a test credential provider operating within the open VI ecosystem — not a production payment processor. It issues real credentials using real cryptography against the real specification. It does not process actual financial transactions.
Verifiable Intent is how agents prove authorization. Identity Architecture is how organizations prove accountability. This server is where the two chains meet.