A team's principal is allowed to update the permission document attached to itself; how does that single grant become full administrator access?

## Write access to the permission system is a different kind of grant Most permissions answer the question *what may this principal do to the estate*. A small set answer a different question: *what may this principal do to the permission system itself*. Those are the actions that write, attach, detach or delete a permission document, or that change the `condition` under which an identity may be taken on. The platform evaluates the current document on every call. So a grant of write access to the document that governs you is not one permission among many — it is a grant of every permission, one edit away. The scoping in it usually looks careful, because the resource genuinely is narrow: **the team's own principal**. That narrowness is what makes it pass review, and it is also what makes it total. ## Four edits that all end in the same place 1. **Append an allow.** Add a statement allowing every action on every resource to the document attached to your own principal. The next call succeeds. 2. **Attach a stronger document.** Do not write anything new; attach an existing administrative document that somebody else already wrote and the platform already trusts. 3. **Edit a trust condition.** Change the condition on a stronger identity so that it will accept being taken on by you, then take it on. You never edited your own document at all. 4. **Remove a deny.** Delete the explicit deny that was the whole control, from a document you are permitted to edit. Each of these is one management API call. None of them requires an administrative action to be granted anywhere, and after step 5 — putting the document back — the grant set looks exactly as it did before. ## Why an explicit deny is usually the wrong fix, and when it is the right one An explicit deny normally beats any allow, which makes it the first thing people reach for: deny the permission-writing actions, keep the convenient grant. The reasoning is sound and the placement is usually wrong. **A deny constrains a principal only where that principal cannot edit the document carrying it.** If the deny sits in the same self-managed document, removing it is the first call of the attack, and the control is decoration. So the deny has to live outside the principal's write reach: in a ceiling applied to the principal that local grants cannot exceed, or in a document owned by a separate function that self-service teams have no write action against. Where it lives matters more than what it says. ## What closes the path | Approach | Effect | The catch | |---|---|---| | Remove the permission-writing actions from self-service principals entirely | The path does not exist | Every permission change becomes a request to another team, which is the friction self-service was meant to remove | | Ceiling above the principal that no document it writes can exceed | The team keeps writing its own grants, but cannot write itself past the ceiling | The ceiling has to be attached when the principal is created, and it must itself be unwritable from inside | | Deny the permission-writing actions in a document the team cannot edit | Blocks the edit at call time | Worthless if the deny is anywhere the team can reach | | Alert on any change to a permission document | Gives you the moment it happened | Detective only; the call already succeeded | ## Why the review misses it The grant is small. It names one or two actions and one resource, and the resource is unmistakably the team's own. An approver checking *does this principal have administrative permissions* reads it and correctly answers no. The question that finds it is a different one: *can this principal change what the answer will be on the next call?* That reframing is the whole skill. The actions that write the permission system, that attach an identity to a workload, that issue a credential for another principal, and that take on another identity are all answers to the second question, and none of them looks administrative in the first. Platforms differ in how finely these write actions are split — some expose separate actions for writing a document, for attaching one, and for changing a trust condition, others fold them together — and that granularity decides how precisely you can grant part of it. What holds everywhere is that partial write access to the permission system is still write access to the outcome unless a ceiling caps it.