Many teams keep credentials in one shared store — what makes the boundary between two teams' branches actually hold?

## The convention is not the boundary Every shared store has a naming convention — `teams/<team>/<environment>/<system>` or something close — and it is easy to mistake that convention for isolation. It is not. The convention is a layout; the boundary is the set of rules evaluated on each request. If a team's values sit under its own first segment but three identities hold rules on the parent, the layout is tidy and the boundary does not exist. ## Grants are additive, so the widest rule decides Most designs evaluate **every** rule an identity holds, directly or through whatever roles it carries, and grant if any of them matches. That means: - An identity's real scope is the **union** of its rules, not the narrowest one. - A rule written last year for an on-call role, covering the whole `teams/` branch, silently overrides today's carefully scoped grant. - Reviewing the one rule that was just written tells you nothing about the identity's actual reach; you have to enumerate every rule attached to it. Stores differ here and it is worth knowing which you have: some union all matching rules, some take the most specific match alone, and not every store has an explicit **deny** at all. Where deny exists and beats allow, a deny at the boundary is the single most useful rule in a shared store, because it survives someone else's over-broad pattern. ## List at the shared root The second leak is enumeration. If any identity holds `list` on the root that contains both teams, it can read off the other team's inventory of names — counterparties, projects, systems — with every read denied. It is easy to grant because it looks harmless and because tooling asks for it. Deny it at the shared root, and grant it per branch to the identities that genuinely need an inventory. ## Write is a boundary break too A boundary is usually discussed as *they must not read our values*. The other direction matters as much: 1. An identity that can write under a neighbour's branch can **create** a name their service will later read. 2. It can **replace** the value their service reads at start-up, choosing what that service presents to a downstream system. 3. Neither of those fails loudly — the neighbour's service starts, authenticates and behaves normally with a credential someone else chose. So the boundary must be symmetric: neither team's identities hold read, write or list that reaches across it. ## The shared branch Nearly every shared store grows a `shared/` or `platform/` branch that both sides may read, for the message bus, the metrics endpoint, the internal registry. That branch is the boundary's honest exception, and it should be treated as such: - A credential placed there is held by **every** team that can read there, so its blast radius is the union of all of them. - Anything that should not be readable by all of them does not belong there, whatever the convenience. - Write into the shared branch is the widest write in the store, because it reaches every consumer that reads from it. ## One tree, or separate name spaces Some stores offer entirely separate name spaces, each with its own rule set and no rule able to span them; others give you one tree and expect rules to carve it up. The separate-name-space design makes the boundary structural — there is no pattern anyone can write that crosses it — at the cost of duplicating everything that genuinely is shared. One tree is more flexible and asks you to keep the boundary correct by review. Neither is universal, so say which shape you are describing. ## What to check when someone claims a boundary exists 1. Enumerate every rule attached to an identity on each side, including inherited ones, and take the union. 2. Look for any rule whose pattern matches a parent of both branches. 3. Check `list` separately from `read`, at the shared root in particular. 4. Check write and create in both directions, not only read. 5. List what sits in the shared branch and who can read it, and count that as held by all of them. 6. Ask who can add a rule that spans both branches — that identity is above the boundary regardless of everything else. The last item is the one candidates leave out. A boundary enforced by rules is only as strong as the surface that changes rules, and a good answer names that ceiling even while treating it as somebody else's question.