Guardrails: four interventions, five layers

The syllabus asks for a multi-intervention guardrail strategy, and the word
multi-intervention is doing the work. A guardrail at one point is a filter.
Guardrails at four points are a strategy, because each catches what the others
structurally cannot.

The four points

User inputs. Jailbreak attempts, prohibited requests, use outside the agent's
scope. This is the one everybody builds.

Tool calls. The agent trying to do something it should not — checked before it
happens.

Tool responses. Content coming back from something the agent called.

Outputs. Harmful content, leaked data, unsupported claims, wrong format.

Check what comes in, check what it tries to do, check what comes back from what it
did, and check what it says. Four gates on one journey.

The one people miss is tool responses

Input filtering assumes the attack arrives from the user typing something hostile.

For agents that assumption is usually wrong. The injection arrives inside a
document the agent retrieved, an issue body it read, a web page it fetched, an API
response it requested. Content the agent retrieved is untrusted content — and
it enters the context after your input filter has already run and passed.

That is not an edge case. It is the primary attack path against a system whose
whole job is going and getting things.

And the highest-value gate is tool calls

Of the four, tool calls is where the leverage is, because it sits between
intention and effect.

An agent that has been talked into wanting something harmful is contained if it
cannot execute it. The persuasion succeeded; the damage did not. Which is the whole
argument for constraining tools rather than instructions, arriving here as a
concrete control point.

The layers, weakest to strongest

Microsoft is unusually candid about the weak end:

"Defensive prompts… lower the success rate of known attacks; they don't make the
next attack impossible. Sanitization is lossy and has to be re-tuned as
adversaries adapt. Pre/post-hoc monitoring detects damage; it doesn't prevent
it."

So, in order:

Defensive prompt. Cheap, helps, never sufficient.

Content filters. Foundry's built-in safety classifiers on input and output.

Custom guardrails. Your domain rules — the ones with consequences. Never quote a
price outside the approved list. Never give advice a regulator classifies as advice.
Never confirm identity on fewer than two factors.

Tool restriction. The agent has no tool that can do the damage. Structural, and
it does not care how persuasive the attacker was.

Information-flow control. FIDES — deterministic, label-based, enforced before
the tool runs. Currently experimental and Python-only, but the strongest form.

What separates a guardrail from a wish

Three properties.

Enforced outside the model. If the model ignoring it causes harm, it needs a
mechanism, not a sentence.

Fails closed. When the guardrail cannot evaluate — the checking service is down,
the input is malformed — the safe default is refuse, not proceed.

Legible when triggered. The user needs to know they hit a boundary rather than a
bug, and the system needs it logged as a guardrail event so you can count them.

That last one has an operational payoff: guardrail trigger rate is a monitored
signal. A sudden rise is either an attack or a change that broke something
legitimate, and you want to know which within the hour.

The trap

An expert-level question will offer you a prompt-level answer and a structural one,
and the structural one wins.

But the genuinely best answer usually layers rather than choosing — because each
layer fails differently, and the value of the stack is that no single failure is
total.