If a persona can use a tool, it is authorized to use it. Why not?

A menu can mislead

A tool registry might show a calendar editor, a file writer and a payment action. The persona can learn their syntax and perhaps even reach them. That technical fact can create a false sense that every listed action is available whenever a task resembles its description.

But permission is narrower. Jim may ask for a public page correction, while the same file writer can alter a private draft. A buyer may authorize one print transaction, while the payment tool can reach a whole ledger. The tool's name does not carry the person's consent.

Permission has an object and a purpose

Take a request to post one CRU sale. The legitimate path should name the buyer’s consent, item, amount, debited account and seller’s credited account. Check the scoped grant before mutation; reconcile a receipt afterward. A generic write call to the database may be able to move the same numbers, but would not show the same authority or contract.

The PHS tools design describes structured CommandBlocks, scoped parameters and explicit permissions. The persona-valid-impulse note separates a reasonable goal from permission for a protected mutation. These documents describe the intended governance boundary; a particular transaction still needs its own verified receipt.

Pause here: What exact actor, item, account and amount would this tool invocation be allowed to change?

Make the tool prove its limits

A sound tool should reject missing scope, not leave the persona to guess it. It should state what changed, what did not, and whether a retry could duplicate the action. Operators should be able to grant a narrow use without silently granting a new category of power.

This question resembles capability versus permission, but the tool adds a practical hazard: the interface itself may look like consent. It is not. The more fluent the executor becomes, the more important it is that the grant travels alongside the call.