The job that applies your store's access rules can grant any right to anyone — how do you bound the most powerful identity in the estate?

## Why least privilege does not apply here The usual move — give the identity only what it needs — does nothing for an identity whose job is to change any rule. You cannot narrow it without breaking it. So the real question is different: **where does its authority actually live, and can it be split?** Answering that well is what separates a design from a diagram. The honest starting point is that concentrating this power in one automated identity is usually *better* than the alternative it replaced, which was a dozen humans each holding the same right at a console. One identity reading one reviewed input is far cheaper to watch, reason about and attribute than twelve people. But that argument is conditional, and the conditions are the design. ## Four bounds that do work 1. **Its input is its authority.** The job must accept exactly one source, and that source must be a place only reviewed changes reach. The consequence is uncomfortable and often unnoticed: whoever can write to that source, change which source the job reads, or edit the job definition holds every right the applier holds — without appearing in a single rule review. The protections on the source and on the job are therefore part of the access-rule system, and they are now among the highest-value targets you own. 2. **It changes rules; it does not read values.** Rewriting a rule and reading a stored credential are different powers, and an applier that holds both collapses them into one identity that can grant itself a read and take it. Keeping the two apart is a general discipline of its own, but the applier is the single most important place to apply it. 3. **Partition it.** Several appliers, each able to change only the rules governing its own branch of the name space, so that no one identity can rewrite the estate. This is the only bound that genuinely reduces blast radius rather than adding a check in front of it. 4. **Gate its own effect.** The applier computes the effect of what it is about to apply and refuses on two conditions: the effect differs from what was approved, or the set alters the applier's own rights or the rules protecting its source. These are mechanical checks on a delta — no judgment, no reviewer's attention required. ## The cost side, stated honestly | Bound | What it buys | What it costs | |---|---|---| | One protected input | Every applied rule traces to a reviewed change | The rule change at 3am now needs the source, the review path and the job all healthy | | No read of stored values | The applier cannot grant itself a value and take it | A second identity and a second path for anything that legitimately needs both | | Partition by name branch | No single identity can rewrite the estate's rules | Coordination, duplicated review paths, and a shared region that still needs one owner | | Effect gate on its own set | Lockouts and self-widening refused mechanically | A change that must bypass the gate now needs an explicit route, which is another door | Every row trades availability and speed for attributability and blast radius. That trade is the judgment call, and it is genuinely open: a four-person team with one name space that partitions its appliers has bought coordination overhead and very little safety, while a large estate that leaves one applier able to rewrite every rule has a single identity whose compromise ends the argument. ## The judgment you own - **How many appliers, drawn along which boundary?** Ownership boundaries usually beat technical ones, because the coordination cost lands on whoever has to agree. - **What may bypass which guard, and who decides in the moment?** Guards you cannot bypass will be bypassed anyway, by hand, during an incident — which produces exactly the undeclared state you were avoiding. - **What are you prepared to stake on the review path being available?** If rule changes cannot happen while it is down, that is an availability dependency you have taken on deliberately, and it belongs in the same conversation as any other. ## What an external audit actually asks Not for a framework's wording. The questions are: *who could have changed this rule*, *what would we see if they had*, and *could they have done it without anyone approving?* A design where the applier reads one protected source, cannot read stored values, and refuses sets that change its own rights answers all three with mechanisms rather than assurances — and a design where one identity can do anything and the answer is "we trust the pipeline" answers none of them.