Guardrails are architecture, not politeness.
NVIDIA just open-sourced NeMo Guardrails. The bigger shift: control of LLM behaviour is moving out of the prompt and into a layer you can actually enforce.
🚧 Guardrails are architecture, not politeness.
This week NVIDIA open-sourced NeMo Guardrails — a toolkit that sits between the user and the language model, enforcing three kinds of limits: topical (stay on subject), safety (grounded, appropriate answers) and security (restrict what external systems the model may touch).
The tool is useful. The mental model it ships with is more useful, and worth spelling out for anyone taking LLMs into an enterprise:
Most teams' first instinct is to control the model by asking it nicely. The system prompt grows a list of commandments — do not discuss competitors, never give legal advice, refuse off-topic requests — and in the demo, it works. But a prompt is a request, honoured by a probabilistic system that a determined user (or a cleverly-worded document) can talk out of it. February's Bing episode showed exactly how far "never reveal this" goes. Politeness is not a control.
A guardrail, properly understood, is enforcement outside the model. A separate layer that inspects what goes in and what comes out, and applies rules the model cannot be sweet-talked around:
Input rails — catch injection patterns, off-topic requests and disallowed content before the model sees them
Output rails — check responses for policy violations, ungrounded claims and data that should not leave (PII masking lives here) before the user sees them
Topical rails — define what the application is for, and route everything else to a refusal or a human
Tool rails — whitelist which systems the model may call, with the model's permissions capped at the current user's permissions, never above
The pattern underneath all four is the same one security engineering has preached for decades: defence in depth, with the untrusted component sandboxed. Treat the LLM as brilliant but untrusted — the way you would treat any powerful dependency you did not write — and put the trust in layers you control deterministically.
There is also an organisational reading. When behaviour rules live in a prompt, they belong to whoever edits the prompt. When they live in a guardrail layer — versioned, testable, reviewable — they can belong to compliance, security and the business, in a form they can actually audit. That, more than any single blocked jailbreak, is what makes an LLM application governable: the rules become infrastructure, not vibes.
None of this makes an application bulletproof — this field is weeks old and the attacks will evolve faster than the toolkits. But the direction is now clear, and it is the right one: the prompt is where you shape behaviour; the architecture is where you guarantee it. Teams that internalise the difference will ship systems that survive contact with real users.
If you have an LLM pilot running, one review worth doing this month: list every rule currently written inside your system prompt, and mark which ones would cause real damage if ignored once. Every mark on that list is a rule that needs to move out of the prompt and into a layer that does not negotiate.
Last updated