The comparison
Four tables, on four axes, using the same criteria each time. They are not rankings: the things compared here are mostly not substitutes for one another, and a serious deployment uses several at once. The point is to make the trade in each case legible, so a choice can be made deliberately rather than by default.
This page is revised as the field moves — it is the part of the hub most likely to be wrong first. Where an approach simply does not address a criterion, the cell says so rather than scoring it low.
Spend controls
Every approach to bounding an agent's spending sits somewhere on a trade between expressiveness and unavoidability. Controls attached to an instrument are enforced whether or not the agent cooperates, and can only express what the authorisation message carries. Controls evaluated before the payment can express anything you can compute, and are only reached if the agent calls them.
A serious deployment uses both: a policy that can express the real rule, and an instrument-level cap that holds when the policy is bypassed.
| Approach | Per-transaction amount | Cumulative budget | Counterparty | Purpose | Time window | Enforced where | Bypassable by the agent |
|---|---|---|---|---|---|---|---|
| Virtual / vendor-locked card | Yes | Card limit only | Merchant lock | No | Card validity | Card authorisation | No |
| MCC blocklist | No | No | Category only | Approximate | No | Card authorisation | No |
| Agentic token (network) | Yes | Usage rules | Merchant, category | No | Timeframe | Network authorisation | No |
| Shared payment token (ACP) | Yes | No | One merchant | No | Short expiry | Payment provider | No |
| AP2 mandate constraints | Yes | As issued | As issued | Partially | As issued | Relying party | No |
| Policy engine (pre-transaction) | Yes | Yes, stateful | Yes, with history | Yes | Yes, with hours | Before execution | Yes, if not called |
Scroll the table sideways for the remaining columns.
The two right-hand columns are the whole argument. Instrument-level controls cannot be bypassed and cannot express purpose; pre-transaction policy can express purpose and can be bypassed. Neither is sufficient alone, and the failure modes are different enough that having both is not redundancy.
The 'cumulative budget' column is where most single-mechanism designs fall down. A per-transaction limit and a merchant lock still permit the same correct-looking payment forty times.
Payment credentials
The credential question is really a blast-radius question. Everything here is an improvement on giving an agent a card number, and they differ in how much an attacker gains by stealing one.
| Approach | What the agent holds | Scope | Lifetime | Loss if leaked | Carries policy | Standardised by |
|---|---|---|---|---|---|---|
| Card on file | Card credentials | Anywhere the card works | Until expiry | Full card limit | No | — |
| Virtual card | A surrogate card number | One vendor, one limit | Until cancelled | That card's limit | Limits only | Issuer products |
| Agentic token | A network token | User, agent, merchant, category | Per token rules | Bounded by token rules | Yes, within format | Mastercard Agent Pay |
| Shared payment token | A delegated payment token | One merchant, one amount | Short | One transaction | Amount only | ACP delegate payment |
| AP2 mandate | A signed verifiable credential | As constrained at issuance | As issued | Bounded by mandate | Yes, at issuance | AP2 / FIDO |
| Authorisation artifact | A one-time signed approval | One approved action | Single use, short | One replay attempt, if not claimed | Decision, not credential | mnd8t |
| Funded stablecoin wallet | A key | Anything payable on-chain | Until drained | The balance | No | x402 for settlement |
Scroll the table sideways for the remaining columns.
Reading down the 'loss if leaked' column gives you the honest ranking, and it is roughly the order of the table. Reading down 'carries policy' shows the cost of that safety: the tightest-scoped credentials carry the least information about why the spend was permitted.
The last row is the one most often deployed by teams moving fast, and the one whose loss column should give the most pause.
Policy engines
Whether policy is evaluated by a network, a spend-management platform, an in-house service or a dedicated engine, the properties that make the result defensible are the same. This table is a specification to hold any candidate to, including us.
| Why it matters | |
|---|---|
| Deterministic | Same proposal, same policy version, same answer — always. Without it, no decision can be tested before deployment or replayed afterwards. |
| No model in the decision path | A probabilistic decision cannot be reproduced in front of an auditor a year later. Use a model to draft policy, never to enforce it. |
| Versioned and immutable | The decision must name the exact policy version, and that version must not be editable afterwards, or 'what authorised this?' has no answer. |
| Rule-by-rule trace | A score is not an explanation. The output should name which rules passed, which failed, and in what order they were evaluated. |
| Three outcomes, not two | Allow and deny alone force a choice between a useless agent and an unsafe one. Escalation is what lets the policy stay tight. |
| Stateful budget | Cumulative spend, velocity and counterparty history are where the real limits live. An engine that only sees one transaction cannot enforce them. |
| Shadow mode | You cannot responsibly deploy a blocking control without first measuring what it would have blocked on real traffic. |
| Independently verifiable output | A decision that can only be verified by asking the system that made it is a log entry, not evidence. |
| Outside the money path | An engine that never holds funds or credentials cannot move money if it is compromised, and is not performing a regulated payment service. |
Two of these are frequently traded away and should not be. Determinism goes first, because putting a model in the loop makes the demo better and the audit impossible. Versioning goes second, because it is invisible until the first time someone asks what the policy said in March.
Delegated authority models
Four structurally different answers to the same question. They differ most in what happens under stress: when the agent misbehaves, when the network is unavailable, when authority must be revoked mid-flight, and when someone has to prove afterwards what was permitted.
| Approach | Authority lives in | Evaluated by | Revocation | Works offline from the issuer | Evidence produced | Expressiveness |
|---|---|---|---|---|---|---|
| Credential-embedded (agentic token) | The token | The network, at authorisation | Deactivate the token | No — the network must be in the path | Authorisation records | Bounded by token format |
| Credential-carried (AP2 mandate) | A signed credential the agent presents | The relying party | Under-specified; short lifetimes in practice | Yes — signatures verify offline | Signed mandates, both stages | Constraints fixed at issuance |
| Policy-evaluated (engine) | A versioned mandate held by the delegator | The engine, before execution | Publish a new version; effect is immediate | N/A — the engine is the issuer | Signed decision receipts with reasons | Anything computable, including state |
| Instrument-scoped (virtual card) | The card's own limits | The issuer, at authorisation | Cancel the card | No | Card statements | Amount, merchant, category |
Scroll the table sideways for the remaining columns.
Revocation is the column to read first, because it is the one everybody discovers late. Cancelling a card and deactivating a token are immediate and coarse. Republishing a policy is immediate and precise — and only binds the agents that ask. Revoking a credential already in an agent's hands is the genuinely unsolved case, which is why most credential designs lean on short lifetimes instead.
The offline column explains why credential-carried designs keep being proposed despite that weakness: they are the only ones that let a relying party check authority without a live call to the party that granted it.
Where mnd8t sits in these tables
In the first table mnd8t is the “policy engine (pre-transaction)” row: it can express purpose, stateful budget and counterparty history, and it is bypassable by an agent that never calls it — which is why we tell customers to keep an instrument-level cap underneath. In the second it is the authorisation artifact: not a payment credential at all, but a one-time signed approval an executor redeems. In the third it is the specification we hold ourselves to, and the limitations page says where we do not yet meet it. In the fourth it is the policy-evaluated row.
The honest summary: mnd8t does not replace a network token, a virtual card or a commerce protocol. It replaces the part of the design that is currently a spreadsheet, a code review and a hope that the agent behaves.
Last reviewed 8 September 2026. Corrections: hello@mnd8t.com.