Deny by default

The mechanism is short enough to state completely. Collect every permission on every role the caller holds. If any of them matches the resource and the action and its effect is deny, refuse immediately and record which role and which pattern decided it. Otherwise, if any matching permission allows, permit and record that one. Otherwise refuse, with a reason that says so in those words. Three properties fall out of that ordering, and each is worth more than it looks.

The first is that precedence does not depend on ordering. Because the deny path returns before any allow is settled on, a narrow guardrail wins whether it is written above the broad grant, below it, or inside the same role. That is what makes a subtractive guardrail a pattern an operator can rely on rather than a race: you can grant a whole tool namespace to a team and remove one action from one agent, without rewriting the broad grant or duplicating it into a narrower one. Under allow-wins semantics the same configuration is a coin toss decided by role iteration order, which is exactly the kind of thing that changes silently in a refactor.

The second is that absence is an answer. There is no implicit grant anywhere, so the empty cases are all safe: an agent with no roles can do nothing, a role someone created and never populated grants nothing, and a resource nobody thought about is refused. This is the property that keeps working when everything cleverer has failed, which is why deny by default is worth having before any policy engine, any anomaly detection and any classifier.

The third is that the failure mode is inverted deliberately, and that has a cost somebody has to pay. Deny by default produces breakage, and the breakage lands on whoever shipped the agent. That is the point — under-privilege arrives as a ticket an engineer raises, while over-privilege arrives as an incident eighteen months later that nobody files at all — but it only holds if refusals are legible. A refusal has to name the role and the pattern that produced it. When it does not, the engineer debugging a failing agent widens the broadest grant they can find until the error stops, and the model has been defeated by its own error messages.

It helps to be precise about what deny by default is not. It is not least privilege: a system can deny by default and still hand out a wildcard permission that allows everything, and in most estates that grant exists somewhere. It is not zero trust, which is a network and authentication posture rather than an authorisation default. It is not argument-aware — a rule such as refunds above a threshold need a human is a policy, because a permission model knows the tool and not the amount. And it says nothing about time: a grant stands until someone edits the role, so deny by default without periodic review is a snapshot of intentions from whenever the roles were last written.

The recurring ways it is defeated are worth listing because they are all local decisions that look reasonable. A wildcard grant issued to unblock a launch and never narrowed. Roles scoped to a team rather than to an agent, so every agent on the team holds the union of what the team needs. A deny list used as though it were an allowlist, which only covers the resources someone had already thought of. And a filtered catalogue mistaken for enforcement: hiding a tool from the list an agent is shown is a usability feature, and the authorisation decision still has to be taken when the call arrives.