Model refusal is not an enforcement boundary
Why a model declining one injected instruction is useful evidence, but not durable authorization or isolation.
Behaviour can change
A refusal is an observed model response under one provider version, prompt, context order, sampling configuration, and conversation history. Change any of those conditions and the result may change. That makes refusal valuable defence in depth, but a poor place to anchor authorization.
Move authority outside the model
The application should decide which data can be read and which actions can execute. Models can propose; deterministic code should validate identity, tenant, limits, destinations, consent, and approval requirements.
- Test several runs and preserve full inputs.
- Record model and configuration identifiers.
- Do not count refusal as a blocked application action unless execution was impossible.
- Re-run the same corpus after provider or prompt changes.
Use detection as evidence
An independent scan can identify and record an attempted instruction before inference or execution. It still needs calibration, monitoring, and a fallback, but it creates a control the application can enforce consistently rather than hoping the model chooses to refuse.