--- title: "Glossary: Attributable read" canonical_url: "https://tokenobserve.com/glossary/attributable-read" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: Attributable read An attributable read is a read of a sensitive record that is itself recorded as an event naming the identity that performed it, the query or scope it used, and how much data came back. It applies to looking the accounting normally reserved for changing, on the basis that access to a record of people’s activity is an exercise of authority rather than a passive act. ## Also called - audited read - read auditing - evidence access logging ## In practice 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 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 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. ## Example: Who read the refund investigation Six weeks after a disputed refund, the question is who inside the company read that customer’s agent history. Two shapes of answer are possible. One is an application log of 240,000 lines showing a service account issuing queries, rotated after fourteen days, administered by the team under question. The other is eleven entries in the chained audit record: four searches by a named compliance officer with the interpreted filter, the team scope applied and the result counts; two record reads; one export carrying the digest of the bundle it issued, so a file in circulation can be tied back to the read that produced it; one refused read from an account outside the scope; and the erasure preview and the deletion, each carrying a digest of the subject identifier rather than the identifier. Only the second answers the question, and only the second can be shown not to have been edited since. ## Routinely confused with Access log: A web or database access log records requests to a service, for operations, rotated on a schedule and administered by the same people it records. An attributable read is an audit entry carrying an identity, the scope applied and a result count, held under the same integrity guarantee as the rest of the audit record. One is telemetry; the other is evidence. Access control: Authorisation decides whether the read may happen; attribution records that it did. A system with careful scopes and no read records can tell you what was permitted and not what was done, and the question after an incident is always the second one. Non-repudiation: Attribution binds a read to an identity your own system authenticated, which is enough for an internal investigation and for a regulator asking who accessed this. Non-repudiation would mean the reader could not credibly deny it, and that requires a signature under a key only they hold. Audit entries give you the first, not the second.