Can these receipts satisfy a SOC 2 or EU AI Act audit?

Not on their own, and we will not claim otherwise. A signed receipt records the authorization decision and the call's terminal outcome, and shows the record has not been altered since. Only a success receipt evidences execution and charge. A receipt is not a success certificate: refusals and failures are signed too. Whether that evidence satisfies a given control is for your auditor, not for us. We publish no regulatory mappings and hold no certifications. If a mapped compliance report is what you need, buy an audit-layer product.

Can I try it for free?

Yes. Get a free sandbox demo key at /demo-key/ with no account needed. It runs the demo tool with synthetic credits. Production keys are issued to design partners. Paid pilots are scoped and priced after fit.

Is this production-ready?

Production beta, not production complete. The supported beta is vendor-managed and dedicated per customer: separate API, PostgreSQL, Redis, signing material, and administrator resources. It is not a shared multi-tenant SaaS, and optional proof-surface routers are outside the supported production posture. There are no replicas or consensus.

What happens when an agent retries?

For a finalized gateway request, a retry with the same accepted key and payload returns the original receipt instead of dispatching again. A new key is a new request. A local governed tool that crashes after its side effect can leave one debit with no receipt, pending manual review. The gateway cannot prove whether your upstream tool repeated its own side effect. An unknown outcome after dispatch is marked uncertain for manual review.

How agent transaction integrity compares

01 / What is not unique

Signed, offline-verifiable receipts are no longer rare in this field.

Per-call cryptographic evidence for MCP tool calls used to be unusual. It is not now: policy gateways emit signed receipts, and at least one verifies offline without calling its issuer. Audit layers publish hash-chained receipts; whether those carry an issuer signature you can check without the vendor, we have not confirmed.

The receipt is not the argument. The argument is what the receipt is bound to: a ledger debit that cannot happen twice under the same accepted idempotency key.

02 / Where each tool sits

The comparison, including rows we lose.

Assessed August 2026 from each project's public source and documentation. “Not documented” means we did not find the capability described, not that we proved it absent. Retry protection is scoped to this gateway: one accepted idempotency key permits *at most one* dispatch. A call denied or failed before dispatch produces a terminal receipt and no debit.
Capability	Agent Middleware API	Policy gateways	Audit layers	Reliability libraries
Enforces at a boundary the agent cannot bypass	Yes	Yes	Not documented	No, in-process
Per-tool scope and policy	Signed permits	Yes	No	No
Signed receipts, verifiable without the vendor	Yes	Yes	Chained, signature unverified	No
Tamper-evident chained audit	Per-account hash chain	Varies	Yes	No
Budget enforced before execution	Budget ledger	Varies	No	Call and cost caps
Duplicate gateway dispatch prevented on retry	Yes	Varies	No	N/A, in-process only
Debit bound to the idempotency record	Yes	Not documented	Not documented	Not documented
Ambiguous outcome is a distinct receipted state	Yes	Not documented	Not documented	Not documented
Human approval before an action	Permit requests	Varies	Authority trails	No
Compliance framework mapping	No	No	Yes	No
Free way to try it	Sandbox demo key, no account	Often	Varies	Yes

Representative projects: protect-mcp and jamjet (policy gateways), TraceAgent (audit layers), latch (reliability libraries).

03 / Build vs buy

Versus a decorator library you can install today.

The most common alternative is not a competing gateway. It is an afternoon with an open-source Python library: idempotency, circuit breaker, timeout, and budget guardrails on your tool functions. For many teams that is the correct answer.

Choose the library Your problem is reliability
You control every call site and need retries to stop costing money.
Choose a boundary Your problem is evidence
A finance owner, an auditor, or the tool's operator must be able to check what ran and what it cost.
Choose a boundary The agent must not be able to opt out
A call constructed another way is not covered. A gateway is a boundary: once the tool is reachable only through it, there is no way around.

An in-process cache is not evidence, and a library the agent can route around is not a boundary. If neither matters, install the library.

04 / Fit

Who this is for.

A good fit worth a call

You run one internal MCP tool where a duplicate call costs real money.
An agent retried something expensive and you could not prove what ran.
Someone outside engineering needs to check the record.
You can bring one real tool and one engineer.

A poor fit use something else

You want governance across every tool and framework at once. This is one boundary.
Your tool calls are cheap and idempotent already. Nothing here pays for itself.
You need a certified compliance product. See the audit layers above.
You need identity and SSO for agents. Keep your IAM.

05 / Questions we get asked

Compliance, pricing, and honest answers.

Can these receipts satisfy a SOC 2 or EU AI Act audit?: Not on their own, and we will not claim otherwise. A signed receipt records the authorization decision and the call's terminal outcome, and shows the record has not been altered since. Only a success receipt evidences execution and charge. A receipt is not a success certificate: refusals and failures are signed too. Whether that evidence satisfies a given control is for your auditor, not for us. We publish no regulatory mappings and hold no certifications. If a mapped compliance report is what you need, buy an audit-layer product.
Can I try it for free?: Yes. Get a free sandbox demo key at /demo-key/ with no account needed. It runs the demo tool with synthetic credits. Production keys are issued to design partners. Paid pilots are scoped and priced after fit.
Is this production-ready?: Production beta, not production complete. The supported beta is vendor-managed and dedicated per customer: separate API, PostgreSQL, Redis, signing material, and administrator resources. It is not a shared multi-tenant SaaS, and optional proof-surface routers are outside the supported production posture. There are no replicas or consensus.
What happens when an agent retries?: For a finalized gateway request, a retry with the same accepted key and payload returns the original receipt instead of dispatching again. A new key is a new request. A local governed tool that crashes after its side effect can leave one debit with no receipt, pending manual review. The gateway cannot prove whether your upstream tool repeated its own side effect. An unknown outcome after dispatch is marked uncertain for manual review.

Full detail: security limitations. The dated competitive sweep behind this page is docs/market-research-2026-08.md in the public source repository.

06 / Check it yourself

Do not take the table on faith.

The left-column claims are executable; the rest are product facts you take on our word. Clone the public source repository and run make prove-trust-plane without live API credentials. Verify a published receipt offline, without us, on the proof page.

Source repository · Design partner guide

Still think it fits?

The pilot is paid, bounded to one tool, and priced after fit is established. Email the action, retry failure, evidence, cost of one duplicate, budget owner, and decision date. You get a written answer on fit. Estimate economic fit and read the pilot scope before writing.

Start a pilot by email Run the local proof