A person in the loop when an agent pays

What the Human Seal adds

A named person approves the exact action, and the agent gets a signed receipt. The receipt is bound to the exact cart: the agent hashes its cart, the receipt signs a digest that includes that hash, and anyone holding the cart can recompute the chain. Change one character of the cart and the receipt no longer matches.

Anyone can check the signature offline, with no call to us, in the verifier or in a few lines of code. To confirm the key is ours, compare it with the key published at did:web:humanseal.world.

Two working examples, in the sandbox

Both run against the Human Seal sandbox: no money moves, no live tenant is touched, and every receipt is marked as a rehearsal inside what is signed. The code is public: the payments examples.

• One payment. An agent proposes an exact cart, a simulated person approves it, and the agent gets a signed receipt and checks it. The receipt matched the exact cart, and a cart with the total changed did not.
• A spending limit. A person approves one limit that names the agent's key, using the constraint names of the AP2 specification (allowed payees, amount range, total budget, date window). The agent then pays inside it, and a payee or payer checks each payment offline. In the example run, 1 payment was accepted and 6 were refused: over the per-payment limit, over the total budget, a payee not on the list, a date outside the window, a payment signed by the wrong key, and a limit changed after approval.

To run them, follow the quickstart, then use python3 agent_spend_envelope_with_human_seal.py you@example.com. The script does the sandbox steps for you.

How this relates to AP2

AP2 is an open protocol for agent payments, published by Google and donated to the FIDO Alliance in April 2026, where its development continues in working groups. We read version 0.2 of the specification on GitHub. It describes mandates that a user signs on a trusted surface, in two states: open mandates with constraints, for payments the user is not present for, and closed mandates for one transaction. Our approval screen is designed to do the same job as a trusted surface: it shows the request in full and records a person's decision. It is not a registered trusted surface for any verifier.

• Where we are not AP2. AP2 mandates are signed credentials issued through a trusted surface. Our receipts are signed by our published key, not by the user's own key, and they are not AP2 credentials. We are not certified, compatible or listed with AP2, x402 or any card network.
• What a receipt cannot show yet. It shows that a signed-in person approved the exact payment. It does not yet show that a present human consented: a passkey step-up is planned and not built. The AP2 specification itself names a passkey or hardware-attested user key as a future delegation model.
• Sandbox receipts prove nothing about a human. A sandbox receipt is genuine in its signature but is never proof that a person approved anything.

What is not built

Nothing here holds money or moves it. What is built and what is not is on the limitations page; if anything here reads stronger, that page is right. Questions the pages do not answer can go to the flocore_support_ask tool, which says so when it cannot answer.