Necessary authority is Allen’s inside-out of Miller’s Principle of Least Authority (2023). Where least authority asks “what transitive authority should we limit?”, necessary authority asks “what authority does the user genuinely need to accomplish their work — including the transitive authority that flows through the tools and systems they must use?”
Least authority sets a ceiling: no entity should hold more authority than required. Necessary authority sets a floor: no entity should be denied authority it legitimately needs. Without the floor, least-authority analysis produces systems that are technically minimal but operationally hostile. Users who lack necessary authority develop workarounds — sharing credentials, escalating through informal channels, accumulating ad-hoc permissions that are never revoked. The workarounds are worse than the authority they replace, because they are invisible to the security model.
This is not a failure of least authority as a principle. It is a failure to ask the complementary question. A system that satisfies least authority but violates necessary authority has not achieved security — it has achieved friction. Friction that users route around.
Miller’s contribution was recognizing that authority is transitive. Necessary authority inherits this scope. A user who needs to accomplish a task that requires invoking a service that accesses a database needs authority over that entire chain — not just the first link. Denying any link in a necessary chain does not remove the need; it forces the user to find another path, often one that is less auditable and less secure.
Necessary authority occupies the middle column of Allen’s enabling row, paired with Principle of Least Authority in the restrictive row. The two patterns together define the authority corridor — the range between “more than needed” (violation of least authority) and “less than needed” (violation of necessary authority). Good design lives inside that corridor.