Why Spend7 does not offer a liability backstop for AI agents
TL;DR: key takeaways
- A backstop that pays out is insurance. Insurance needs underwriting, capital and a regulator, not a pricing page.
- We ship the evidence packet instead: the decision as it was made, its signals, and the ruleset hash in force at the time.
- The packet argues against the claim too. One that only argues your side is worth nothing to whoever receives it.
- If a vendor offers a backstop, ask who carries the capital, what voids it, and what the per-incident cap is.
Every few weeks a prospect asks the same question: if the agent overspends, does Spend7 pay? It is a fair thing to ask: an agent spent money it should not have, somebody is out of pocket, and a liability backstop for AI agents is exactly the reassurance a finance director wants before signing. The answer is no, and it will stay no until a person with the authority to make an insurance commitment makes one. This piece explains why we drew that line, what we built instead, and how to interrogate any vendor who tells you they have drawn it differently.
What a backstop actually is
Strip away the language and a backstop is a promise: if this payment goes wrong, we pay some of it.
That is insurance. Not insurance-adjacent, not a guarantee, not "assurance", but a contract to indemnify against a financial loss. Calling it something else on a pricing page does not change what happens when someone claims.
Real insurance needs three things a software company does not get by shipping code:
Underwriting. Somebody has to model expected loss. For a liability backstop for AI agents in 2026 there is barely any loss history to model from. The rails are months old (x402 in May 2025, AP2 in September 2025) and the failure modes are still being discovered. Underwriting a risk nobody has measured is not conservative pricing; it is a guess with a contract attached.
Capital. Reserves against claims. Not revenue, not runway, money set aside that cannot be spent on engineering.
Usually a licence. Indemnifying against financial loss is a regulated activity in most jurisdictions, with the details varying enough that "it depends where your customer is" is the only honest summary.
None of those are engineering decisions. They are decisions a person with legal and financial authority signs their name to.
"We could have written a covered amount on the pricing page in an afternoon. What we could not do in an afternoon is underwrite it, reserve against it, or be confident it was lawful in every market we would sell into. So it is not there."
the Spend7 engineering team
Why the temptation was real
Here is the uncomfortable part, told straight.
A liability backstop for AI agents was in the original product concept. It was going to be the paid tier's headline: Spend7 scores your payment as low risk, the payment turns out to be fraudulent, Spend7 absorbs a portion.
Commercially it is a strong offer. It aligns incentives: a vendor with money at stake tunes its thresholds honestly. It is easy to explain. It closes deals.
It also could not be shipped, and the reason is not squeamishness. Advertise a guarantee, take money for it, then discover at the first real claim that you cannot lawfully pay or have not reserved for it, and you have not sold a product. You have sold a fiction to people who made decisions based on it.
So the backstop is not offered, not priced, and explicitly disclaimed on the pricing page, in the terms, and in the machine-readable llms.txt so that an agent evaluating Spend7 reads the same limitation a person does.
What ships instead
Chargeback-assist. It is narrower and it is real.
Every risk check is recorded before the payment settles: the intent, the decision, the score, every signal with the numbers it fired on, and the hash of the ruleset in force. Raise a claim against a stored payment and Spend7 assembles a packet from that record.
The critical property is the timing. The record was written before anyone knew how the payment turned out, which is what makes it evidence rather than reconstruction. Nothing is re-scored; running today's engine over a six-week-old payment would produce a document describing a decision that was never made.
| Chargeback-assist does | Chargeback-assist does not |
|---|---|
| Record every decision before settlement | Reimburse any part of a loss |
| Assemble an evidence packet as JSON or PDF | Guarantee a dispute outcome |
| Include the ruleset version and hash in force | Re-score the payment with today's rules |
| Show surrounding activity and the merchant's platform-wide picture | Represent you to a bank or processor |
| Feed confirmed fraud back into the cross-account graph | Provide insurance of any kind |
Table: the boundary of what Spend7 ships around disputes. The right-hand column is not a roadmap.
And one more property that customers occasionally dislike: the packet states the case against the claim. If Spend7 flagged the payment and your system settled it anyway, the packet says so.
That is deliberate. A document that only argues one side is worth nothing to the person receiving it, and everyone in disputes knows what a one-sided packet is. A packet that concedes the inconvenient fact is a packet that gets read.
A worked example
A procurement agent settles £6,200 to a supplier that turns out to be fraudulent. The company wants the money back.
Without a record. They know £6,200 left on the 14th. They cannot show what the agent knew, whether anything looked unusual, or what controls applied. The dispute becomes an argument about plausibility, and plausibility favours whoever tells the better story.
With the packet. The payment scored 61 (flag, not deny). Contributing: first-seen counterparty (12), amount 4.2× the agent's median (fires), off-hours (8). The ruleset hash is recorded. Also recorded: the system returned a flag, and the caller settled anyway.
That last line costs them something. It is also the reason the rest is credible. A packet showing a clean allow when the system had actually warned would be discovered, and then nothing in it would be believed.
The realistic outcome is a better-argued dispute and an internal fix; flags now stop the payment. Not a refund from us, because we do not do that.
How to evaluate a liability backstop for AI agents that is offered
Some vendors will offer one, and some of those offers will be perfectly genuine. Four questions separate them.
1. Who carries the capital? "We do" from a Series A startup is a promise backed by runway. "Underwritten by [named insurer]" is a different instrument. Ask for the name.
2. What are the caps? Per incident and annual aggregate. A backstop with a £500 per-incident cap is a gesture; nothing wrong with that, but price it as one.
3. What voids it? Get the exclusions in writing. Ask specifically whether "the system flagged the payment and you proceeded" voids cover; it almost always does, and it is the single most common real-world scenario.
4. What is the claims process? Who decides, on what evidence, in what median time? A backstop that resolves in nine months is a footnote, not a control.
If those answers are crisp, it is a real product and possibly a good one. If they are vague, you are being sold comfort.
Common pitfalls
Buying a backstop instead of a control. Cover pays after the loss. A cap prevents it. A liability backstop for AI agents, even a genuine one, is the more expensive way to arrive at a smaller number. If the budget only stretches to one, the cap is worth more.
Assuming cover survives a flag you ignored. It does not. Read the exclusions.
Not recording decisions because you have cover. Every claims process wants evidence. Cover without a record is a slow argument you will probably lose.
Waiting for the category to mature. It will, and the losses are happening now. Spend caps and a decision log are available today and cost less than one incident.
The straight version
Spend7 prevents and records. It does not indemnify. If that changes it will be because a person made an insurance decision and said so plainly, not because a marketing page got braver.
If you want the mechanics: chargeback-assist covers the packet, AI agent governance covers the authority questions an auditor asks, and agent payment fraud detection covers what to stop before any of this becomes relevant.
Frequently asked questions
- Does Spend7 cover losses from a fraudulent agent payment?
- No. There is no liability backstop for AI agents on any Spend7 plan, no covered amount, and no insurance. What ships is chargeback-assist: raise a claim against a payment Spend7 scored, and get an evidence packet assembled from what was recorded before that payment settled. That is the entire claim, and it is stated the same way on the pricing page and in the terms.
- Why not just offer one? Competitors do.
- Because paying out on a loss is insurance regardless of what it is called on the pricing page, and insurance requires underwriting, reserved capital and usually a licence. Those are decisions a person with legal and financial authority makes, not a feature an engineering team ships. Advertising a guarantee we had not underwritten would be the most expensive kind of dishonest.
- What is actually in the evidence packet?
- The claim, the payment, the decision exactly as it was made with every contributing signal and the numbers each fired on, the ruleset version and hash in force at the time, that agent's activity in the 24 hours either side, your other payments to that merchant, and the merchant's 30-day picture across the platform. Available as JSON or PDF.
- How should I evaluate a vendor that does offer a backstop?
- Four questions. Who holds the capital: the vendor, or an insurer with a name? What is the per-incident and annual cap? What voids the cover, specifically, and is 'the system flagged it and you proceeded' on that list? And what is the claims process and its median resolution time? Clear answers mean a real product. Vague ones mean marketing.
Score a payment before it settles
Spend7 returns allow, flag or deny in one call, with the signals that produced it. The free tier covers a single agent, its spend caps and its full decision log.
