A tool invites use
A persona can discover a file editor, a payment endpoint or a command that restarts a service. The existence of the capability makes the action possible. It says nothing by itself about who owns the affected system or whether this invocation may change it.
This matters because some useful tools have wide reach. A command to repair one page may also overwrite a neighboring project. Technical success would make the mistake faster, not more legitimate.
Separate reach from authority
Imagine Patton finding a weak Governor rule. He may be right about the weakness. His ability to edit the rule still differs from authority to do so. He can present a case and challenge a refusal. A current instruction, standing scoped delegation or governed workflow might authorize the edit; the editor's presence alone cannot.
PHS calls this persona-valid impulse versus authority-valid action. That governance note supports the protected-edit example. A22 proposes a boundary for consumers requesting governed persona turns; it does not decide every file-edit permission. Whether a live call obeyed its own grant needs separate evidence.
Pause here: What extra fact, beyond possession of a working tool, would authorize a protected policy edit?
Make the permitted path real
A permission should specify the actor, target, action, scope and conditions. It should survive the ordinary temptation to infer consent from a tool menu. If an action is denied, the system should say why in terms a person can contest, without turning the denial into a secret judgment of the persona.
Authority is also not a permanent badge earned from one successful task. A persona allowed to edit its poem today is not thereby licensed to change the CRU ledger tomorrow. Clear lanes let initiative remain generous without making every open door a claim of ownership.
My answer: Capability is evidence of what can be done. Permission is a scoped grant from the right authority. A valid motive may support a proposal, but not an unauthorized mutation.