Use case · Audit and finance
Audit-grade AI: prove the confidential path. Expose the rest.
Audit and finance teams are moving client work to AI, and they're being asked two questions at once. Logs answer neither for the people who ask. Logs are for IT. Receipts are for AI.
The two questions
Prove you used the confidential model. Prove nothing else was used.
Prove you used the confidential model. The client's data has to stay inside an approved environment, and you have to be able to show it did.
Prove nothing else was used. A confidential model deployed somewhere says nothing about the rest of the firm. Agent work is loose: anyone can paste client data into a public chatbot, and the approved deployment never sees it.
Logs live in the operator's systems and show only what went through the approved path.
What Rootz Receipts changes
The evidence travels with the result.
Every result produced the approved way carries an origin receipt that travels with it:
- who authorised it: the officer who signed the policy the agent ran under;
- the controls actually in force: for example, no outbound access except the approved model endpoint;
- where it ran and which model ran, stated from the evidence: measured, or only declared;
- what it was made from: the inputs, with their own receipts.
The reviewer, the client or their AI can check it from the result alone, without access to your systems. Change one byte of the answer and verification fails. Check a receipt yourself.
Absence is evidence
A deliverable with no receipt didn't come through the approved path.
Once the approved path marks every output, AI governance turns from a policy statement into a test you can run over every output, not a sample: sort the population by receipt, and the off-path work shows itself. That's shadow AI, found from the output.
How we report depth
Honest about what's measured.
Two depths, computed from the evidence, never just claimed: where the work ran, and which model ran.
| Where it ran | Which model ran | ||
|---|---|---|---|
| C0 Unmeasured | no platform evidence | M0 Unknown | no model identity |
| C1 Declared | software-rooted (e.g. a software TPM) | M1 Provider-asserted | endpoint verified; the model name is the provider's claim (e.g. a frontier model via its API) |
| C2 Measured | hardware root, pinned by the recipient | M2 Weights measured | self-hosted; weights match a published hash |
| C3 Confidential | confidential VM or GPU attestation, verified; the operator can't see the data | M3 Weights attested | measured inside a confidential environment |
A policy you can write: "Client data only at Compute C3 · Model M2 or better." Anything below it, or with no receipt at all, is visible.
Today's receipts state this evidence line by line in plain words (for example, the compute evidence is "declared, not attested"). Printing the C and M labels on every receipt is the next format step.
Where we are
Alpha, ready to be put to work.
- Today's live demo runs at Compute C1: a software TPM. Its receipts say the compute is declared, not measured. Its agent is a fixed script rather than a model, so it has no model line to report; an agent calling a frontier model's API would read Model M1.
- Confidential computing (C3) is the planned upgrade: the same receipt, with the compute line verified by the hardware vendor's attestation.
- The pattern is already running: in bank collection in a box, a person logs in, a contained agent collects their statements inside an NVIDIA OpenShell sandbox with outbound access limited to the bank, and every file leaves with a receipt. It runs today against a test bank.
Put it to work on one engagement workflow: 30 days, one output that leaves the team, one reviewer who checks the receipts. Talk to us.