Every credential your team uses is held in a secret store, so where do copies of those values still come to rest outside it?

## The value of record is not the only copy A secret store gives a credential a **value of record**: one place the estate agrees is authoritative, with access rules and a record of who asked for it. That is a real improvement over a value living in a settings file. What it does not do is make the store the only place the value exists. Every copy outside the store was made by a person doing ordinary, well-intentioned work: getting a colleague unblocked, reproducing a failure locally, writing down a recovery step so the next person is not stuck at 3am. **Sprawl** is the name for the resulting population of copies. Its defining property is asymmetric: the store can tell you exactly what it holds and which callers it answered, and nothing anywhere can tell you how many copies rest outside it. ## Where copies come to rest - **A configuration repository.** A settings file carrying the value in clear text. The current file is only half the problem — the repository's own history keeps every earlier revision, and every clone and fork carries that history with it. - **Shell history.** A value pasted onto a command line is written verbatim into that shell's history file, on that machine, under that person's account, and stays there until the file rolls over. - **Terminal scrollback.** The same value sits in the buffer of the window it was typed in, in any recorded screen share, and in the screenshot someone pasted into a thread to show the error. - **A chat thread.** Searchable, retained, exported, and readable by everyone added to the channel later — including people who were nowhere near the system when the value was pasted. - **A ticket attachment.** The request for a credential very often carries the credential, because the fastest way to answer the request was to attach it. - **A runbook page.** The value inlined into the recovery step, precisely because the page exists to be followed under pressure without thinking. - **A laptop.** A personal settings file so the service runs locally, a scratch file that was never deleted, an entry in a personal password manager. | Resting place | How the copy got there | Who can read it now | What it survives | |---|---|---|---| | Configuration repository | Committed so the service would start | Everyone with the repository, plus every clone | Cleaning the current file | | Shell history | Pasted onto a command line | Anyone with that account or that disk | Closing the terminal | | Chat thread | Sent to unblock a colleague | Everyone in the channel, now and later | The sender forgetting | | Ticket attachment | Attached to answer the request | Anyone who can read the ticket queue | Closing the ticket | | Runbook page | Inlined to make a step copy-pasteable | Everyone with the page | Staff turnover | ## Why nobody can count them Three properties make the count unknowable rather than merely unknown. 1. **Copies are made by people, not by systems.** A system that copies a value could log it. A person pasting into a thread produces no event anywhere the estate looks. 2. **Copying is not an action against the store.** The store recorded one read, months ago, by an identity that may no longer exist. Everything after that read happened where the store cannot see. 3. **Copying is transitive.** The moment one copy exists outside the store, that copy can be copied again by someone who never touched the store at all, and the chain has no terminator. So the honest statement about any long-lived shared credential is not *how many holders exist* but *how many holders you can name*, which is always fewer. ## What follows for the estate This is the reason the first deliverable of a secrets programme is an inventory, not a store. Putting a value into a store changes where it is fetched from; it does nothing to the copies already at rest, and every one of those copies keeps working until the system that accepts the credential stops accepting it. Deciding which values to replace and which holders to cut off is a decision you can only take over a list of values and their known copies — and if the list does not exist, the default outcome is that the value stays live forever, because nothing forces the question. ## Where this leaf stops Searching automatically for credential-shaped strings, why removing a committed line does not undo the exposure, tracing which workloads read a value before you replace it, and values escaping a build into its outputs are each separate subjects with their own mechanisms. This one is about where copies come to rest and why they cannot be counted.