The audit record

Three different records answer three different questions, and a review that conflates them ends up asking for something that already exists under another name. Read this page for which one you want.

The receipts

Every tool call leaves one. Successes, refusals, and calls parked waiting for an approver alike: there is no path through atmon that acts without writing one, and none that skips it under load.

A receipt carries what was asked, which action ran, against which connected account, for which entity, what it returned, how long it took, and what it cost. Receipts are grouped by the turn that produced them, so a question that ran five actions reads back as one decision with five things under it rather than five unrelated rows.

Refusals are receipts too. A call your policy stopped is more interesting to a review than a call that succeeded, and a system that only records what it did cannot show you what it declined to do.

Attribution

Attribution starts at a key. It answers which key, holding which role, acting for which entity, in which chain of principals, is responsible for a call. It is what you read when the question is about spending or about responsibility rather than about what happened.

It is on the Governance surface and on the command line:

automaton governance attribution -addr <url> -key <api key> -chain <hop[,hop...]>

Attribution cannot answer a question that starts before a key exists, which is why the administrative record is a separate thing.

The administrative record

Every administrative act, appended and never edited. Sign-ins that succeeded and sign-ins that failed, sessions revoked, credentials added and removed, invitations sent and accepted, roles changed, memberships ended, ownership transferred, keys issued and revoked, signups throttled, lockouts applied, refresh tokens rotated and refresh tokens replayed.

Four properties are worth stating to a reviewer directly.

The set of event kinds is closed. A free-text kind is a log nobody can query, so every row is one of a fixed vocabulary, and a query by kind returns everything of that kind or the feature does not exist.

Normal traffic is recorded, not only exceptions. Ordinary refresh rotations are in the log beside the reuse detections. A record holding only the failures shows a reviewer exceptions with nothing to be exceptions to.

The one row written by a person holding the machine is named as such. Claiming a node mints a first-login link from the command line rather than over the network, and that act appears in the record under its own kind. It is exactly the event a security review wants to see written down rather than inferred.

Network origin is a prefix, never an address. Each row records the /24 or /64 an actor came from and not the full address. It is enough to see that a session moved networks and not enough to become a location record of your staff.

Reading it

In the console, under members, where the administrative acts sit beside the people they were done to. It is an admin-only read with no control in it, because it is a record rather than a screen you act from.

Over the API, ListIdentityEvents returns the same rows newest first, filterable by actor and by kind, and paged backwards by timestamp. Admin only, and session-authenticated, on the same rule that stops a key from managing members.

Getting it out of atmon

Traces export to your own collector over OTel, which is the path that puts atmon's record beside everything else your organization already watches:

automaton otel set -addr <url> -key <approver key> -endpoint <your collector> [-sampling 1.0]
automaton otel get -addr <url> -key <api key>

Writing a destination needs an approver key rather than any key, so pointing your telemetry somewhere new is an act with a second person's authority behind it.

A scheduled push of the administrative record into a SIEM is not built. Today the record comes out through the API read above, and the traces come out through the collector. If your retention policy needs the administrative record held longer than the deployment holds it, pull it on your own schedule and say so in your runbook.

What retention does to it

A retention sweep replaces the payload fields of tool calls, job log entries, and trigger events past their window with a redaction record holding the original byte count, field count, and digest. Every identifier, timestamp, status, error code, count and link survives, and no row is deleted.

So the record of what happened outlives the data the call touched. That is the property that lets an organization honour a short data-retention policy and still answer a question about last year, and it is worth checking against your own policy rather than assuming either half.