Payloads on a long-retained stream were encrypted by their writers, so a year on, what does custody of those encryption keys decide?

## Why custody is the real access decision On a cluster where the broker reads plaintext, the question "who can read this stream's history?" is answered by the grant table, and it can be answered again tomorrow by editing it. Once the writers encrypt payloads, that stops being true. The grant decides who can obtain the bytes; the encryption key decides who can understand them. Two consequences follow that most teams do not plan for: - **Reading history is retroactive.** Whoever holds the key today reads records written a year ago, by people they never met, for purposes nobody remembers. Handing someone the key is not a forward-looking grant; it is access to everything in the window. - **Denial is retroactive too.** Withdrawing the key removes access to that same history even from a principal whose broker-side grant is untouched. The two control surfaces can disagree, and the key wins. ## Custody is also a durability decision This is the half that surprises people. If the key the records were written under is lost — a team dissolved, a store rebuilt, a custodian gone — the records remain exactly where they were. Every copy is intact, retention has not expired, the cluster serves them happily, and they are meaningless. There is no operational recovery from the broker side, because the broker never had anything to recover with. So the design questions for a stream carrying opaque payloads are the same ones you would ask about a backup: 1. Who can produce the key today, and who can produce it if that person and their team are gone? 2. Is the custody arrangement itself recoverable, or does it have a single point of failure that nobody has exercised? 3. Does the retention window on this stream exceed the lifetime of the arrangement that protects it? If history is kept for a year and keys are managed by a team that reorganises every six months, the answer is already no. ## Moving to a new encryption key Stored records are already written, and a broker's history is append-only: there is no operation that re-encrypts what is there. That produces a specific, permanent shape: - New writes use the new encryption key; **everything already retained stays bound to the key it was written under**. - A reader that must cover the whole window therefore has to hold more than one key, and must be able to tell which one applies. That requires the record to carry, outside the ciphertext, an indicator of the key it was written under. - "Re-encrypting the history" is possible only by reading it out and writing it somewhere else as new records, which produces new records with new positions — a migration, not an in-place change, and it is rarely worth it. The practical rule: the number of keys a consumer must be prepared for is set by how often you change keys and by how long the stream keeps history. ## Who should hold it | Custodian | What it gets you | What it costs | | --- | --- | --- | | The producing team | Access follows the data's owner; narrowest reader set | Central teams cannot help debug; history is orphaned if the team dissolves | | A central platform team | Durable, staffed, recoverable custody | The platform team can read everything, which was often the point of encrypting | | A rented tier's operator | No machinery for you to build or run | Their staff are inside the boundary; you have re-created the problem | | A consumer-side group per stream | Readers hold exactly what they read | Duplication, and no single answer to "who can read this history?" | There is no free option, and saying so is the answer to this question. The point of writer-side encryption was to exclude the operator; choosing an operator-adjacent custodian for convenience quietly undoes it, and a lead is expected to notice that trade rather than discover it in an audit. ## What varies Platforms differ in ways that change the sums. Some keep history for days, so custody only has to outlive a week and the problem is small; others keep months or years, and on those the custody arrangement must outlive people. Rented clusters differ in whether you can supply the key that protects their storage at all — where you can, it changes who can read the volumes but not who the broker serves plaintext to, so it is not a substitute for writer-side encryption. And platforms differ in what a record may carry outside the ciphertext, which decides how gracefully you can run several keys at once. ## Answering it well Name three things: custody decides retroactive read access; it is a durability dependency, because the bytes survive and the meaning does not; and old history cannot be re-encrypted in place, so every key decision is bounded below by the retention window. Then state who you would make the custodian and what you accept by doing so.