Every agent action deserves a receipt

Your AI agent booked the refund. Or did it? Checked the vendor portal — did it see the right page? Moved $500 — was that even allowed?

Right now, for most of the industry, the honest answer is: nobody knows. Agents run scripts that vanish into stdout. "Success" is whatever the log line says. There is no audit trail, no proof, no accountability — just a model's confidence and a prayer.

This post is about the fix we built, and the thesis behind it: every agent action should come with a receipt.

The accountability gap

When software was something humans clicked, we built an entire trust infrastructure around actions: order confirmations, signed contracts, database WAL, git history. Then agents arrived and started taking actions at machine speed — and skipped all of it.

Three failure modes keep showing up:

• No proof of execution. An agent claims it "completed the workflow." You cannot check. The script is gone; the log line is all you have.
• No guardrails. The same code path that reads a page can spend money. Nothing distinguishes a $0 lookup from a $500 purchase until it's on your invoice.
• No tamper-evidence. If your own logs are the only record, they can be wrong, or rewritten. Trust-me-isn't.

The fix: signed receipts for every run

Our answer is boring in the best way: every workflow execution and every sandbox run in Forge Box issues an ed25519-signed receipt at completion time. Not a log line. A compact, canonical JSON payload with an asymmetric signature:

{
  "id": "rcpt_797a7ff6d425",
  "action": "workflow_execution",
  "actor": "agent:usr_demo_001",
  "workflow": "check_example_page",
  "risk_score": 10,
  "cost_usd": 0.001,
  "timestamp": "2026-09-17T20:49:50.138Z",
  "algorithm": "ed25519",
  "key_id": "key_2b47722ac3eed01a",
  "signature": "RKSobO4a1Y/sBv27ivpb5GNMygVMZVJlnKaUt9u+DoBo8U3dGCYSKrUHMBSWb7C8+A9P/..."
}

Three properties matter here:

• Offline-verifiable. The public key is published at a stable endpoint (/api/v1/keys/current). Anyone — you, your auditor, your lawyer — can verify a receipt years later without ever talking to our servers.
• Byte-exact. The payload is canonicalized (sorted keys, no whitespace) before signing. One extra field at verification time and the signature fails. There's no "roughly the same receipt."
• Unforgeable. The signing key never leaves our production key store. A forged receipt would require breaking ed25519, not guessing a UUID.

Receipts alone aren't enough — you need policy

A proof of what happened is retroactive. Guardrails have to be prospective. So before anything executes, Forge Box's policy engine evaluates the action:

• Spend limits — daily USD caps per user and workflow. Exceeded? The execution is denied before it runs, and the denial itself is recorded.
• Allowed domains — a browser workflow can be restricted to specific hosts.
• Risk scoring — every sandbox run gets a 0-100 score. Reading a file is cheap; spawning a shell is an 80. Operators tune the weights; the scoring is transparent, not vibes.

Then — and only then — does the action run, and the receipt captures the policy decisions alongside the outcome. You get the full story: what was attempted, what was allowed, what actually happened, what it cost.

What this looks like in practice

A concrete, real example from our production system — a workflow that opens a page and extracts its content:

logs: [
  "Browser launched (real chromium)",
  "Step 1: navigate",
  "  Navigated to https://example.com/ (status 200)",
  "Step 2: extract",
  "  Extracted page title + 2k text preview"
]
output.status: success
title: "Example Domain"
receipt: rcpt_797a7ff6d425 → verified: true

That's a real browser — not a simulation — running on our infrastructure, with a cryptographic proof that it ran and what it returned. You can verify that receipt yourself, today, from our public key.

Honest engineering: we found our own stubs

Here's the part most vendors wouldn't publish. In September 2026 we ran a no-mercy audit against our own production API and found that while the auth, receipts, and webhooks were real, several flagship features were not: the workflow executor logged "would navigate" instead of navigating, the sandbox 500'd on every run due to an integer column bug, scheduled workflows never actually fired, and generated API keys couldn't authenticate.

The scariest part? The receipts were real the whole time. We could have shipped marketing that said "signed receipts!" and it would have been technically true — proving things about executions that didn't really happen.

We fixed all of it in a day, then verified by simulating a brand-new stranger through the entire funnel — register, create, execute, verify — 13 checks, all passing. The lesson we keep coming back to: test your product the way a stranger would, because your own dashboard will lie to you politely.

The thesis

Verifiable receipts are to agent actions what TLS was to web traffic: the moment it becomes the default, everything before it looks reckless.

We think the next phase of the agent economy doesn't work without this layer. Delegations get bigger, autonomy gets longer, and the question "can I trust what my agent did?" shifts from a vibe to a curl command. The companies that make their agent actions verifiable now will be the ones allowed to operate when the trust requirements arrive — and they're arriving.

That's what Forge Box is for. Turn your browser workflows and code into secure, versioned APIs that agents call — with policy guardrails before the action and signed receipts after it.