Which fields must a secret store's access entry carry so a review three months later can name which identities read one value?

## The record is the store's output, not a debugging byproduct A secret store's access record exists to answer a question that is never asked while the read is happening and is almost always asked long afterwards: **which identities obtained this particular value, and between which dates**. A review three months after the fact — an outside reviewer asking who could have read a reporting warehouse's database credential — can only be answered from that record, because nothing else in the estate knows. That inverts the usual design instinct. The fields are not chosen from what was convenient to emit at the call site; they are chosen from the future question, working backwards. ## The fields, and the question each one answers | Field | The question it answers | What breaks without it | |---|---|---| | Timestamp, with zone and sub-second precision | *When* | entries cannot be ordered against any other record | | Acting identity, as a **stable identifier** | *Who* | the read is attributable to nobody | | How that identity authenticated | *How it got in* | you cannot tell a stolen bootstrap value from a platform-signed identity | | The value's `name` | *Which value* | a read of the wrong branch looks identical | | The value's `version` | *Which copy of it* | you cannot say whether the leaked copy was the one served | | Operation — read, write, list, refusal | *What was done* | the record answers only one of four questions | | Outcome, plus the rule that allowed it | *Whether it was served, and why* | "allowed" cannot be traced to a grant you can withdraw | | Source address and a caller description | *From where* | a read from an unexpected place is invisible | | Correlation identifier | *Which request* | the entry cannot be joined to the caller's own records | | Sequence number | *Whether the record is complete* | a missing entry is indistinguishable from a quiet hour | ## Identity is the field that decays Two failures are common and both are visible only later. The first is recording a **display name** — a human-readable label that gets renamed, reassigned or deleted. Three months on, the entry names something that no longer resolves, or worse, resolves to a different principal. Record an identifier the store will not reissue, and carry the display name beside it as a convenience rather than as the answer. The second is recording only the **session reference** — the handle the store issued when the caller authenticated. That answers *which session*, not *which identity*, and if the session was issued to a role several people or several workloads share, attribution stops at the role. The entry should carry the authenticated identity through from the moment of authentication, and where a shared role is unavoidable, the record's honest reading is "someone holding that role", not a person. ## What the entry must never carry The value read is absent, always. Putting it in creates a second, longer-lived copy of the credential in a place designed to be widely readable and retained for a long time — which is the exact shape of the problem the store exists to prevent. The `version` does the identifying work instead: it says which copy was served without reproducing it. A digest of the value is a weaker but real version of the same mistake. Where the value has low entropy — a chosen passphrase rather than a generated key — the digest is recoverable by guessing, so the record becomes worth stealing on its own. Where the value is high-entropy, the objection is weaker, but the digest still buys nothing the version does not already give you. The same applies to anything derived from the value: a rendered connection string, a parameter set carrying it, an error message quoting it. ## Writing for a reader who is not you 1. **Prefer identifiers that survive renaming** for the identity, the value and the rule that allowed the read. 2. **Record the version on every read**, not only on writes, so a read can be tied to a specific copy after a rotation. 3. **Record the outcome and the rule together**, so a review that finds an unexpected allowed read can go straight to the grant that permitted it and withdraw it. 4. **Emit one entry per operation**, not a summary per session, so breadth and timing survive. Stores differ in how much of this they emit by default; some record reads richly and refusals thinly, some record nothing about listing at all. Treat the list above as the target shape and find out by experiment — ask your store a question at the far end of its own record and see whether it answers.