---
type: Agentic Web Standard
title: "Verifiable Intent"
description: "After an agent completes a purchase on a user's behalf, can the merchant, issuer and consumer all point to the same cryptographic record of what the user actually authorized?"
resource: "https://verifiableintent.dev/spec/"
tags: ["account", "document-format", "vendor-consortium", "agent-checkout", "delegate-user-authority", "audit-agent-actions", "prove-agent-identity"]
status: draft
generated: { by: agenticweb-builder/1.0, at: 2026-10-30T00:00:00Z }
verified: { by: process:agenticweb-engine, at: 2026-10-23T00:00:00Z }
stale_after: 2026-11-22T00:00:00Z
sources:
  - id: ref-1
    resource: "https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html"
    title: "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."
    last_modified: 2026-03-05T00:00:00Z
  - id: ref-2
    resource: "https://verifiableintent.dev/spec/"
    title: "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."
    last_modified: 2026-02-18T00:00:00Z
  - id: ref-3
    resource: "https://github.com/agent-intent/verifiable-intent"
    title: "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."
    last_modified: 2026-09-05T00:00:00Z
  - id: ref-4
    resource: "https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/"
    title: "Mastercard contributed Verifiable Intent to the FIDO Alliance Payments TWG on 2026-04-28"
    last_modified: 2026-04-28T00:00:00Z
---

# Verifiable Intent

Verifiable Intent (VI) is an agentic-web standard (document format — /.well-known/verifiable-intent) at step 9, Account, governed by Mastercard; its status is "Draft". It answers: "After an agent completes a purchase on a user's behalf, can the merchant, issuer and consumer all point to the same cryptographic record of what the user actually authorized?" Implementation status is prototype, last verified 2026-10-23.

# Overview

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 [^ref-2][^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 [^ref-1].

**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 [^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 [^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) [^ref-1]. The public specification is version 0.1-draft, dated 2026-02-18 [^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) [^ref-1][^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.

# Examples

```http
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.
```

# Knowledge Graph

* **Lifecycle Step**: [9 Account](/category/account/index.md)
* **Pairs with**: [Agent Payments Protocol (AP2)](/okf/protocols/ap2.md), [Universal Commerce Protocol (UCP)](/okf/protocols/ucp.md), [Agentic Commerce Protocol](/okf/protocols/agentic-commerce-protocol.md), [Trusted Agent Protocol (TAP)](/okf/protocols/tap.md), [AP2 Checkout Mandate](/okf/protocols/ap2-checkout-mandate.md), [Agentic Mobile Protocol (AMP)](/okf/protocols/amp-ant.md)
* **Related terms**: [Know Your Agent](/okf/terms/know-your-agent.md), [Human Not Present](/okf/terms/human-not-present.md), [Verifiable Intent](/okf/terms/verifiable-intent.md), [Agentic EoR (Employer / Entity of Record)](/okf/terms/agentic-eor.md), [Buyer of Record & Merchant of Record (Agentic Commerce)](/okf/terms/buyer-of-record.md)
* **Compared in**: [3-D Secure & Card Checkout vs AP2, ACP & UCP (classic vs agentic)](/compare/3d-secure-vs-ap2/index.md), [Verifiable Intent vs Agent Payments Protocol (AP2)](/compare/vi-vs-ap2/index.md), [Verifiable Intent vs Agentic Commerce Protocol](/compare/vi-vs-agentic-commerce-protocol/index.md), [Verifiable Intent vs EMV® Agentic Payments – Framework for Specifications](/compare/vi-vs-emv-agentic-payments/index.md), [Verifiable Intent vs Trusted Agent Protocol (TAP)](/compare/vi-vs-tap/index.md), [Verifiable Intent vs Agent Decision Commitments for Payments](/compare/vi-vs-agent-decision-commitment/index.md), [Verifiable Intent vs Agent Audit Trail](/compare/vi-vs-agent-audit-trail/index.md)

[^ref-1]: 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)
[^ref-2]: 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/)
[^ref-3]: 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)
[^ref-4]: Mastercard contributed Verifiable Intent to the FIDO Alliance Payments TWG on 2026-04-28 (https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/)
