Proof After an Incident: How We Answer "Who Authorised This"

A hypothetical situation, the problem behind it, and what we built so it does not repeat

The situation

A client comes to us — not a startup, but a company with a process: requests, approvals, payments. We deploy an agent that runs part of that process. Two months later there is an incident: the agent sent a payment that no human approved.

The review starts with a simple question: "show us on what basis it did that." And it turns out there is nothing to show.

There are logs. There is a chat trail. There is a CRM export. But none of these artefacts answers whether the agent had the right to that action at that second, and who granted it. Authority sits in one place, the decision in another, dispatch in a third, and the fact of execution with the recipient — and nobody ever checked them together.

The problem

We framed it for ourselves like this: there is a gap between authority, decision, dispatch and effect, and the industry closes it with assurances rather than evidence.

Attestation and identity standards answer "who is on the other side": which workload, which key. That is necessary, but it does not answer "under what right did you act". A correctly attested server can accept an action outside the delegated scope, and no attestation property is violated.

Logs answer "what happened", not "was it permitted". A record can be complete and still describe an action nobody authorised.

So after an incident the client is left with a lot of data and no answer. And the vendor is left with "everything is logged", which does not survive a review.

What we built

We did not build another agent implementation. We built an instrument that lets claims about authority be checked — ours and other people's — under one set of rules.

A comparison contract. Four scenarios that break almost any design: refusal at the decision point, a decision on stale data, an unreachable approving party, revocation after dispatch. Fourteen required fields — from authority and decision through committed effect, receipt, action digest, deadline and retry count. Four evidence states: measured, not applicable, not emitted, not measured.

That last one is the key. It forbids the main manipulation in reporting: presenting "we did not measure it" as "it does not apply".

An offline verifier with negative controls. The check must reject a packet in which a case was dropped, duplicated, a verdict flipped, a cited record removed, or two rows swapped receipts. And it must accept the unaltered packet. It sounds like a formality until it fires: in one published packet a record claimed the executor refused at its own boundary, while the job record showed a stalled attempt and a refusal later, on retry. No integrity check catches that — only comparing the claim against the record does.

Openness. The contract, the cases and the refusal rules are published; the work runs in an open identity-and-trust working group, with results in a public repository and a paper under review. We are not asking to be taken on faith: anyone can take a packet and run the check.

What it gives the client

After an incident — not a "log" but a review: which authority applied, which decision was taken, what was sent, what happened on the receiving side, and where evidence is missing. Before an incident — the ability to agree in advance what counts as normal and what counts as an incident.

And, most importantly, the ability to check us through a third party. That is exactly what is usually missing from "trust us, everything is under control".

What we do not claim

We do not issue certificates or claim conformance to a standard. We have not proven that an agent is safe in general. We say plainly that part of the guarantee sits with the executor and the target: we can show that a decision was taken within the granted authority, but we cannot, alone, prove that the receiver executed exactly that action.

And we state the limits of our own method: the comparison is offline, over retained records; it does not establish live enforcement or effects on the target side.

What it looks like in practice

A pilot: we look at your agent's records, run them through the contract, and show what they prove and what they do not. Then either the record is improved, or the boundaries of authority are changed, or the uncovered part is written honestly into the contract.

If you have a running agent and a question of "what will we show if something goes wrong" — that is where we start.