Technology
Every side effect, bracketed by two signed records.
Trust Gateway sits between an AI agent and the systems it can act on. It decides whether an action may happen, performs it with credentials the agent never sees, and leaves a signed record someone outside the operating company can check. One claim holds the design together, and everything in the system either makes it true or makes it checkable later.
An action is one tool invocation. What follows is the path that invocation takes, the stack that carries it, and what can be demonstrated live today.
The agent is untrusted by construction
It holds no keys and no provider credentials. It asks; the gateway decides and acts. Nothing it can do to itself changes what it is permitted to reach.
Refusals are evidence too
A blocked action is signed with its grounds. A system that records only what it allowed cannot later show that it stopped anything.
Time is not ours to move
Third-party RFC 3161 timestamps and a daily on-chain root mean the record's age rests on parties with no stake in our version of events.
Verification without disclosure
The insurer checks a proof against a root they pinned in advance. They learn that the condition held — not what the transaction contained.
How it works
What happens to one tool call.
DECIDE
May this action happen?
The call arrives on a short-lived token and passes an allowlist, then a policy engine, then — above a threshold — a person. It fails closed, and a refusal is signed with its grounds rather than dropped.
BRACKET
Surround the effect with evidence
An intent receipt is signed before the call goes out; an outcome receipt is signed after the answer comes back. The agent never holds the credentials that make the call — the gateway does.
CHAIN
Make a gap detectable
Receipts are hash-chained per tenant, so a deleted record breaks the chain at the point it was removed. Evidence is stored under envelope encryption with the keys held in a KMS.
PUBLISH
Put the record beyond our reach
Chains are batched into Merkle trees, published to a transparency log, bound to third-party RFC 3161 time, and anchored daily on chain. Rewriting yesterday now contradicts a block we did not write.
PROVE
Reveal only what settlement needs
A zero-knowledge circuit shows that an anchored receipt met a covered condition — the breach, the ceiling, the tally — while the order, the counterparty, and the data stay with the insured. A nullifier makes a second claim on the same event fail.
Stack
What it is built out of.
Chosen so that a third party can check the result with tools they already trust, rather than tools we wrote.
- Gateway
- Go 1.25. Open Policy Agent (Rego) for the decision, PostgreSQL for state, OpenTelemetry throughout.
- Signing
- COSE signatures over CBOR receipts, produced inside an AWS Nitro enclave reached over vsock. The signing key is generated there and has no path out.
- Evidence
- Per-tenant hash chains, Merkle batching, a transparency log, RFC 3161 timestamps, envelope encryption with keys in KMS, objects in S3.
- Proving
- Noir circuits over Poseidon — authority, claim, loss, tally — proving eligibility without disclosing the action.
- Chain
- Solidity contracts under Foundry: the daily anchor, log inclusion, the claim and authority verifiers, and a nullifier registry that refuses a duplicate settlement.
- Interfaces
- An operator console in Next.js 15 and React 19, a Python SDK, protobuf definitions managed with buf, and an MCP boundary that real LLM tool calls run through.
Demo
It runs. Here is what can be shown.
Each demo answers one question and stops when the promised evidence is on screen.
Browser stage
How does an agent's authority become a signed forecast, then a proved premium and a verifiable claim decision?
Authority snapshot, signed rate card, live gateway decisions, a covered-period batch, the tally proof, and the claim decision — end to end, in a browser.
Control-failure proof
Can an insurer verify that a real action met a covered condition without receiving the receipt?
A real action, its committed receipt, the anchored root, a private proof, the insurer-side verification, and the spent nullifier.
Corroborated-loss proof
Can a corroborated loss be joined privately to the covered action and paid once, under terms signed before the incident?
A signed programme, the shared provider action id, a two-tree proof, the claims decision, limit erosion, and a duplicate claim being refused.
Said plainly, because a demo that overstates itself is worse than no demo: the proofs establish that a covered condition held and that a claim is not a duplicate. They do not establish intent, causation, actuarial correctness, or the loss amount. In the loss walkthrough the attesting bank and the insurer are simulated, and no funds move.
Get in touch
[email protected]→