Why a prompt is not a control
Every serious vendor ships a way to tell a model to answer only from your documents. Microsoft documents theirs plainly: with the setting enabled, the model attempts to only rely on your documents for responses. Read that sentence as an engineer rather than as a buyer. It is a description of an intention, not of an enforcement — and it is honest, which is more than most such features get.
An instruction competes with everything else in the context window: the user's phrasing, the retrieved material, the model's own priors, and whatever the previous eleven turns established. It usually wins. Usually is a strange word to find at the centre of a compliance story.
Where the refusal lives here
The agent can only open a document by naming a path, and the tool that opens paths will only open ones that appeared in a listing it was given. Ask for something else and the call fails. Not "the model declines" — the call fails, before any content is produced, in code that has no opinion and no context window.
This is why refusal is a feature rather than a failure here. The system can return "declined" as a first-class outcome with a reason attached, and your application can route that to a human on a field rather than by pattern-matching apologetic prose.
What it does not protect against
It does not stop a model misreading a document it legitimately opened, and it does not make the library correct. If a page in your library says something wrong, an agent that faithfully cites that page will tell your customer something wrong, with a citation. That is what the evaluation suite and the guards are for, and it is why they are separate mechanisms rather than one.