Runtime guardrails versus putting the rules in the prompt — what is the actual difference?

The difference is where the rule lives relative to the thing it is constraining.

A rule in the prompt is text, in the same channel as everything else the model reads, evaluated by the same model that is producing the output. That has three consequences:

• It competes with other text. Later instructions, retrieved documents and user input all argue with it, and the model resolves the conflict by judgement rather than by precedence.
• It can be argued with. This is the whole basis of prompt injection.
• It is probabilistic. It usually holds, and there is no version of "usually" you can put in a compliance document.

A runtime layer is separate code that inspects input or output and makes a decision the model does not participate in. It is deterministic in the sense that matters: the same input produces the same verdict, and the model cannot talk it out of that.

So the honest framing is: prompt rules are guidance, and a runtime layer is a control. Systems that need to demonstrate anything need at least one of the second kind.

Where the runtime layer is insufficient, because it is sold as more complete than it is:

It sees text, not intent. Classifiers work on surface features. Paraphrase, indirection, and splitting a request across turns all reduce their effectiveness, and the arms race there is genuinely difficult.

It does not know your context. A filter cannot know that this particular account number is one your system should never emit. Business rules are yours to write and they are usually the ones that matter.

It has false positives, and they are expensive. Over-blocking makes a product feel broken in a way users cannot diagnose or route around. Getting the threshold right requires exactly the evaluation set most teams have not built.

Output filtering is late. By the time you are inspecting output, the model has already been steered. Blocking the answer does not undo an agent that has already taken an action.

One thing to insist on when evaluating any of these: ask to see the failure rate on your own data, in both directions.

Vendors quote detection rates on public benchmarks. What you need is how often it blocks something legitimate in your domain, because that number decides whether your users can work.

Run it in shadow mode first — logging its verdicts without acting on them — for a couple of weeks. That gives you both numbers for free and it is the only honest way to choose a threshold.

The architecture that actually holds up, and it is not either of the two things in the question: constrain what the system can do, not what it may say.

If the agent has no credential for the destructive operation, no prompt and no filter is load-bearing. If it can only write to a scratch area, an injected instruction to delete production fails at the permission layer, silently and completely.

So the ordering I would argue for:

1. Capability limits. Least privilege, per agent, enforced outside the model.
2. Runtime checks on input and output, for the categories a classifier is genuinely good at.
3. Prompt instructions, as the last layer and the one you assume can fail.

Most teams build these in exactly the reverse order, because the third is free and the first requires touching infrastructure.