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.
VI applies equally to physical agents. A fleet operator sets L2 constraints for delivery drones: geographic bounds, weight limits, time windows. The drone (L3) acts within scope. The recipient verifies the delegation chain. Peaq DID provides the L1 identity layer for machines. The same eight constraints work — the substrate changes, the proof doesn't.
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
- Deterministic vs Probabilistic — Intent is probabilistic, verification is deterministic
- 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
- Peaq — Economy of Things — VI's L1 Identity maps to peaq DID for machine authorization
- Intercognitive Standard — Physical AI coordination where VI constraints apply to devices
- Machine Protocols — Physical agent coordination stack
- Standards — What protocols become when they prove reliable
- Protocols — Where VI sits in the hierarchy
- Agency — VI closes the loop between intent and action — verification that agency was exercised within scope
- Phygital Beings — The agents whose actions VI proves
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?