Permissions matter more than prompts
A prompt expresses intent. A permission decides what is possible. Only one of them holds when the model is wrong.
The difference is enforceability
An instruction telling a system not to contact customers directly is a statement about intent. It changes the probability of an action. A credential that cannot send external mail is a statement about capability. It changes the set of possible actions.
Both are useful. Only the second survives the case where the model is confused, the input is adversarial, or an upgrade changes behaviour in ways nobody anticipated. A probability, however favourable, is not a boundary.
This is not an argument against careful instruction. It is an argument about which layer carries the guarantee. Instructions should describe how to do the work well. Permissions should describe what the work is allowed to touch. Asking instructions to do both puts the guarantee in the layer least able to hold it.
Permissions resolved to a list, not a role
A permission expressed as a role name is not yet a permission. Roles drift: they accumulate access over time as people request additions, and the accumulated set is rarely reviewed against what any particular automated workflow actually needs.
The more useful form resolves to a specific enumeration at the point of use — these tools, these fields, this scope of write, for this operation. A run that requests something outside the enumeration should fail closed and surface, rather than degrading to a smaller action that happens to be permitted. Silent degradation is how a system ends up doing something nobody asked for while remaining technically within its rights.
The revocation test
There is a simple check for whether a control is real. Can it be withdrawn, by a named person, without redeploying anything?
If the answer is yes, the control lives in the architecture. If the answer is that someone would have to edit an instruction and hope, the control lives in the prompt, and it is not a control — it is a preference expressed to a system that may or may not act on it.
The same test explains why permissions belong in the contract rather than in the implementation. A boundary that requires an engineer to change is a boundary owned by engineering. Operational authority should be revocable by the person accountable for the operation.