A worker identity that has only ever read two names begins listing a whole branch of the name space — what does that signal even though every read succeeds?

## Breadth as a dimension of its own Most discussion of abnormal reads is about volume — someone read too much. Breadth is a separate and often earlier signal: the identity read, or asked to see, things outside what its job needs. For a worker whose entire secret usage is two names at start-up, breadth is the tightest dimension it has. Any widening is visible immediately, and there is no legitimate version of it that does not correspond to a deliberate change in the job. That is worth stating plainly because it inverts the usual intuition. A busy, general-purpose caller has a noisy breadth dimension and a useful volume dimension. A narrow worker is the opposite: its volume is a little noisy because restarts vary, and its breadth is almost perfectly quiet. ## Listing is disclosure, not a harmless subset of reading It is tempting to rank the operations as list < read, on the grounds that listing returns no values. That ranking is wrong, and the reason matters: - **The names are information.** A branch of a name space is a map of the estate: which systems exist, which teams own them, which environments are separated, which downstream accounts are held. That is reconnaissance, delivered by the store, for free. - **It converts blind guessing into a target list.** Without it, a caller has to guess names and generate refusals — which is exactly the noisy, detectable behaviour you would rather they produced. Listing lets them skip that step silently. - **It survives a denied read.** Even if every value under the branch is refused, the caller has already learned the shape of what it was refused. So a grant that includes listing over a branch discloses the branch's contents-by-name to everyone holding it, and that disclosure has already happened by the time you notice. ## Two findings, not one When this signal fires, resist collapsing it into a single sentence. There are genuinely two things to say: 1. **A capability gap existed.** The identity could list a branch it had never listed, which means the grant was written wider than the need — probably at onboarding, probably by copying another service's rule. The grant has been over-wide for as long as it has existed; today is just the day something used it. 2. **Something is using it now.** A first-ever list call from an identity whose recorded shape is two reads at start is a departure in a dimension that has never moved. The first is a standing weakness that would be worth fixing even if the second turned out to be an engineer debugging with a borrowed credential. The second is what needs an explanation today. ## The innocent twins Being honest about what else produces this is what separates a usable signal from an alarm nobody trusts: - a person using a workload's credential interactively to troubleshoot, which is a process problem in its own right - a new library or platform agent that enumerates before fetching, introduced in a deploy - a migration tool run once, under whichever identity was to hand - a genuinely widened job that nobody recorded — the worker now needs a third value, and the deploy went out before the baseline was re-derived Every one of those is a permitted operation by a valid credential, and the only thing that separates them from abuse is an explanation from a human who knows what changed. That is the correct outcome of the signal: it produces a question with a name, a time and a specific operation attached, which is a very different thing from "something looks odd". ## What follows, and what does not What follows is a question about scope: which names were returned by the listing, and which of them were subsequently read. That is what turns a departure into an assessment of what an attacker could know. Whether the signal ends in a declared exposure, and what is done about the credential, is a separate matter from detecting the departure at all. What does not follow is any conclusion drawn from the store's outcome field. Every call in this story succeeded — the list succeeded, and any reads under it that the grant covered succeeded too. The store behaved exactly as configured. The entire finding exists in the comparison between what the identity did and what it had ever done before, which is why breadth has to be a recorded dimension rather than something you notice by reading logs after someone else raises the alarm.