Attributable read

Auditing writes is habitual; auditing reads rarely is, and the asymmetry stops making sense the moment the store being read is an agent evidence store. That store holds prompts, tool arguments and the identities of the people the agents acted for — a corpus of personal data the organisation did not possess before it deployed agents. Pulling up one named person’s history is a privileged act. So is a bulk export. So is the preview query that counts how many of a subject’s records exist before an erasure runs, which is exactly the kind of read that gets built as a convenience and shipped unaudited. Data protection regimes treat access as processing; the operational argument is blunter, which is that an investigation into misuse of an evidence store is unanswerable when the store does not record who read it.

Four properties separate an attributable read from a line in a log file. The read is performed by a named human identity with a server-side session, not by a shared credential — a shared administrator token makes every read attributable to the token and to nobody. The scope is derived by the server from that identity rather than accepted from the request, and re-checked on every surface that returns the data: list, search, detail, export. Scoping the list endpoint and leaving the detail URL open is the usual way this fails. The recorded entry carries the query as it was interpreted, the scope that was actually applied and the number of records returned, because who read what without how much came back cannot distinguish a targeted lookup from a bulk pull. And identities have to survive: disable accounts rather than deleting them, or the entries stop resolving to a person exactly when somebody asks.

Refusals are events too. Returning forbidden rather than not found for a record outside the reader’s scope turns an attempt into an attributable event instead of an ambiguous missing identifier, which is what you want when the question is whether anyone tried. It trades against identifier probing, since a uniform refusal is also what stops a caller distinguishing a real record from an absent one; the way through is to pick one rule, apply it on every surface, and record the refusal either way, so the trade is a decision rather than an accident of which handler ran first.

Where the read record goes decides whether it is worth anything. Put it in the same tamper-evident chain as the administrative acts, not in an application log the reader can rotate or edit, because a record of who read the evidence that is weaker than the evidence is not much of a control. And take care that the entry does not become a second copy of what was read: record a digest of the subject identifier rather than the identifier, the kinds of data matched rather than the values, and counts rather than results. An erasure whose audit entry quotes the erased identifier has, in a small way, undone the erasure.

The two failures to test for are dull and common. First, internal tooling: background jobs, support consoles and analytics pipelines read the store through service accounts, and their entries name a system rather than a person, so the trail dies at the boundary of the thing you actually wanted to see through. Second, coverage: read auditing gets added to the obvious endpoints and missed on the derived ones — the search box, the export, the CSV download, the erasure preview, the support tool that renders a single record. A useful test is to take a week of read entries and try to answer who looked at this person’s data. If answering it requires knowing which internal system maps to which service account, or a second query against a different log, the reads are logged rather than attributable.