An audit log answers one of four questions an agent trust stack faces

In August 2026 I read the KYA survey arXiv 2605.25376 and held my own agent-call tables up against it. The survey puts the unclosed gaps in agent infrastructure in three places: identity, provenance, verifiable behavior contracts. My tables answered exactly one of the four questions a trust stack has to face.

Screenshot: agent-call ledger sketch, columns call_id, mandate_id, depth, spend_cap, ts.

The four questions

IDENTITY   who is acting?
AUTHORITY  who allowed it, and within what scope?
EVIDENCE   what happened?
ASSURANCE  was it right, and who carries the cost when it wasn't?

Audit trails, lineage, redaction, retention: that is the third question. Observability platforms added these surfaces through 2025 and 2026, prices dropped, and audit logging became a commodity. The other three questions still have no off-the-shelf answers.

Identity: the agent needs a name that survives the key rotation

A stable identifier that does not bind to one API key or one wallet. W3C DID and Verifiable Credentials won the format war, and ERC-8004 adds an on-chain passport. If you log calls by key id, every rotation rewrites your history. Those standards put money and rules side by side, and I wrote the design side of that line in Design for Web3: Where Trust Meets Regulation.

Authority: a mandate, not a config policy

A mandate is a signed artifact a third party can verify: who issued it, what it allows, when it expires. Google's AP2 chain (Intent → Cart → Payment) travels as W3C Verifiable Credentials. UCAN, ZCAP-LD and macaroons solve the same problem inside capability systems. The schema fits in one file: tool_calls.mandate_id references a mandate row, and the row holds scope as JSONB (allowed tools, spend cap, time window). Then the approved string becomes a link to a signed document.

The delegation chain: nobody answers this

Human → agent A → agent B → agent C: which production system today answers who authorized the final call? The identity standards survey (arXiv 2604.23280) says none. A chain that works keeps three properties: each link signs, each link narrows scope, and revocation at the root cascades to every leaf. You do not have to solve the theory. Record the chain honestly and answer "depth=3, root principal=P" when someone asks. Very few teams can do even that.

Assurance: disputes and the stop button

Agent payments settle through x402, and settlement is final. No chargeback. When a tool takes $0.05 and returns garbage, today nothing happens. The fix needs three parts: escrow with a timeout, a dispute protocol that reads evidence from the ledger, and automatic arbitration for micro amounts, because nobody argues manually over one cent. The audit log stops being paperwork and becomes the evidence. Inside the interface a cheaper version of that evidence is a visible confidence score, and I argue it in Glass-Box AI: Showing Model Confidence So People Trust It.

The other half of assurance is the stop button. An agent misbehaving at 3 a.m. can only be caught by stopping it before the next call, so revocation latency is a metric you can sell: seconds or minutes.

Buy the boring parts

Key rotation: GCP KMS. Trusted time: NTP plus an external timestamp service, because without signed timestamps you cannot prove event order. Interop adapters for AP2, ERC-8004, MCP-I, Visa TAP, Mastercard Agent Pay: thin, one per protocol, while the standards fight. A jurisdiction resolver: a plain rules table at first. I keep that table outside the model, and the split is in Why Your AI Agent Needs a Compliance Layer.

I build agent-facing surfaces and keep the proof per call. The contact form is on the site.