Verifiable Intent
How do you prove an AI agent did what you asked — and nothing more?
When a human taps a card, the tap IS the consent. When an agent transacts, there is no tap. Verifiable Intent (VI) fills that gap — a cryptographic, tamper-evident delegation chain binding AI agent actions to human-approved scope. Open-sourced by Mastercard and Google.
The Three Layers
Every agent action traces back to a human through three cryptographically bound layers:
| Layer | Name | Who Creates | What It Proves |
|---|---|---|---|
| L1 | Identity | Credential provider | Who you are (issuer signs user's public key) |
| L2 | Intent | User | What you authorized (constraints, budget, scope) |
| L3 | Action | Agent | What was done (within L2 constraints) |
Each layer signs the next via cnf (confirmation) claims. L2 binds to L1 via sd_hash. L3 binds to L2 the same way. The chain is unforgeable — break one link, the whole proof fails.
L1: IDENTITY (credential provider signs user key)
| cnf.jwk binding
L2: INTENT (user sets constraints + binds agent key)
| sd_hash binding
L3: ACTION (agent proves it stayed within scope)
| checkout_hash binding
VERIFICATION (verifier checks the full chain)
Two Modes
| Mode | Layers | Use Case | Human Involvement |
|---|---|---|---|
| Immediate | L1 + L2 | User reviews final transaction, signs directly | User confirms each transaction |
| Autonomous | L1 + L2 + L3 | User sets constraints, agent acts within them | User sets scope once, agent acts repeatedly |
Autonomous mode is where VI earns its value. The user says "buy office supplies under $500/month from these three vendors." The agent acts. The merchant can verify the agent had authority. The issuer can verify the chain of consent. Nobody trusts anybody — they verify.
Eight Constraints
L2 intent supports eight machine-verifiable constraint types:
| Constraint | What It Bounds | Example |
|---|---|---|
| Amount bounds | Min/max transaction value | "No single purchase over $200" |
| Merchant allowlist | Who the agent can buy from | "Only from approved vendors" |
| Budget caps | Total spend over period | "$500/month maximum" |
| Recurrence terms | Frequency of transactions | "Weekly subscription only" |
| Category restrictions | What can be purchased | "Office supplies only" |
| Time windows | When agent can transact | "Business hours only" |
| Geographic limits | Where transactions occur | "NZ merchants only" |
| Approval thresholds | When to escalate to human | "Human approval above $100" |
Verification
A verifier (merchant, issuer, or auditor) checks three things:
| Check | What It Proves | Failure Means |
|---|---|---|
| Delegation chain | Each layer's signing key is bound by the previous layer's cnf claim | Agent isn't authorized |
| Constraint satisfaction | L3 values fall within L2 constraints | Agent exceeded scope |
| Checkout-payment binding | checkout_hash and transaction_id cross-reference | Payment doesn't match intent |
All three must pass. The spec mandates ES256 signature verification at every layer.
The VVFL Connection
VI is the VVFL made into a protocol. Each station maps:
| VVFL Station | VI Layer | Function |
|---|---|---|
| Capture | L1 Identity | Establish who you are |
| Priorities | L2 Constraints | Define what matters (scope, budget, limits) |
| Attention | L3 Action | Direct effort within constraints |
| Standards | Verification | Gauge reads reality — did action match intent? |
| Reflect | Constraint satisfaction | Controller asks: was scope respected? |
| Evolve | Updated constraints | Next cycle's L2 is informed by this cycle's results |
Without VI, the VVFL has no gauge. With VI, every agent action is measured against its stated intent. The feedback loop closes.
Protocol Position
VI is not a payment protocol. It is the authorization proof layer that sits orthogonal to every payment protocol:
| Protocol | What It Does | What It Doesn't |
|---|---|---|
| A2A | Agent-to-agent communication | Prove authorization scope |
| MCP | Agent-to-tool access | Verify intent constraints |
| UCP | Commerce operations (checkout, cart) | Prove delegation chain |
| AP2 | Payment authorization | Prove human consent chain |
| ACP | Merchant commerce | Prove delegation chain |
| VI | Authorization proof | Handle transport or settlement |
VI credentials travel alongside any of these protocols without transport-layer changes. The spec is intentionally protocol-agnostic.
The Mandate Connection
Our mandate Move module is a Sui-native implementation of VI's core pattern:
| VI Concept | Mandate Module | Difference |
|---|---|---|
| L1 Identity | identity module — 4 entity types, attestation providers | Compiler-enforced via capabilities, not SD-JWT |
| L2 Intent | IntentMandate — budget, items, constraints | On-chain object with explicit ownership |
| L3 Action | CartMandate — merchant counter-offer | Shared object for cross-party coordination |
| Verification | Status flow: Open → Fulfilled → Cancelled | Move's type system prevents invalid transitions |
| Constraint enforcement | Budget field + agent identity check | Compiler prevents unauthorized access |
Key difference: VI uses SD-JWT delegation chains (runtime cryptographic verification). Move uses linear types and capabilities (compile-time structural enforcement). Move's approach eliminates classes of bugs that SD-JWT can't — you literally cannot write code that bypasses the authorization, because the compiler won't let you. See smart contract safety comparison.
The bridge: A Sui-native VI implementation could use Move's capability pattern for on-chain enforcement while emitting SD-JWT credentials for off-chain verification — giving both compile-time safety AND cross-protocol interoperability.
Commissioning Alignment
VI's verification model maps directly to the commissioning protocol:
| Commissioning Level | VI Equivalent | Evidence |
|---|---|---|
| L0 Spec | L2 Intent written | PRD exists with constraints |
| L1 Schema | L1 Identity established | Backend can authenticate |
| L2 UI connected | L3 Action possible | Agent can transact |
| L3 Tested | Constraint satisfaction verified | Automated tests prove scope respected |
| L4 Commissioned | Full delegation chain verified | Independent commissioner proves intent matched outcome |
L4 commissioning IS verifiable intent applied to software delivery. The builder (agent) acts within the PRD (intent). The commissioner (verifier) checks the delegation chain (spec → build → outcome).
Context
- Agent Commerce — The standards war and VI's role in it
- AP2 Protocol — Payment authorization that VI complements
- Smart Contracts — On-chain enforcement of intent
- Sui Development — Mandate module as Sui-native VI
- VVFL Loop — The feedback loop VI closes
- Commissioning Protocol — L0-L4 as verifiable intent for software
- Standards — What protocols become when they prove reliable
- Protocols — Where VI sits in the hierarchy
Links
- Verifiable Intent Spec — Draft v0.1 specification
- Protocol Landscape — How VI relates to other protocols
- GitHub — Open source, Apache 2.0
- Verifiable Intent Home — Overview and rationale
Questions
If every agent action must trace back to a human-approved scope, what happens when the scope itself was wrong?
- When VI proves the agent stayed within constraints but the outcome is still bad, is the protocol working or failing?
- Move's compiler prevents unauthorized access structurally. SD-JWT verifies it cryptographically at runtime. Which approach wins when agents transact at machine tempo?
- If commissioning IS verifiable intent applied to software delivery, should every L4 commission produce a VI-compatible credential?
- What constraint type is missing from VI's eight that would matter most for DePIN device transactions?