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 that the call executed and was charged; a denial receipt evidences that the call was refused and never ran, and a refunded-failure or unconfirmed-outcome receipt evidences exactly that. Ledger linkage appears where there is a ledger record to link — a debit, or the compensating entry that reversed it — so a pre-dispatch denial has no debit to point at. It is deliberately not a success certificate: refusals and failures get signed too, which is what makes the evidence worth anything when something goes wrong. Whether that evidence satisfies a given control is a question for your auditor, not for us. We publish no regulatory mappings and hold no certifications. If a mapped compliance report is the deliverable you need, an audit-layer product is a better purchase.

Why is there no pricing page or free tier?

Because we qualify fit before we deploy. This is a design-partner stage product, and most of the value of the first deployments is in being wrong quickly with someone who will tell us. A self-serve signup would get us installations we cannot support and cannot learn from. You can still run the entire loop yourself, locally, with no credentials and no contact with us.

Is this production-ready?

Production beta, not production complete. The supported beta is vendor-managed and dedicated per customer: each customer receives 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. Read the security limitations before deciding.

Does exactly-once hold all the way to my tool?

At our boundary: one accepted idempotency key maps to at most one gateway dispatch and debit plus one terminal receipt. Whether your upstream tool's own side effect happens exactly once depends on whether that tool honors the forwarded key. When the outcome after dispatch is genuinely unknowable, we mark it uncertain and route it to manual review rather than guessing.

How agent transaction integrity compares

01 / What is not unique

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

When this project started, per-call cryptographic evidence for MCP tool calls was unusual. It is not unusual now. Policy gateways and safety frameworks emit signed receipts, and at least one verifies offline without calling its issuer — the same property our proof page demonstrates. Audit layers publish hash-chained receipts; whether those also carry an issuer signature you can check without the vendor, we have not confirmed either way.

So 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 the 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. Capabilities change; verify before deciding. Retry protection is scoped to this gateway: for an authorized request, one accepted idempotency key permits *at most one* dispatch from here — a call denied or failed before dispatch produces a terminal receipt and no debit at all. Whether your upstream tool then runs its own side effect exactly once depends on that tool honouring the forwarded key.
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 — dedupes in-process, and only at call sites that use the wrapper
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 and self-serve	No	Often	Varies	Yes

Representative projects in each column: protect-mcp and jamjet (policy gateways), TraceAgent (audit layers), and 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 guardrail as decorators on your tool functions. It is MIT-licensed, free, and adds no infrastructure. For a lot of teams that is the correct answer, and we would rather say so than sell past it.

Choose the library Your problem is reliability
You control every call site, you trust your own agents, and you need retries to stop costing money. Nobody outside your team has to believe the result.
Choose a boundary Your problem is evidence
Someone who is not you — a finance owner, an auditor, the tool's operator — has to be able to check what ran and what it cost, without trusting the process that ran it.
Choose a boundary The agent must not be able to opt out
A decorator protects the call sites that import it. An agent that constructs a call another way is simply not covered. A gateway is a boundary you can actually close: once the tool is reachable only through it, there is no way around.

The honest summary: an in-process cache is not evidence, and a library the agent can route around is not a boundary. If neither of those distinctions matters for your tool, install the library and keep your afternoon.

04 / Fit

Who this is actually for.

A good fit worth a call

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

A poor fit use something else

You want governance across every tool and framework at once. That is a platform; this is one boundary.
Your tool calls are cheap and idempotent already. Nothing here pays for itself.
You need a certified compliance product with regulatory mappings. See the audit layers above.
You need identity and SSO for agents. Keep your IAM; this sits downstream of it.

05 / Questions we get asked

Compliance, pricing, and other 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 that the call executed and was charged; a denial receipt evidences that the call was refused and never ran, and a refunded-failure or unconfirmed-outcome receipt evidences exactly that. Ledger linkage appears where there is a ledger record to link — a debit, or the compensating entry that reversed it — so a pre-dispatch denial has no debit to point at. It is deliberately not a success certificate: refusals and failures get signed too, which is what makes the evidence worth anything when something goes wrong. Whether that evidence satisfies a given control is a question for your auditor, not for us. We publish no regulatory mappings and hold no certifications. If a mapped compliance report is the deliverable you need, an audit-layer product is a better purchase.
Why is there no pricing page or free tier?: Because we qualify fit before we deploy. This is a design-partner stage product, and most of the value of the first deployments is in being wrong quickly with someone who will tell us. A self-serve signup would get us installations we cannot support and cannot learn from. You can still run the entire loop yourself, locally, with no credentials and no contact with us.
Is this production-ready?: Production beta, not production complete. The supported beta is vendor-managed and dedicated per customer: each customer receives 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. Read the security limitations before deciding.
Does exactly-once hold all the way to my tool?: At our boundary: one accepted idempotency key maps to at most one gateway dispatch and debit plus one terminal receipt. Whether your upstream tool's own side effect happens exactly once depends on whether that tool honors the forwarded key. When the outcome after dispatch is genuinely unknowable, we mark it uncertain and route it to manual review rather than guessing.

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

06 / Check it yourself

Do not take the table on faith.

The core trust-plane claims in the left-hand column are executable — the rest, like the absence of compliance mapping or a self-serve tier, are product facts you can only take us at our word on. The source repository is public; clone it and run make prove-trust-plane to walk permit → invoke → charge → receipt → replay → deny with no credentials and no signup. Then verify a published receipt offline, without us.

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, current evidence, cost of one duplicate, budget owner, and decision date. You get a written answer on fit. A call is available only when a scenario needs one. Estimate economic fit and read the pilot scope before writing.

Start a pilot by email Run the local proof Book a call if your scenario needs one Agent Middleware API calls are with Christopher Sellers.