Guardrails belong in the tool plane, not the prompt
Most AI safety writing concerns what a model says. In prior authorization the interesting question is what a system does: what reaches a payer, what reaches a patient's chart, what leaves one practice and arrives at another. Those are not language problems, and they cannot be solved with language.
#The distinction that matters
There is a real difference between instructing a model not to do something and making it unable to. An instruction is probabilistic: it holds most of the time, degrades under unusual input, and can be argued with by anything the model reads. An enforced constraint is deterministic: it holds because the code path does not exist.
In a domain where being wrong means a patient's procedure is delayed or the wrong practice's chart is read, probabilistic is the wrong category of guarantee.
| Constraint | In a prompt | At the tool boundary |
|---|---|---|
| Only this practice's data | A sentence the model may follow | The query is scoped by the caller's identity and cannot be widened |
| No patient identifiers in this output | An instruction | Masking applied by field name after the call returns |
| A human must release this | An instruction | The transmission path requires a release token that only a human can create |
| Stay inside a spend limit | An instruction | A counter that refuses the next call |
#What an ordered check sequence looks like
Every capability an agent can invoke passes the same sequence, in the same order, server-side, before anything executes. Order matters: each step assumes the previous one held.
- Is this a registered capability at all. An unregistered helper is unreachable by construction.
- Is the caller bound to a practice, and is that practice active.
- Does the caller hold the permission this capability requires.
- Does the current autonomy level permit this capability.
- Is the caller inside its budget.
- Does this action require a human release, and is a valid one present.
- Execute.
- Record it, with the purpose of use.
#Why this shape and not another
The alternative pattern, common in agent frameworks, is a capable agent with broad access and careful instructions. It is faster to build and it fails in a specific way: every new prompt, every new model version and every unexpected input is a fresh opportunity for the instruction not to hold.
Putting the constraint in the tool plane costs more up front. It buys a property worth having: the safety behaviour does not depend on the model at all. Swap the model and the guarantees are unchanged, because they were never the model's to provide.