Keelson

The liability layer for AI agents that pay: every purchase is checked against your signed mandate by two independent TEEs and comes with a public, verifiable receipt.

Comment

Inspiration

AI agents can now open a browser, pick a product and pay with PayPal. The question nobody has answered is who pays when the agent gets it wrong.

We went through the rules. Visa's Core Rules make the cardholder responsible for an agent's purchase "as if the Cardholder initiated the Transaction". PayPal's Seller Protection for agent purchases covers unauthorized payments and items that never arrived, and nothing else, so "the agent bought the wrong thing" is out. Amex has announced Agent Purchase Protection, but it is still "coming soon" and only for US Amex cards. The store sold exactly what it was asked for, and the company that built the agent guarantees nothing because no rule makes it. The user is left with the loss.

Agents also get it wrong more often than people assume. In Visa's Agentic Commerce Benchmark (November 2026), 22 models from 12 labs failed 42.8% of shopping runs, and 54% of the failed runs still ended in a purchase that didn't meet the customer's requirements. Even when a model passed a scenario, it passed all three attempts only 34.2% of the time.

So people don't let agents buy on their own. Visa's Trust Index found that 72% of US consumers have used an AI assistant, but only 23% trust one to handle a payment. Only 9% of consumers would allow fully autonomous purchases (Accenture), and most of those who would try it refuse to let an agent spend more than $100 without asking (YouGov for Visa; Ping Identity). In PayPal's own survey of 498 merchants, almost two thirds asked for a standard liability framework for agent purchases. Disputes and chargebacks already move $37–42B a year (Chargebacks911; Datos Insights for Mastercard). As an Amex executive put it: "If the merchant has made no error and the cardmember has made no error, but the agent has made the error, that's a new paradigm… one that has not been figured out."

Keelson is our answer to that question: who answers for each part of an agent's purchase, decided before the payment and provable after it.

What it does

1. You sign a mandate. You write what you want in plain language, and Keelson turns it into a structured mandate (compatible with AP2) that shows who is responsible for each field:

Field Who answers if it fails
Price limit, allowed stores, dates, quantity, currency Keelson, because a machine can check them
Size, color, "free returns" The agent's operator, which asserts them and signs
"Something that looks good" You, because it is subjective (Keelson warns you)

You sign with your passkey. No password, no new app.

2. Keelson checks the purchase before money moves. When the agent has a cart, a deterministic policy engine compares it with your mandate. There is no LLM in this step. The engine runs inside two TEEs from different vendors (Intel TDX on Phala and AWS Nitro), and both have to countersign. If the cart breaks the mandate, the purchase is blocked and you see exactly which field failed. If it complies, the countersignature is Keelson taking responsibility for the machine-checkable fields.

The agent's pay click on PayPal is held until the amount is confirmed by PayPal's own APIs or by your passkey. The payee must be one your mandate names, and a currency conversion must stay within the spread you allowed.

3. The proof travels with the payment. Keelson writes the evidence (mandate, cart, what the agent saw and the engine's decision) to a public transparency log. Independent witnesses cosign it and its root is anchored on chain, so not even we can rewrite it. You get an Alibi, a portable receipt in the IETF SCITT format that anyone can verify offline at verify.keelson.finance.

4. If something goes wrong, whoever failed pays.

Who failed Who pays
A field Keelson checked Keelson, from its reserve
A field the operator asserted falsely The operator's bond, a PYUSD deposit in a smart contract that gets slashed
The store shipped something else The store, through PayPal's normal dispute
It was subjective, or the claim is in bad faith Nobody: the Alibi is the defense

PayPal still adjudicates disputes. Keelson decides whom to charge, whom to reimburse and what evidence to send, and the evidence is built so a third party can check it. Disputes can carry zero-knowledge proofs written in Noir, and an SP1 proof that the engine evaluated the purchase correctly can veto an unfair slash.

We tested all of this with real money: an agent bought sheet music from a live store with a Colombian PayPal account. The USD 2.95 order was charged as COP 10,236, 510 bps from the reference rate and within the mandate's limit, and the purchase got its Alibi.

How we built it

The PayPal integration uses Orders v2 (authorize, then capture), Vault so a saved PayPal account can hold funds without a login window, and webhooks. The sandbox runs in every automated test.

The policy engine is Rust and runs the same code in both legs. Leg A runs on Phala Cloud under an app on Phala's on-chain KMS on Base, and leg B runs in an AWS Nitro Enclave. CI rebuilds both images from source and reproduces their measurements, so anyone can confirm what code is approving purchases.

The Noir circuits cover mandate compliance, mandate violations and anonymous mandates. SP1 proves the engine itself. The verifiers, the bond vault, the reserve and the courts are deployed on Arbitrum Sepolia.

The log is tile-based, with three independent witnesses and checkpoint anchors on chain, and anyone can run the monitor that checks those anchors and the TEE signers.

Users get a Next.js app with passkey signing (it also works embedded inside a store's checkout). Merchants get a console, operators get theirs, and judges get Judge Mode. Developers get an MCP server, docs, and SDKs on npm (@keelson-finance/sdk) and PyPI (keelson-finance).

To test the pay click we run 210 checkout attacks in CI and nightly against the PayPal sandbox, including hidden fees, fake totals, look-alike payees, bidi and locale tricks, and prompt injection. Today none of them get through, and the scoreboard is public and can be recomputed.

Business model

It works like flight insurance with a black box attached: many purchases pay a little, which covers the few that go wrong, and the evidence shows who caused each loss. Stores pay a fee on protected volume (0.30–0.60%, the range of Riskified and PayPal Chargeback Protection), operators pay per countersignature, and dispute defense comes included. Most claims never touch Keelson's reserve, because the operator or the store pays when they were at fault and bad carts are blocked before payment.

We start with a capped warranty on Keelson's own countersignature, paid from a reserve. Next come operator bonds held with licensed partners (surety, bank or escrow), and eventually full third-party coverage as an MGA or Lloyd's coverholder, the way Armilla works with Chaucer.

Challenges we ran into

The hardest problem was knowing what PayPal will actually charge. The review page's text can't be trusted: bare "$" signs in several currencies, masked card digits, hidden frames, Pay Later offers that look like totals. We stopped reading page text and moved the gate to PayPal's structured data and the user's passkey.

Rotating both TEEs without stopping countersigning was the other big one, because the log's signing keys and the credential issuer had to move in the same rotation.

We also wanted a stranger to be able to verify everything we produce, from image digests and measurements to proofs and log checkpoints, and that took more plumbing than any single feature.

Accomplishments that we're proud of

A real-money agent purchase across two currencies with a receipt anyone can verify. Countersigning by two TEE vendors in production. A liability split that names who pays for each field before the purchase happens. A red-team suite with a public, recomputable scoreboard.

What we learned

Nobody has measured yet how much of today's dispute losses come from agents. Visa's benchmark shows how often they would cause them, and right now the problem blocks more volume than it destroys. That blocked volume is lost money too. What unlocks it is evidence a third party can check: who approved the purchase, under which rules, and who is on the hook if a field was wrong.

What's next for Keelson

Merchant-signed carts, so checkout doesn't need a passkey prompt. A third TEE vendor. A PayPal partner integration to read orders directly on any merchant. Operator bonds with licensed partners, then mainnet with real reserves and agent ratings that stores and insurers can query.

Built With

Share this project:

Updates

Submission history