On the Marqeta blog in January, Mike Milotich put it this way: “An AI agent could create and configure a card with very specific instructions from that user in terms of what it wants to go purchase.” That is the correct architecture, and Marqeta is further into it than most. The MCP server issues the virtual card, sets spend and velocity controls, manages transactions and files disputes.
On the Q1 call he was more specific still: you will not send an agent out with your actual card credential, you will provision a virtual card with all the specifications, all the limitations and instructions you are giving that agent, to remove exposure to the underlying credential.
Follow the sentence to the end though. The specifications become authcontrols. The limitations become velocity windows. The instructions do not become anything. There is no field for them, and your docs are explicit that controls apply at the program, card product or user level and cannot be applied to individual cards. So the one thing that would settle a later argument, what the user actually told the agent to buy, exists only as text in a system nobody outside can check.
That gap gets expensive at the dispute. Your own guide says to provide the strongest possible documentation, communication with the merchant, receipts and timelines, and warns that incomplete documentation decreases the likelihood of winning. For an agentic purchase none of those three artifacts exist. Eight receipt types below, seventeen live runs against the open verify route. Three come back false on purpose, because a verifier that never refuses anything is not a verifier.
This is not a card platform and it is not a control plane. Nothing here issues, authorizes, funds or settles anything, and nothing here would improve a platform that processed a hundred and twenty billion dollars of volume last quarter across more than forty countries.
These receipts sit above the control plane. Your controls enforce. A receipt records what the enforcement rested on, in a form a network, an issuer, a program manager or an opposing party can recompute without access to your platform or your customer’s rules.
Nothing on this page is a legal determination. No receipt assigns liability, damages or negligence. Each one states its own boundary in plain words on the page, because an instrument that overclaims fails the first time somebody tests it.
The commercial case is the dispute, not the authorization. You already win the authorization. What is still expensive is a 30 day compliance clock starting on a transaction where the documentation your own guide asks for was never created, because no human was there to create it.
Every row is a documented Marqeta behaviour, followed by the artifact that would make it checkable by someone outside the platform.
Milotich described an agent creating and configuring a card with very specific instructions from the user about what it wants to go purchase. Controls apply at the program, card product and user level, and your docs note that controls cannot be applied to individual cards.
mandate.conformance holds the per-task instruction one layer above the control plane, commits it before the purchase, and recomputes whether the purchase fell inside it.
The instruction becomes an artifact, not a memory.
Under Gateway JIT Funding the customer’s system makes the allow or deny call on its own business rules. That is a good architecture and it puts the burden of explanation on the customer, whose only current evidence is an internal log.
authorization.decision recomputes the verdict from committed inputs and makes the stated reason match the constraint that fired, without exposing the rules.
The customer can explain the call to someone who does not trust them.
When a gateway stops answering, the platform stands in and records COMMANDO_AUTO or COMMANDO_MANUAL. Documenting that openly is the right call. It still leaves an interval where the party that owned the decision was not the party making it.
effect.quiescence proves what did or did not land across declared channels during a bounded interval, and reports honestly when something did.
The window gets closed with evidence instead of assumption.
Your guide is blunt: provide the strongest possible documentation, communication with the merchant, receipts and timelines, because incomplete information decreases the likelihood of winning. In an agentic purchase there was no human, no conversation and no receipt in that sense.
mandate.conformance, authorization.decision and ledger.parity produce documentation that exists at the moment of the transaction rather than being assembled afterwards.
The evidence is already there when the 30 day clock starts.
Mike Milotich described an AI agent creating and configuring a card with very specific instructions from the user about what it wants to go purchase. The card carries the limits. It does not carry the instruction, and the instruction is the thing anyone will later want to see.
Your own docs are precise about where controls live. They apply at the program, card product or user level, and the note says controls cannot be applied to individual cards. That is the correct design for a platform doing a hundred and twenty billion dollars of volume in a quarter. It also means a per-task instruction has nowhere to live inside authcontrols.
mandate.conformance puts it one layer up. MANDATE_LINK and MANDATE_INTEGRITY bind the instruction, MANDATE_PRECEDES_TRANSACTION and VALIDITY_WINDOW put it ahead of the purchase in time, and AMOUNT_WITHIN, CURRENCY_MATCH and SCOPE_MATCH check the purchase against it.
CONFORMANCE_RECOMPUTE derives the verdict instead of reading one. Run the fail case: it returns valid false, because the body claims a pass the arithmetic does not support. NO_PAN keeps the instrument out of the receipt entirely, so the artifact moves between agent developer, program manager and issuer without carrying card data.
What it does not prove, in plain words. It does not say the instruction was appropriate, that the user understood it, or that the purchase was wanted. It attests that a specific transaction fell inside an instruction committed before the transaction occurred.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Under Gateway JIT Funding your docs say it plainly: your system makes a decision to allow or deny the funds based on your own business rules and returns the appropriate response to the Marqeta platform. The customer owns the call. The customer therefore owns the explanation, and today the explanation is a log entry.
DECISION_BASIS_RECOMPUTE and DECISION_RELATION_RECOMPUTE derive the outcome from committed inputs and require the stated reason to match the constraint that actually fired. CONSTRAINT_EVALUATION_RECOMPUTE re-runs the evaluation instead of accepting the answer that came with it.
MANDATE_REF_INTEGRITY, MANDATE_SCOPE_DIGEST_RECOMPUTE and MANDATE_LIVENESS_RECOMPUTE bind the decision to the exact authority in force at that instant, and DECISION_INSTANT_ORDERED fixes when. The revoked case is the one that gets argued: authority that was live when the gateway answered and dead by the time anyone reviewed it.
NO_CARDHOLDER_IDENTITY_LEAK keeps the cardholder out of the artifact. A program manager can hand this to an issuer or a network without handing over the customer, and without exposing the business rules that produced the verdict.
What it does not prove, in plain words. It does not say the decision was correct, fair, or commercially sensible, and it does not reveal the rules or the model. It attests that a stated decision follows from inputs committed before the decision instant.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Marqeta’s own framework sorts agents into high, medium and low trust, with low trust getting single-purpose virtual cards scoped to execute only the specific purchase the user intended. That is exactly right. The open question is what evidence exists, afterwards, for why a given agent landed in the tier it landed in.
ADMISSION_CREDENTIAL_PRESENT and ADMISSION_CREDENTIAL_COMMITMENT fix what was actually presented at the gate, under a commitment rather than a description. ADMISSION_SALT_PRECOMMITMENT means the commitment was fixed before the check, not written up around the result.
CREDENTIAL_VERIFICATION_CANDOUR is the gate that keeps this honest. The receipt has to state how thoroughly the credential was checked, so a light check is recorded as a light check instead of quietly reading like a strong one.
CONDUCT_RECEIPT_LINK, SUBJECT_COMMITMENTS_IDENTICAL and MAXIMUM_SEPARATION_COMMITMENT then tie the admission to what the same actor did afterwards, with a bounded gap. That link is the difference between knowing an agent was admitted and knowing this transaction came from that admitted agent.
What it does not prove, in plain words. It does not say the credential was genuine, correctly issued or properly controlled, and it does not say the tier was the right one. It attests that a committed credential was presented at admission and binds it to subsequent conduct by the same actor within a stated separation.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
A single-purpose virtual card is supposed to stop mattering once the task is done. Revocation is easy to execute and surprisingly hard to prove, because the only interesting question is whether a specific attempt happened before or after the moment authority ended.
AUTHORITY_REFERENCE_MATCH and PRIOR_RECEIPT_LINK tie the revocation to the exact authority being killed and to the receipt that granted it, so the chain does not start mid-story. PRECOMMITMENT_ORDER requires the revocation policy to predate the event.
CLASSIFICATION_RECOMPUTE derives whether the action was before or after rather than accepting a stated answer, and CLOCK_CONSERVATISM resolves any timing ambiguity against the claim instead of in its favour. That single choice is what makes the receipt usable by the party who does not benefit from it.
PROPAGATION_COMMITMENT_MATCH and NOTIFICATION_EVIDENCE_CANDOUR cover the part nobody likes to write down: revocation takes time to propagate, and the receipt says how much rather than pretending it was instant.
What it does not prove, in plain words. It does not say the revocation was justified, timely, or correctly communicated to everyone. It attests to whether a specific action fell before or after a committed revocation instant, under a conservative clock.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Velocity controls run per day, per week, per month, forever, or per transaction. Each window is enforced correctly on its own. The exposure an agentic program actually cares about is the total across many single-purpose cards issued to one user, and that total is not any one window.
MEMBER_LINKS and MEMBER_INTEGRITY bind every contributing transaction under a commitment, and NO_DUPLICATE_MEMBERS blocks the oldest trick in aggregate reporting, which is counting the same item twice or dropping it once it becomes inconvenient.
MEMBERS_IN_WINDOW and MEMBER_MANDATE_MATCH keep the set honest. Everything counted has to be inside the stated window and under the stated mandate, so the total cannot be improved by quietly redefining membership after the number is known.
CURRENCY_UNIFORM prevents mixed-currency sleight of hand, and TOTALS_RECOMPUTE and OUTCOME_RECOMPUTE derive both the sum and the verdict. The receipt states a total that any third party can rebuild from the committed members.
What it does not prove, in plain words. It does not say the spending was appropriate, authorised or wise, and it does not identify the transactions. It attests that a stated total and outcome recompute from a committed set of members inside a stated window.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
merchant_scope takes one identifier at a time. A merchant ID, a merchant category code, or an MCC group. That is a clean and enforceable model per control. It also means the shape of an agent’s spending across many different acceptors is not something any single control is positioned to see.
CONTRIBUTION_SET_INTEGRITY and CONTRIBUTION_WINDOW_MEMBERSHIP fix which transactions are inside the window before anything is counted. DISTINCT_ACCEPTOR_COUNT_RECOMPUTE and DISPERSION_CLASS_RECOMPUTE derive how widely the activity spread rather than accepting a supplied count.
WINDOW_LINK, WINDOW_PREDECESSOR_INTEGRITY and WINDOW_CONTINUITY chain each window to the one before, so an agent cannot erase its own history by starting a fresh window. That is the obvious attack the moment aggregate limits exist at all.
NO_ACCEPTOR_IDENTITY_LEAK is what makes the artifact shareable. A program can prove an agent breached a cross-acceptor limit without disclosing which merchants it used, which matters when the merchants are also customers.
What it does not prove, in plain words. It does not say the spending was fraudulent, unauthorised or harmful, and it does not identify the acceptors. It attests that a stated cumulative position across distinct acceptors recomputes from a committed contribution set inside a linked window.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Commando Mode is one of the more honest things in your documentation. When a customer gateway stops answering, the platform stands in and records the approval as COMMANDO_AUTO or COMMANDO_MANUAL. It is the right engineering choice. It also creates a window where the party that owned the decision was not the party making it.
A negative is not provable from logs, because absence in a log is indistinguishable from a log that stopped. CHANNEL_SET_COMPLETE requires every channel through which an effect could have landed to be declared up front, so the claim covers the whole surface rather than the parts that happened to be watched.
OPENING_ANCHOR_LINK, CLOSING_ANCHOR_LINK, CHAIN_CONTINUITY and GAP_BOUND fix the interval at both ends and cap how large an unobserved gap inside it is allowed to be. ROSTER_RECEIPT_LINK and ROSTER_PRECOMMITMENT_ORDER require the roster of actors to have been committed before the interval opened.
COVERAGE_RECOMPUTE and VERDICT_RECOMPUTE derive the answer, and ADMITTED_EFFECT_COUNT makes the receipt admit effects that did land rather than only reporting a clean result. Run the effect case, which is the receipt reporting honestly that the window was not quiet.
What it does not prove, in plain words. It does not say the system was safe, correct or well operated, and it does not prove absence outside the declared channels and interval. It attests that no prohibited effect landed on declared channels during a bounded interval, within a stated gap tolerance.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Your dispute guide says you are responsible for reconciling all disputes using the Chargebacks report, and that dispute mitigation is a joint responsibility. Joint responsibility across two ledgers only works while the two ledgers agree, and the moment of disagreement is exactly when nobody wants to be the one exporting spreadsheets.
LEDGER_DISTINCTNESS and ATTESTOR_KEY_DISTINCTNESS require the two sides to be genuinely separate parties with separate keys, so this cannot degrade into one system checking itself. ATTESTOR_QUORUM and ATTESTOR_SIGNATURE_VALID hold the attestation to a real threshold.
COMMITMENT_EQUALITY_RECOMPUTE is the core. It derives whether the two commitments match instead of comparing two reports. Run the fail case: it returns valid false, because the body asserts parity the recomputation does not support.
NO_RAW_STATE_LEAK means neither side sees the other’s balances or transaction detail. AGREED_FIELDS_DECLARATION states up front which fields were in scope, and DIVERGENCE_CONSISTENCY with MAGNITUDE_CLASS_ENUM classify how far apart the ledgers are when they do disagree, which is usually the first question anyone asks.
What it does not prove, in plain words. It does not say either ledger is correct, complete or well kept, and it does not reveal balances or transactions. It attests to whether two independently attested commitments over declared fields agree at a bound cursor.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every receipt above is deployed, open to verify, and honest about what it does not prove. If the argument holds, the next step is one integration against a route you can already call from a terminal.
Verify a receiptRead the canon
Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.