A public library system lets branch staff use Claude Code against the catalog-integration repository. Policy states that the production ILS deploy command must never be executed from an assistant session, no matter how the request is phrased or how reasonable the model's justification appears. The architect wants a control that refuses the command outright rather than surfacing a prompt a tired staffer might approve. What should be configured?

The difference between a control and a suggestion is who enforces it. Permission rules are evaluated by the harness before a tool call runs, entirely outside the model's reasoning, and that is what lets a library system state a prohibition no phrasing or plausible-sounding justification can negotiate around.

deny is the strongest rule type, because a matching tool call is blocked outright rather than surfaced as a prompt, and deny takes precedence over allow so nothing else in the configuration can quietly re-enable it. Putting the rule in the project's settings.json also checks it into version control, so every branch's checkout inherits the same prohibition with no per-machine setup and no drift between staff laptops.

An instruction in CLAUDE.md is context the model weighs against everything else in a long session, so it raises probability without guaranteeing anything at the moment the call is made; an ask rule preserves exactly the prompt the architect wanted eliminated and makes safety depend on a human declining correctly every single time; and deleting the command from documentation changes nothing about what the shell can execute, because obscurity is not a permission boundary.

Exam caveat: a deny rule blocks what its pattern matches, so the same operation spelled differently through a wrapper script, an alias, or another path can slip past a narrowly written pattern. Operational check: attempt the deploy through the literal command and through one plausible wrapper or alias, and confirm both are refused before calling the control complete.