Mastercard's Verifiable Intent is an open standard for proving an agent was authorized to make a purchase. It addresses the same problem Treeship solves: how do you prove intent and authorization in agent commerce?
The two systems approach this from different angles but converge on the same core primitive: a signed authorization that binds to a specific action.
The alignment
Verifiable Intent proves: "this agent was allowed to buy this thing."
Treeship proves: "this human approved, this agent acted, here is the cryptographic evidence."
Both start from the same assumption: bearer tokens are not enough. A token proves the agent has access. It does not prove the agent was authorized for a specific action. Authorization needs to be scoped, signed, and verifiable.
How Treeship maps to Verifiable Intent
The concepts translate directly:
| Treeship | Verifiable Intent | What it does |
|---|---|---|
| Approval artifact | Intent credential | Proves authorization was granted |
| Nonce binding | Authorization binding | Links authorization to a specific action |
| Verify page / CLI | Verification endpoint | Confirms the chain is valid |
| Receipt chain | Audit trail | Full history from intent to execution |
The mapping is not accidental. Both systems are solving for the same threat model: an agent acting without authorization and no one being able to prove it after the fact.
A concrete example
An agent purchasing cloud compute credits:
Treeship side
# Human approves
treeship attest approval \
--approver human://devops-lead \
--description "approve up to $200 for cloud compute credits" \
--allowed-actor agent://procurement \
--allowed-action cloud.credits.purchase \
--max-uses 1
# Agent acts
treeship wrap \
--actor agent://procurement \
--action cloud.credits.purchase \
-- curl -X POST https://api.cloudvendor.com/v1/credits \
-d '{"amount": 150, "currency": "USD"}'
# Verify
treeship verify last --fullVerifiable Intent side
The approval receipt from Treeship contains the same information a Verifiable Intent credential needs: who approved, what was approved, the scope, the binding to a specific action.
The bridge
A Treeship approval receipt can be translated into a Verifiable Intent credential. The fields map:
- Approver identity -> Verifiable Intent issuer
- Approval scope -> Verifiable Intent authorization constraints
- Nonce -> Verifiable Intent binding reference
- Ed25519 signature -> Verifiable Intent proof
The translation is mechanical. The cryptographic foundation (Ed25519 signatures, content-addressed IDs) is compatible with Verifiable Intent's requirements.
Future
Treeship could emit Verifiable Intent-compatible credentials alongside its native receipts. A single treeship attest approval could produce both a Treeship artifact and a Verifiable Intent credential, letting the agent present whichever format the counterparty expects.
This is not built yet. The foundation is in place: the signature scheme, the approval model, the nonce binding. The credential format translation is engineering work, not a design change.
For now, Treeship receipts and Verifiable Intent credentials solve the same problem with compatible approaches. As agent commerce matures, the standards will converge. Treeship will be ready.