Is the Log All of It? How Remit Shows an AI Agent Did Nothing Else

This is the prose version of our film Is the Log All of It?, the sequel to Who Wrote the Log?. That one asked who keeps an agent’s record. This one asks whether the record is all of it.

Intact is not complete

An illustration, not a real incident: an agent keeps its own log, every line hash-checked and intact. It also took one action it never wrote down. Every integrity check passes, because each one tests the lines that exist; the missing line is not there to fail. As Remit’s README puts it: “Tamper-evident logs prove a record has not changed, but not that it is complete: an action that was never recorded is invisible to every integrity check.” The gap only shows against a record someone else kept.

Three things to prove

The same README sets the bar: an agent “should be able to show, with evidence rather than assurance, that every action it took was authorized, that it could not have acted outside that authority, and that it took no action that is unaccounted for.” Tokens answer the first. Policies answer the second. A signed log cannot answer the third, however carefully it is signed.

How Remit answers the third

Remit is Abacross’s open-source attempt at that third question, in four parts.

  1. Warrants. Before the agent acts, a person signs a warrant: which agent, which actions on which resources, for how long, and why. A delegation can only narrow it.
  2. A broker. The agent holds no standing cloud credentials. The broker issues short-lived ones stamped with the warrant’s identifier, so the provider records that identifier on every call.
  3. Reconciliation in both directions. The warrants are checked against the provider’s own audit record, which the agent did not write, and that record against the warrants. “An action outside any warrant becomes a finding, not an absence.”
  4. A witnessed log. “A warrant that is not in the log is never honoured.”

What happened when we ran it

We ran it on our own account, and the recorded results keep the parts that went wrong. On 24 September 2026 the first live session went through Remit, and CloudTrail, AWS’s own record, carried the warrant’s identifier.

The first reconciliation covered 384 events and returned incomplete. It was right: the three sessions of those first live runs had each outlived their warrant by about a second. That came from comparing the cloud’s own record of each session with its warrant, not from anything Remit wrote about itself. The broker now keeps a 60-second margin.

We also edited a copy of a signed report so its verdict read “complete”. The verifier rejected it and the log refused it. On 25 September 2026 came the first complete verdict: 27 events across two regions, checked against the provider’s signed record, 74 hourly digest files and 75 log files.

What it does not claim

The specification is plain in section 7: “It does not judge intent. A warranted action can still be the wrong one; the warrant says who allowed it.” And: “It does not prevent an action the cloud permits and the warrant permits. It makes that action attributable.” A complete verdict means nothing happened outside the warrants, not that the warrants were wise.

Not only AWS, in principle

The design needs a record the agent did not write, and the other major clouds keep one. On Azure, “Azure Monitor collects activity log entries by default with no required configuration. The system generates these entries, and you can’t change or delete them” (Microsoft Learn). On Google Cloud, “Admin Activity audit logs are always written; you can’t configure, exclude, or disable them” (Google Cloud). In practice, Remit’s broker and reconciler run on AWS today. Brokers for Azure and Google Cloud are not built yet.

Try it

The code is at github.com/abacross/remit under Apache-2.0, and our own Remit log is public at abacross.github.io/remit-log. Agents reach it two ways today (ADR 0009):

  • an MCP server with three tools: see the warrant, check one action, run one command under the warrant;
  • a plugin for Claude Code and the Claude Agent SDK, which also stops the agent calling cloud command-line tools directly, so its cloud work goes through the warrant.

The ADR calls that stop a guide rail, not the boundary. The boundary is that the agent holds no cloud credentials. A signed log shows nothing was changed; Remit is our answer to whether anything was left out.