Risk scoring for autonomous payments
A spend leash for autonomous agents
Post the payment your agent is about to make: amount, merchant, agent id, and whether it settles on x402 or AP2. One call back comes a score, an allow, flag or deny, and every signal that produced it, while there is still something to decide.
50 checks a day on the free tier, no card and no waitlist. Same thresholds and same ruleset as every paid plan.
- Outside this agent's usual hours+6
Nothing else crossed a threshold. Most calls look like this one, and they cost the same to check as the ones that do not.
Settle it. The decision is recorded either way.
Not a demo
Score a payment right here
The form below posts to the production endpoint. Break one of the scenarios on purpose and watch which signals fire.
The agent is signing an authorization for more than the resource actually quoted. A protocol invariant, so it denies regardless of the score.
This posts to the same /api/v1/risk-check endpoint your agent would call, in stateless mode: the scenario’s caps and history travel in the request. Nothing is stored, and no account is needed.
Pick a scenario and score it. The decision, the score and every signal that fired land here, in the same shape the API returns them.
Caps live outside the agent
A budget in a system prompt is a suggestion. Spend7 holds the caps, per agent, per merchant, per category, per rolling window, so nothing the agent reads or writes can move them.
Spend limits→Rail defects a card model cannot see
An x402 authorization above the quoted maximum. An AP2 cart mandate that overruns the intent mandate it descends from. A replayed nonce, an expired quote, a merchant outside a mandate's scope.
Rail coverage→Every decision is evidence
The decision, its signals and the ruleset hash are recorded before the payment settles. When one goes wrong, the packet is assembled from what was stored, not reconstructed afterwards.
Chargeback-assist→Three outcomes, and no fourth
Execute the payment. Nothing crossed a threshold, and the decision is recorded.
Score at or above 50. Step up: a human, an explicit confirmation, or a re-check with the missing context. Not a soft allow.
Score at or above 80, or a decisive signal: a hard cap breach, a blocked merchant, a broken protocol invariant, which denies regardless of the total.
There is no mode where a missing ledger is quietly scored as an empty one. A score computed against history that was supposed to be there and was not looks exactly like a clean bill of health, so Spend7 returns an error instead, and says which ledger it used on every decision it does make.
What lands in the dashboard
Every stored decision, every cap and how much of it is used, right down to the signals that made a call. The same read-only log an evidence packet is built from.
See it on your own account →The rails it reads
Neither protocol decides whether a payment is a good idea. Both leave evidence that says whether one broke its own rules.
Where it goes in your stack
One call in front of the payment tool. The agent never learns where the limit is, because it never holds it.
Use cases
A budget written into a system prompt is a suggestion. The agent that overspends is usually not the one that was told to; it is the one that looped, or that was handed a task whose cost nobody estimated, or whose credential ended up somewhere else.
Card fraud models are trained on how people buy. An agent does not buy like a person: it transacts at machine speed, at odd hours, in tiny amounts, with counterparties it found seconds ago. The behaviour that looks anomalous for a human is Tuesday for an agent, and the behaviour that should alarm you (a retry loop, a quote overrun, a mandate that outgrew its scope) has no equivalent on a card rail at all.
Disputing an agent-initiated payment means answering questions nobody logged the answers to. What did the agent know? What was it authorised to spend? Was anything unusual about the payment at the time, or does it only look unusual now that you know how it ended?
Questions
- What is agentic commerce?
- Commerce where the buyer is software acting for a person or a business: an agent that researches, chooses and pays without a human at the checkout. It needs new payment rails because the existing ones assume a person is present, and new controls because the assumptions that made card fraud detection work do not hold when the buyer is a program.
- What are x402 and AP2?
- The two rails agentic payments are converging on. x402 negotiates payment over HTTP 402: the server quotes what it wants, the client pays and retries with a signed payload. AP2 carries the user's authority as signed mandates so a merchant can tell what a human actually approved. They solve different halves of the problem and Spend7 checks both.
- Why can't existing fraud tools handle agent payments?
- They model how people buy. Agents transact at machine speed, at any hour, in amounts and patterns that look anomalous for a human and are routine for a program, while the failures that should alarm you, like a retry loop or a mandate that outgrew its scope, have no equivalent on a card rail for those tools to have learned.
- What does Spend7 actually do?
- It scores a payment intent before the money moves and returns allow, flag or deny with the reasons. It holds the spend caps so they live outside anything the agent controls, it checks the rail-specific invariants on x402 and AP2, and it records every decision so a disputed payment has an evidence trail.
More at what agentic commerce breaks, or write to contact us.
Put the check in front of the payment
A key takes a minute, the first call takes a line, and the 50 free checks a day are scored by the same ruleset as every paid plan.
No card, no waitlist, no sales call. Spend7 never holds a payment credential and never moves money.