Xavi Sheikrojan, your director of risk intelligence, described the problem better than anyone else has: “When agents handle the shopping, the human session disappears. There’s no mouse movement, hesitation or familiar checkout path. Because of that, fraud no longer stands out through noisy or chaotic behavior. It blends into transactions that look perfect instead.”
Signifyd then asks the right question on the same page: does this action align with the customer’s identity and intent, even when the customer never touched the keyboard? That question cannot be answered by observing the transaction. The observable part is exactly the part that went away.
It can be answered by a different kind of artifact. Not a signal inferred at checkout, but a commitment made before the agent acted, checkable afterwards by someone who was not there. What the human was actually shown. What the agent was actually permitted to do. Whether the thing that got sent is the thing that got approved.
This matters more to you than to almost anyone else in the flow, because Guaranteed Chargeback Protection shifts the liability for chargeback losses away from merchants and onto Signifyd. You hold the loss. Eight receipt types below, twenty one live runs against the open verify route. One comes back false on purpose, because a verifier that never refuses anything is not a verifier.
This is not a fraud model, it does not score orders, and it is not a claim that Hive can decide a transaction better than a platform with the largest enterprise merchant network on the market. Nothing here competes with your decisioning, and nothing here would improve it.
These receipts sit on the other side of the decision. Your model decides. A receipt records what the decision rested on, in a form that recomputes for a merchant, an issuer, an agent developer or a court, none of whom have access to your model and none of whom should.
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 itself, because an instrument that overclaims is worthless the first time somebody tests it.
The commercial case is about the cost of a contested file. You already win the fraud decision. What is still expensive is the argument afterwards, and that argument is expensive because every party brings its own records and none of them can be checked by anyone else.
Every one of these was a behavioral signal until agents started shopping. Each now has to be a commitment made before the action, or it is not evidence at all.
Sheikrojan named it precisely. The human session disappears, so there is no mouse movement, no hesitation, no familiar checkout path, and fraud stops standing out through noisy behavior. It blends into transactions that look perfect instead.
intent.affirmation replaces the lost signal with a committed one. What was presented to the person, what was transmitted to you, and whether those two artifacts are the same thing.
The perfect-looking transaction becomes checkable again.
You define agentic commerce fraud partly as misuse of the permissions customers give agents. Proving misuse means the permission has to be a fact fixed before the order, not a setting somebody can adjust afterwards.
mandate.conformance binds the permission under a commitment made before the transaction, and delegation.attenuation proves authority narrowed rather than widened at every hand-off.
Misuse becomes provable instead of arguable.
You deliver an instant decision and then carry the loss on approved orders. That makes your decision the artifact most likely to be re-examined, by a merchant, an issuer or an agent developer who does not like the outcome.
authorization.decision recomputes the verdict from committed inputs and requires the stated reason to match the constraint that fired, without exposing the model or the shopper.
The decision holds up without opening the model.
Liability shifted away from the merchant means liability shifted onto you. Every dollar you recover afterwards depends on facts assembled after the fact from records belonging to whichever party you are trying to recover from.
fault.attribution derives whose breach produced the outcome, and recovery.determination derives the allocation from a table committed before the determination and linked to that finding.
A recovery position that survives the other side reading it.
This is the signal you lost. The human session disappears, so the question your own page asks becomes unanswerable from behavior: does this action align with the customer’s identity and intent, even when the customer never touched the keyboard? Behavior cannot answer it any more. A committed artifact can.
Two artifacts are committed. The one presented to the human and the one transmitted to you. PRESENTED_ARTIFACT_INTEGRITY and TRANSMITTED_ARTIFACT_INTEGRITY hold each of them to a commitment, and ARTIFACT_EQUALITY_RECOMPUTE derives whether they are the same thing rather than accepting an assurance that they are.
That single comparison catches the attack that costs the most and looks the cleanest. The customer approves a modest order on screen, and something else goes out over the wire. The transaction that arrives at you looks perfect because the difference happened before the transaction existed.
AFFIRMATION_ORDERING_RECOMPUTE puts the affirmation before the action, and DRIFT_BOUND_SATISFIED caps how far the clocks can be apart before the ordering claim stops meaning anything. CHANNEL_CLASS_DECLARED records whether the person was looking at a screen, speaking, or replying in a thread, because those are not equally strong and pretending they are is how this gets abused.
What it does not prove, in plain words. It does not say the person understood, agreed, had capacity, or was who they claimed to be, and it does not reproduce what they affirmed. It attests that a committed artifact was presented on a declared channel before the action, and whether it matched what was transmitted.
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.
Before you can hold an agent to an instruction you have to know whether the instruction was the kind of thing anyone could check. Find me reliable running shoes and spend up to two hundred dollars on running shoes are not the same sentence, and only one of them can be enforced or disputed later.
PREDICATE_CLASSIFICATION_RECOMPUTE and VERIFIABILITY_CLASS_RECOMPUTE derive the class from the predicates in the instruction rather than reading a label. RULESET_PRECEDENCE requires the classification ruleset to have been committed before the assessment, so nobody reclassifies an instruction as subjective once it turns out to have been breached.
The classes are honest. Checkable, partial, subjective, and unclassified. An instruction that lands on subjective is a real answer, and it is a much better basis for declining to enforce than an argument after the loss about what the shopper must have meant.
NO_INTENT_CONTENT_LEAK keeps the instruction text out of the receipt. You can prove the instruction was unenforceable without publishing what the customer asked for.
What it does not prove, in plain words. It does not say the intent was genuine, authorised, lawful or well formed, and it does not interpret what the person wanted. It attests to how a stated intent classifies under a ruleset committed before the assessment.
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.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
You define agentic commerce fraud as the misuse of AI shopping agents and the misuse of the permissions customers give them. Misuse of a permission is only provable if the permission itself is fixed in time. Right now it is a setting in somebody else’s system, and settings change.
MANDATE_PRECEDES_TRANSACTION and VALIDITY_WINDOW put the permission ahead of the order in time. AMOUNT_WITHIN, CURRENCY_MATCH and SCOPE_MATCH check the order against it, and CONFORMANCE_RECOMPUTE derives the verdict rather than reading one out of the body.
Run the fail case. It returns valid false, with CONFORMANCE_RECOMPUTE failing because the body claims a pass the arithmetic does not support. A verifier that refuses to bless a mismatched claim is what makes every passing receipt worth something.
NO_PAN keeps instrument numbers out entirely, so this artifact can move between merchant, platform and issuer without dragging payment data along with it.
What it does not prove, in plain words. It does not say the permission was appropriate, that the customer understood it, or that the purchase was wanted. It attests that a specific order fell inside a permission committed before the order 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.
You deliver instant decisions on orders, and on approved orders you carry the loss. That makes your decision the most consequential artifact in the flow and the one most likely to be re-examined. A decision that has to be explained from an internal score is weaker than one that can be recomputed.
DECISION_BASIS_RECOMPUTE and DECISION_RELATION_RECOMPUTE derive the outcome from the committed inputs and require the stated reason to match the constraint that actually fired. CONSTRAINT_EVALUATION_RECOMPUTE re-runs the evaluation instead of trusting the result.
AMOUNT_COMMITMENT_RECOMPUTE and MANDATE_SCOPE_DIGEST_RECOMPUTE bind the decision to the exact amount and scope in force at the moment, and DECISION_INSTANT_ORDERED fixes when it was made. The revoked case is the interesting one, because an authority that was live at decision time and dead afterwards is a fact people argue about constantly.
NO_CARDHOLDER_IDENTITY_LEAK means the reasoning is provable without the receipt carrying the shopper. Your model stays yours. The decision becomes checkable.
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 model or the policy. 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.
Signifyd has written that not knowing where the specific vulnerability lies makes it difficult to assign responsibility and accountability. In agentic commerce that list is long. The shopper, the agent developer, the platform, the merchant and the issuer all have a version, and every version is supported by its author’s own logs.
ATTRIBUTION_CLASS_RECOMPUTE and ATTRIBUTED_ROLE_RECOMPUTE derive the shape and the party from committed artifacts instead of reading a conclusion. PRECOMMITMENT_PRECEDENCE and VIOLATION_SUBSET_INTEGRITY block the standard move of retrofitting a loss into somebody’s breach because a loss occurred.
The three shapes are single, shared and hindsight. Hindsight is the one worth running. A signed finding that nobody breached anything, on an order that still went bad, is the finding that ends an argument with an agent developer instead of starting one.
NO_PARTY_IDENTITY_LEAK lets the finding travel to a platform or an issuer without naming the parties, which matters when the counterparty is somebody you also do business with.
What it does not prove, in plain words. It does not assign legal liability, damages or negligence, and it is not a legal determination of any kind. It attests to which committed constraints were broken by which named party under the stated procedure.
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.
Guaranteed Chargeback Protection shifts the liability for chargeback losses away from merchants. That sentence is the whole reason this page is worth your time. You are the party holding the loss, so you are the party with the strongest interest in a recovery position somebody else cannot simply dispute.
ALLOCATION_TABLE_INTEGRITY and ALLOCATION_PRECEDENCE require the allocation table to have been committed before the determination, so the split cannot be authored after the number is known. ALLOCATION_ENTRY_RECOMPUTE derives each share and SETTLEMENT_POSITION_RECOMPUTE derives the net position.
ATTRIBUTION_LINK and ATTRIBUTION_INTEGRITY tie the recovery to a specific fault finding, so a recovery claim cannot rest on an attribution that was quietly amended in between. That linkage is the difference between a recovery position and a demand letter.
Run the none case too. A signed determination that there is no recovery position is a clean, cheap way to close a file, and closing files cheaply is most of the economics of a guarantee.
What it does not prove, in plain words. It does not determine legal liability, does not create or interpret a right of recovery, and does not bind any party to pay. It attests that a stated allocation follows from a committed table and a linked attribution finding.
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.
You describe the low and slow pattern, where nothing looks wrong at any single merchant. With the largest enterprise merchant network on the market you are one of very few parties who can see the whole shape. The problem is proving what you saw to somebody who cannot see your network.
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 the spread across merchants rather than accepting a stated count.
CUMULATIVE_COMMITMENT_RECOMPUTE and CUMULATIVE_RELATION_RECOMPUTE derive the running total and its relation to the cap. WINDOW_LINK and WINDOW_CONTINUITY chain each window to the one before it, so an agent cannot reset its own history by starting a fresh window.
NO_ACCEPTOR_IDENTITY_LEAK is the commercially important gate. You can prove an agent breached an aggregate limit across your network without disclosing which merchants it hit. Your network stays your network.
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.
The permission a customer gives an agent rarely stays a single hop. An assistant hands work to a shopping agent, which hands checkout to something else. Authority is supposed to shrink at every hand-off. Nothing in the flow currently proves it did.
Four gates carry the argument. ATTENUATION_CEILING_NONINCREASING stops a spend ceiling rising down the chain. ATTENUATION_CATEGORY_SUBSET stops new categories appearing. ATTENUATION_EXPIRY_NONEXTENDING stops a child credential outliving its parent. ATTENUATION_DEPTH_STRICT_DECREASING stops the chain looping back on itself.
CHAIN_CONTINUITY and ROOT_AUTHORITY_BINDING tie every link back to the original grant, and ACTION_CEILING_WITHIN_FINAL_LINK checks the actual purchase against the last link rather than the first. That distinction is where widening usually hides.
The chain is checkable end to end by someone who was not party to any hop in it, which is the property that matters when the agent developer is not your customer.
What it does not prove, in plain words. It does not say the original permission was valid, informed or lawfully obtained, and it does not say the agents behaved well. It attests that authority did not widen at any hop and that the action fell inside the final link.
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.