A read rule over one branch of secret names silently matched a neighbouring branch — what about prefix matching caused that?

## What a rule over a branch really is A rule granting rights over *a branch of names* does not hold a list of values. It holds a **pattern**, and the store evaluates that pattern against the name in each request. Everything surprising about branch-scoped rules follows from that one fact: the scope is a shape, not a membership list, and the shape is only as precise as the matching rules behind it. ## The over-match: characters instead of segments The classic failure is a pattern anchored on a name rather than on a separator. Take a rule written for the search team: - pattern `teams/search*` - intended: `teams/search/prod/index-writer-db` - also matched: `teams/search-internal/prod/root-db` — a different team - also matched: `teams/searchtest/staging/api-key` — a sandbox nobody reviewed Nothing about this fails loudly. Over-matching only ever **grants**, so there is no refusal to investigate, no error in a log, no failed deployment. It surfaces when someone reviews the rule, or when the neighbouring branch turns out to have been readable all along after an incident. The fix is to anchor on the separator — `teams/search/` — so the pattern can only continue at a segment boundary. Some stores match by segment natively and the question does not arise; some match by characters; some let the rule author choose. That difference is precisely the thing to check in the store you actually run, and the reason the answer to *does my rule cover only my branch* is **test it**, not **read it**. ## The under-match: depth The mirror image bites in production instead of in review. A pattern whose wildcard consumes **one** segment covers `teams/search/prod/index-writer-db` and refuses `teams/search/prod/eu/index-writer-db`. The day a team introduces a region segment, or splits a value into a sub-branch, reads start being refused — and the refusal looks like the store being broken rather than like a rule being precise. | pattern | matches | does not match | |---|---|---| | `teams/search*` | `teams/search/prod/index-writer-db`, `teams/search-internal/prod/root-db` | `platform/search/prod/index-writer-db` | | `teams/search/*` (one segment) | `teams/search/prod` | `teams/search/prod/eu/index-writer-db` | | `teams/search/**` (all below) | everything under the branch, at any depth | `teams/search-internal/...` | The temptation at that moment is to widen the pattern until the refusals stop, which is how a rule scoped to one environment quietly becomes a rule over a team, then over the tree. Widening under pressure is how most over-broad grants are actually born. ## Names that do not exist yet Because the scope is a shape, **anything created later under that shape is inside the grant from the moment it exists**. That is the feature — a team adds a value and its own service can read it without a rule change — and it is the hazard, because a name created under a branch by anyone who can write there lands inside every rule that matches it. When you review a rule, you are reviewing what it will match, not what it matches today. ## Where designs genuinely differ Do not state one store's evaluation as a fact about stores. Real differences you should ask about rather than assume: - Whether a **deny** rule exists at all, and whether it beats an allow that also matches. - Whether several matching rules are **unioned**, or the **most specific** one is taken alone. - Whether matching is over characters or segments, and whether one wildcard form means *one level* and another means *all levels below*. - Whether a rule on a branch implies the right to list it, or listing must be granted separately. ## Making the boundary hold 1. Anchor every pattern on the separator so a sibling whose name starts with the same characters cannot fall in. 2. State the depth deliberately — one level or everything below — rather than inheriting whichever the default is. 3. Write down the names the rule must **refuse**, including one neighbour with a similar name, and check them the way you check the names it must allow. 4. Re-check the rule whenever the name space is restructured; a restructure moves values across boundaries without touching a single rule. 5. Where the store has deny rules, put one at the boundary between teams so an over-broad pattern elsewhere cannot reach across it.