After a holder of the file's key leaves, what can you establish about which credentials they actually read?

## Opportunity against use After a holder with the file's key leaves, the question the incident actually turns on is **which values must be treated as theirs**. Two different kinds of evidence could answer it, and only one of them exists in each model. - **Opportunity**: who could have read this. With a file you have exactly this, from the outside — who was given the key, and when they last pulled a copy of the repository. - **Use**: who did read this, and when. With a file you have none of it, because the decryption ran on their machine with no participation from anything you operate. Nothing in the file closes that gap, and no amount of care in how the key was handed out changes it. So the scope is the union of everything the file held during the period they held the key. On the estate in question that is forty entries, replaced across forty owning systems, because the alternative is trusting their account of what they opened. ## What changes when the store serves the value A store hands values out over a request, which is the whole reason it can record anything: the read happens at a service you run. Each successful read produces an event carrying, at a minimum, **which identity**, **which name**, and **when**. That converts the scope question from an assumption into a query, and the replacement list from forty entries to the ones actually fetched. This is the single most under-appreciated difference between the two models, because it is invisible until the day you need it and then it is the difference between a week of coordinated replacement and an afternoon. ## Three limits worth stating before you rely on it 1. **Attribution needs a per-person identity.** If everyone authenticated as one shared deploy identity, every read under it is unattributable and you are back to the file's answer. The record is only as sharp as the identities behind it. 2. **It records the fetch, not the fate of the value.** The event says a value was read; it cannot say whether it was used once in memory, written to a note, or carried out of the building. A read record bounds what *could* have been taken and never establishes that nothing was. 3. **It is bounded by what the store actually saw.** Values that were copied out of the store and pasted somewhere else are read from that other place thereafter, with no event at all. ## Why alerting on failures would not have helped This case is a legitimate holder using legitimate access, so every read they made **succeeded**. Alerting on failed authentication or refused reads is looking at the wrong population entirely. The signals that surface abuse of valid access are shaped differently: - a read from an identity that has never read that name before; - a read at an hour the consumer never runs; - a volume of distinct names no single consumer needs — an enumeration rather than a fetch; - reads continuing after the work that needed them ended. ## What the two models can answer | Question asked after the departure | Encrypted file | Store serving reads | |---|---|---| | Could they have read this value? | Yes, for everything in it | Yes, for their granted names | | Did they read this value? | Unknowable | Recorded, per identity and time | | Was the value used afterwards? | Unknowable | Unknowable — the store sees fetches | | How wide is the replacement list? | Every entry, by assumption | The names actually fetched | ## How to use it honestly in the write-up The defensible sentence is narrow. "The record shows three names fetched by this identity during the engagement, the identity was not shared, and the record covers the whole period; we replaced those three and reviewed the grants that would have allowed more." Every clause there is doing work: without the second, the three names mean nothing; without the third, you replaced what the surviving window happened to show. The indefensible sentence is the tempting one: "the record shows they only read three, so nothing else is at risk". That claims non-use from an absence, and an absence in a read record is compatible with a value having been copied out long before, or read through an identity that was not theirs. An external audit asking who could have read a value and when is answered from the same material, and it exposes the same weakness: a model where everything decrypts locally has no answer to give, whatever the intentions of the people who held the key.