Mastercard Verifiable Intent and Treeship -- Treeship

How Treeship's approval receipts align with Mastercard's open standard for agent commerce.

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.

This post reads a published open standard and describes an open-source integration with it. Treeship is not endorsed by, coordinated with, or speaking for Mastercard or the standard's maintainers. Since 0.31 the integration is treeship vi, an independent implementation of the v0.1 draft tested against the reference SDK.

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 --full

Verifiable 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.