Glossary
Guardrails
Technical boundaries around a language model that define what may go in, what may come out, and what it can trigger.
Guardrails are not a single product but a collection of boundaries in four places: in front of the model, inside the model, behind the model and at the tools. The most effective ones do not sit inside the model but around it.
In front of the model you filter what goes in: mask personal data, limit file types and sizes, reject obvious attack patterns. Behind it you check what comes out: format validation, confidence thresholds, block lists for content that must never appear.
The hardest and at the same time simplest boundary is the permission set of the connected tools. A model that has no delete rights deletes nothing even under attack. This boundary is the only one that does not rest on checking text, and therefore the only one that holds reliably.
A guardrail that is often missing is the fallback path. What happens when a check fires? A system that then simply does nothing is arguably worse than one that escalates: the case disappears instead of reaching a human. Every boundary needs a defined exit.
Guardrails cost quality, and that is the honest part. Filters set too tightly block legitimate cases, format rules set too strictly force unsuitable answers. The setting is a trade-off, not an optimization, and it belongs measured like every other change to the system.
The standard mistake is building guardrails as a prompt. "Never answer questions about pricing" is a request, not a boundary. Security relevant decisions belong in code, in permissions and in checks, not in a text that another text can override.
How you notice it
- Security requirements are written as sentences in the system prompt.
- There is no schema check for structured answers.
- When a check fires, nothing further happens.
- Nobody knows how often which boundary fires.
Not to be confused with
- System prompt
- Steers behaviour and tone, but is not a boundary. It can be influenced by content in the context and does not serve as a security measure.
- Human in the loop
- A person as a review step. The strongest guardrail for consequential actions and the most expensive one, which is why it is used selectively.
- Evaluation
- Measures quality over time. Guardrails act on the individual case at runtime. Both together: the evaluation shows whether the guardrails are set too tight or too loose.
When it fits
- The system is reachable from outside or processes foreign content.
- Connected tools can change, send or delete data.
- The answers have legal or financial effect.
When it does not
- As a substitute for a permission model. A filter meant to compensate for a missing permission does not hold.
- In early exploration with internal users and without writing tools: there they slow down the learning.
How to approach it
- Permissions firstWhat can each tool do in the worst case, and can that be narrowed. This question buys more safety than any text check.
- Limit the inputFix sizes, formats and sources, mask personal data before the model sees it. What was never in the context cannot leak.
- Validate the outputCheck structured answers against a schema, not against a gut feeling. What does not validate is discarded or escalated instead of being processed further.
- Default to refusingWhen in doubt, better not to act. False positives cost trust, missed ones cost little, and the threshold can be lowered later.
- Define the fallback pathEvery boundary that fires needs a destination: a queue, a person, a ticket. A case that quietly disappears is the worst possible exit.
- Measure the effectHow often does which boundary fire, and how many of those were legitimate cases. Without that number nobody knows whether the guardrails protect or obstruct.
Frequently asked
Are the guardrails of the provider enough?
They cover general content risks but do not know your domain. What must not be said or must not be triggered in your context is known only to your system. Provider guardrails are a foundation, not a complete solution.
How strictly should guardrails be set?
Strict at the start, defaulting to refusal, and then loosened on the basis of measurement. False positives cost trust, missed ones usually cost only one extra case. What matters is that rejected cases land somewhere visible.
Where do guardrails belong, in the prompt or in the code?
Behaviour and tone in the prompt, security and correctness in the code. Everything that somebody might want to circumvent belongs in permissions, validation and checks outside the model. A prompt can be influenced by text in the context, a permission model cannot.