For most of the last few years, the interesting question about AI was capability. Can it write code, draft a contract, answer a customer support ticket. Agents change the question. Once a model can move money, sign a request, or hand work to another agent, capability stops being the hard part. The hard part is now trust: can an organization let an autonomous system take an action and later stand behind what it did.
Imagine you hand your teenager the car keys. You set a few rules: stay within the city, be home by 11, and no extra passengers. You can't ride along, so all you really have is trust — trust that they'll remember the rules, trust that they'll follow them even when no one's watching, and a plan to ask a lot of questions if they come home late.
Now swap the teenager for a piece of software making dozens of decisions a minute, and swap the car for your company card, your customer data, or the authority to act on your behalf. That's roughly where we are with agentic AI. We've spent the last few years asking whether these systems are capable. Can they write code, draft a contract, or answer a support ticket? That question is basically settled. The harder question now is whether we can trust them: can an organization let an autonomous system take a real action and later stand behind what it did?
Right now, we manage that trust the same way you'd manage the teenager situation. Before the agent runs, we try to shape its behavior in advance with prompts, permissions, and role definitions. After it runs, we check it via logs, monitoring, audits, or a human reading a transcript and clicking "confirm." Both of these help. But neither one actually proves anything. The "before" controls are advisory. A capable model can misread a rule or find a path nobody thought to close off. The "after" controls have a subtler problem: they're self-reported. A log is the system's own account of its own behavior, so a system that malfunctioned or was manipulated tends to produce a log that looks like nothing went wrong. Fine when the stakes are low. Not fine once an agent is spending real money or acting on someone else's behalf.
Here's a concrete version of the problem. A fund runs a trading agent under a mandate from one of its allocators: position limits, restricted names it can never touch, and a concentration cap it has to respect on every fill. At quarter-end, the allocator asks a reasonable question: did the mandate hold the whole way through, not just at the moments you chose to report? The fund can't just open the book; the positions are the strategy, and showing them to an allocator who also backs three competing managers isn't on the table. So it sends a report instead. It’s a document it wrote about its own behavior, attesting that its own agent stayed inside the rules. The allocator can take it on faith, or commission an audit months later that reconstructs a fraction of it at real cost.
Swap out the specifics and the same shape shows up everywhere that agents are taking real actions: a healthcare system that needs to prove an AI triage agent only ever accessed the records it was authorized to see, a supply chain where one company's purchasing agent negotiates directly with another company's fulfillment agent, a customer support bot that's been given the authority to issue refunds up to a limit. In every case, the entity being asked to trust the agent has no way to check — they either believe the operator's word, or they don't.
Verify the boundary
The tempting response is to verify the agent's reasoning and to prove the model made a “good decision”, whatever that means. That's a dead end. You can't cryptographically prove a judgment call and you don't need to.
Forget whether the model made the right call. The question that actually has an answer is whether execution stayed inside a boundary that a human approved ahead of time. Someone defines a policy: spending limits, approved counterparties, and which data may leave which system. The agent itself is treated as untrusted, it can propose whatever it wants. Think of it like an intern: capable, maybe well-intentioned, but not the one who gets final say. Every consequential action passes through an enforcement point that checks it against the policy and refuses anything outside it. That check is deterministic, which means, unlike a "good decision," it can actually be proved to have happened correctly.
It’s worth being precise here, because the loose version of the claim invites an easy rebuttal. You are not proving that the agent followed policy. The agent has no obligation to follow anything; it can propose whatever it wants. You are proving that the enforcement point did its job and that it evaluated each action against the approved policy and let only compliant ones through and that the resulting receipt can be checked by someone who never has to trust your infrastructure.
That receipt is the whole point. It’s portable evidence that a workflow stayed inside its policy, checkable by a third party who doesn't have to take your word for any of it.
When this is worth the cryptography
Verifiable receipts are not free and most workflows don't need them. It’s worth reaching for when these conditions hold together:
- Someone who doesn't trust the operator needs to be convinced. An allocator checking a fund's trading agent, a regulator, a counterparty, an auditor. If the only party who needs convincing is you, logs are fine.
- The inputs are sensitive. Amounts, counterparties, the thresholds inside the policy itself — things you need to prove compliance about without publishing them. If you can expose everything, plaintext and a signature will do.
- Work is delegated. An orchestrator hands tasks to sub-agents or to agents in another organization and you want the whole chain to reduce to one portable proof instead of a pile of separate attestations.
When all of these hold, cryptographic verification earns its place. When only one does, it's overkill, and someone technical will say so.
How it fits together
The shape is straightforward. A human specifies what they need and approves the compiled policy, the artifact that actually gets enforced, not a plain-language summary of it, since a summary reintroduces the same trust problem at the point where intent is translated into rules. An orchestrator delegates work across agents and every action those agents take has to pass through the enforcement checkpoint, which checks it and issues a proof. Because these proofs are recursive, the proof from a delegated sub-agent folds into its parent’s and the whole workflow collapses into a single succinct receipt. A verifier checks that receipt against the public policy and learns exactly one thing: the workflow stayed in bounds. They learn it without ever seeing the sensitive inputs and without having to trust the operator who ran the workflow.
This is where zero-knowledge proofs come in, they’re what make it possible to verify compliance without exposing the private data and composing many agents' proofs into one.
Proof over promises
Most of the trust machinery around software today runs on promises. A vendor asserts a boundary in a contract. An operator tells you its agent behaved. These assertions are only as good as the incentive to honor them and the difficulty of checking them once the moment has passed.
Cryptographic receipts replace the promise with something checkable. The claim stops being "trust us" and becomes "verify it yourself". For autonomous systems taking real actions, that is the missing layer. We already have tools that govern intent beforehand and record what happened afterward. What's missing is the layer that proves, independently, that execution stayed inside the rules, while the workflow is running and in a form anyone can check later.
This starts with agent actions because that is where the need is strongest and the value moves fastest. But the underlying idea is more general than agents. The same boundary logic, a policy someone approved, an enforcement point that proves conformance, a receipt anyone can verify, applies to other questions of the same shape: what data left a given system or which sub-processor was allowed to touch a record. Proving what an agent did is just the first instance of a broader move from promised control to proven control. That is where trust in autonomous software is heading, and it's what we're building for.