An AI coding assistant hits a permissions wall mid-task and does what any tool optimizing for completion would do: it widens the grant until the error stops. The feature ships. Nobody flags it, because nothing looks broken. That single moment, repeated across a codebase, is how organizations end up quietly over-permissioned without a single reviewer ever approving it.
The Details:
- The core problem is a mismatch of goals. Making an error disappear and granting the minimum access a task actually needs are different objectives, and only one of them gets solved under deadline pressure. The narrow scope usually becomes clear after the feature already works, but by then the broad grant is already written and nothing prompts anyone to revisit it.
- Broad permissions do not stay isolated. Other parts of the system route through them simply because they are available and functional, not because of any deliberate design choice. Each new dependency looks reasonable on its own; together they define a blast radius nobody planned for and nobody can see until something forces a look.
- Unwinding an over-broad permission later means combing logs and tracing call sites to figure out who depends on it, which is closer to archaeology than engineering. The dependency pattern typically has a few obvious major consumers plus a long tail of small, incidental uses, each grabbing slightly more than needed, none loud enough to notice alone.
- The fix is a checkpoint that happens before any code exists: name the principal, name the resource, name the narrowest verb, three lines written down first. If those lines come easily, the resulting code gets tighter for free. If they don't, that difficulty is the actual finding, and it is far cheaper to hit on day one than after a rollback.
Bottom Line: Permissions debt is what happens when nobody owns the question of who needs what before the code gets written; naming that owner upstream costs seconds, skipping it costs weeks.
