CyberFreezeDev
Loading
Checks around an AI model that stop bad inputs, bad outputs and unsafe actions.
Some guardrails are plain code, like permission checks and caps; others are classifiers or a second model. They enforce what a model cannot be trusted with.
Guardrails are the controls around an AI system that enforce rules the model alone cannot be trusted to follow. Some are plain code (a regex for phone numbers, a permission check, a cap on refund amounts). Some are classifiers or a second model that labels text as off-topic, unsafe or containing personal data. Open-source options include NVIDIA NeMo Guardrails, Guardrails AI and Meta's Llama Guard models.
They are one part of wider AI governance: the policies, records and reviews that decide what the rules should be.
Before the model sees a message: catch prompt injection, mask personal data, refuse off-topic requests.
Before the model sees a message: detect prompt injection attempts, strip or mask personal data, refuse off-topic requests.
Before a tool runs: confirm permissions, check limits, require approval for irreversible steps.
Before a tool runs: confirm the user's permissions, check limits, require approval for irreversible actions.
Before a reply leaves: validate format, block personal data or banned claims, verify sources.
Before a reply goes out: validate format, block personal data or banned claims, verify that cited sources exist.
On failure: retry, send a safe reply or route to a person, and log it.
When a check fails: retry, return a safe reply or route to a person, and log what happened.
Keeping Aadhaar, PAN and health data out of prompts and logs supports privacy law.
Keeping Aadhaar, PAN and health data out of prompts and logs supports obligations under the DPDP Act 2023 in India and GDPR in the UK and EU.
Stops a sales bot promising discounts, delivery dates or outcomes it has no basis for.
Stopping a sales bot from promising discounts, delivery dates or medical outcomes it has no basis for.
An agent that writes to systems needs hard limits in code, not just the prompt.
An AI agent that can write to systems needs hard limits in code, not just in the prompt.
An insurance website assistant masks numbers, refuses unrelated topics, blocks promises of claim approval and routes specific claim questions to staff.
An insurance agency puts an assistant on its website. Guardrails around it: an input filter masks policy and phone numbers before anything is logged; a topic check turns away requests unrelated to insurance; an output check blocks any sentence that promises a claim will be approved; and any question about a specific claim is routed to a staff member with the chat attached. The model writes the answers, but the rules decide what can leave the building.
Prompt rules can be talked around. Put hard rules in code the model cannot override.
"Do not discuss pricing" in a system prompt can be talked around. Put hard rules in code that the model cannot override.
Silent refusals hide real demand. Log every block and review the log weekly.
A silent refusal frustrates users and hides real demand. Log every block and review the log weekly.
Keep a set of hostile, tricky inputs and rerun it after every change.
Keep a set of hostile and tricky inputs and run it after every change, alongside your normal evaluation.
No single check does. Defence comes in layers: treat retrieved text and tool output as data, keep permissions in code, limit what tools can do, and require approval for sensitive actions.
Rule-based checks add almost nothing. Model-based checks add a short extra call, so teams often run cheap checks on everything and expensive ones only on risky actions.
Last updated