# Verifiable Intent VI

[9 · Account](/category/account/)

| Verifiable Intent |
| --- |
| Category | [Account](/category/account/) |
| Governed by | Maintained by Mastercard; open to multi-stakeholder contribution per the project's CONTRIBUTING.md; built on FIDO Alliance, EMVCo, IETF and W3C primitives (SD-JWT/RFC 9901, key confirmation/RFC 7800) |
| Status | Draft (v0.1); open-sourced specification and reference implementation |
| Phase | draft |
| Implementation | prototype |
| Adoption | unmeasured |
| Version | 0.1-draft (2026-02-18) |
| Specification | [https://verifiableintent.dev/spec/](https://verifiableintent.dev/spec/) |
| Found at | none |
| Last checked | 2026-09-06 |

[Account](/category/account/) Verifiable Intent (VI) is a credential format -- not a network protocol -- that creates a tamper-evident, cryptographic chain of who authorized what when an AI agent makes a purchase on a person's behalf: a credential provider (bank or card network) signs an identity layer (L1), the user's wallet signs a layer binding specific constraints such as amount range, allowed merchants or line items (L2), and, in 'Autonomous' mode, the agent's own key is bound into a further layer (L3) before it acts without the user present [[2]](#ref-2)[[3]](#ref-3). Selective disclosure (SD-JWT, per IETF RFC 9901) means a merchant, issuer or agent platform each sees only the claims relevant to their role. This is squarely an 'account' spec in this site's sense: its entire purpose is producing a record that can be checked after the fact -- if a dispute arises, all parties can point to the same signed chain rather than reconstructing intent from logs [[1]](#ref-1).

## Overview
What it solves. Before VI, a merchant accepting an agent-initiated purchase has no standard way to prove the user actually authorized that specific transaction, and issuers cannot cleanly separate legitimate agent purchases from fraud. VI gives all parties a shared, privacy-preserving evidence trail [[1]](#ref-1).

What it does not do. VI does not define transport protocols, key management/provisioning, credential-provider enrollment, agent-platform APIs, dispute-resolution process, or regulatory-compliance mapping -- all explicitly out of scope in the spec itself [[3]](#ref-3). It has no discovery mechanism (no well-known path, no registry); a merchant currently has to know out-of-band that a given credential provider or agent supports it.

Current state. Announced 2026-03-05 by Mastercard with a co-authorship/quote from Google's VP of Payments, positioned as complementary to Google's Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP) [[1]](#ref-1). The public specification is version 0.1-draft, dated 2026-02-18 [[2]](#ref-2). As of the announcement, Mastercard describes integration into its own Agent Pay intent APIs as forthcoming ('in the coming months'), not yet live, and the GitHub repository is explicitly labelled Draft (v0.1) [[1]](#ref-1)[[3]](#ref-3).

Who implements it. Mastercard has published an initial reference implementation alongside the specification. Quoted partners in the launch material -- Google, Adyen, Basis Theory, Checkout.com, Getnet, Fiserv, IBM and Worldpay/Global Payments -- describe alignment or planned integration, but none of the fetched sources documents a live, independent production implementation outside Mastercard's own reference code, so implementation is marked 'prototype' rather than 'shipping' or 'multi-implementation.'

Disputed / unknown. No adoption count exists; this record marks adoption 'unmeasured' rather than 'claimed' because no single source stated a specific number of live integrations. Whether VI becomes a true multi-network standard or remains Mastercard-centric (the Mastercard reference credential profile, vct 'https://credentials.mastercard.com/card,' is the only concretely specified profile) is unresolved.

## Discovery and probe

none

```
GET {merchant_origin}/.well-known/verifiable-intent
parse:     Non-normative: the VI specification does not define a discovery mechanism (transport, agent-platform APIs and credential-provider enrollment are explicitly out of scope). This checks a plausible-but-unofficial convention only; a real signal of VI usage is the presence of an SD-JWT credential in a checkout flow with header typ 'kb-sd-jwt' (Immediate/Autonomous modes) or 'sd+jwt' (L1), and vct 'https://credentials.mastercard.com/card' for the Mastercard reference profile.
on absent: Expected in nearly all cases today: VI has not defined a well-known discovery path, and Mastercard states integration into Mastercard Agent Pay's intent APIs is still 'in the coming months' as of the 2026-03-05 announcement.
```

Live check run by [the MCP probe](/mcp/server-card): GET /.well-known/verifiable-intent. A merchant publishes its Verifiable Intent document at a fixed well-known path.

```
{
 "path": "/.well-known/verifiable-intent",
 "expect": {
  "content_type": "json"
 },
 "note": "A merchant publishes its Verifiable Intent document at a fixed well-known path."
}
```

## History
- 2026-09-05 — seeded from Exa Agent research run
- 2026-09-06 — verified against mastercard.com/.../verifiable-intent.html (via firecrawl, curl 403s), verifiableintent.dev/spec/, and github.com/agent-intent/verifiable-intent README and spec/credential-format.md; corrected version date to 2026-02-18, origin.date to 2026-03-05, governance and scope; kept step=account

## Instances

- [Mastercard Verifiable Intent reference implementation](https://github.com/agent-intent/verifiable-intent) · Observed 2026-09-05 · service
- [FIDO Alliance](https://fidoalliance.org) · Observed 2026-04-28 · network
- [ZeroClaw](https://github.com/zeroclaw-labs/zeroclaw) · Observed 2026-03-07 · agent
- [Google (co-developer, AP2/UCP alignment)](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html) · Observed 2026-03-05 · business
- [Adyen, Basis Theory, Checkout.com, Getnet, Fiserv, IBM, Worldpay/Global Payments (alignment/planned integration quotes)](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html) · Observed 2026-03-05 · business

Every instance with its source is listed on the [instances page](/instances/).

## See also

## References

- Mastercard's 2026-03-05 story, co-authored with a Google Payments VP quote, introduces Verifiable Intent as a standards-based trust layer for agentic commerce, aligned with Google's AP2 and UCP, and says Mastercard is 'open-sourcing the Verifiable Intent specification and an initial reference implementation' on GitHub and at verifiableintent.dev; integration into Mastercard Agent Pay's intent APIs is described as forthcoming, not live. — [https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html) (2026-03-05) VERIFIED
- The public specification (version 0.1-draft, dated 2026-02-18) defines a layered SD-JWT credential format binding credential provider, user and agent through key-confirmation claims, with Immediate and Autonomous execution modes and selective disclosure per role. — [https://verifiableintent.dev/spec/](https://verifiableintent.dev/spec/) (2026-02-18) VERIFIED
- The GitHub repository README describes VI's status as 'Draft (v0.1). Maintained by Mastercard; open to multi-stakeholder contribution,' and lists transport protocols, key management, credential-provider enrollment, agent-platform APIs and dispute resolution as explicitly out of scope for the spec. — [https://github.com/agent-intent/verifiable-intent](https://github.com/agent-intent/verifiable-intent) (2026-09-05) VERIFIED

[JSON](/data/protocols/vi.json) · [Markdown](/protocols/vi/index.md)