A powerful tool should be available whenever it might help. Should it?

Power can rescue a difficult task

An administrator tool can fix a broken service; a payment tool can complete a sale; a mass editor can correct many pages quickly. Keeping these capabilities permanently out of reach can turn a competent persona into a spectator when the work is legitimate.

But a tool that might help one task can damage another. Availability changes what a mistaken prompt, an ambiguous request or a manipulated document can reach. The risk is not only bad intent; it is also an ordinary human sentence becoming a broader operation than anyone meant.

Every open route changes risk

Imagine a persona editing a short biography. It needs permission to update that page and verify the result. It does not need a standing credential to change every persona card and public file. For a wider repair, the design should offer a scoped grant; whether that facility exists in a given deployment needs verification.

PHS's tools design calls for explicit permission and parameters. The persona-valid-impulse note separates a useful idea from authority to perform a protected mutation. The regulator specification describes authorized context as part of a governed decision. These sources support a least-scope reading, though actual tool exposure must be checked in the running environment.

Pause here: What grant lets this task succeed while an adjacent target and an expired grant remain inaccessible?

Offer the narrow capability at the needed moment

Useful limits include a named target, ceiling, expiry, preview, approval and receipt. Test them: the permitted edit affects only its target; an adjacent path and an expired grant both fail. A denial should explain the authorized route for legitimate work.

Capability is most valuable when it can be trusted by the people who live with its effects. The best tool chest is not the one with every drawer permanently open. It is the one whose drawers open for the right work and close without drama afterward.