Deterministic guardrails for AI agents
An agent that calls tools needs checks that decide the same way every time. This guide covers what makes a guardrail deterministic, where it fits next to model-based guardrails, and the one mistake to avoid: treating a repeatable check as a correct one.
The short answer
A deterministic guardrail decides with a rule, a parser or a solver, so the same input against the same policy always gets the same decision. Use deterministic guardrails for what can be stated exactly (allowed tools, argument ranges, SQL, code, totals) and model-based guardrails for judgements such as tone or toxicity.
Two kinds of guardrail
| Question | Model-based | Deterministic |
|---|---|---|
| How it decides | A classifier, a safety model or an LLM judge returns a label or a score | A rule, a schema, a parser or a solver returns the same decision for the same input |
| Good at | Tone, toxicity, off-topic replies, jailbreak and prompt-injection attempts: properties with no formal answer | Allowed tools, argument types and ranges, SQL and code shape, money totals, state changes |
| Weak at | Repeatable decisions: the same input can score differently with a new model or prompt | Anything that cannot be written as a rule or a formal statement |
| Examples | Safety models in NeMo Guardrails, ML validators in Guardrails AI, PromptGuard 2 in LlamaFirewall, the OpenAI Moderation API | JSON Schema checks, allowlists, policy files, SQL parsing, AST rules, SMT solvers |
Most guardrail libraries mix both. NeMo Guardrails, for example, validates tool calls against a JSON Schema with no model in one engine and runs safety models in others. What matters is knowing which kind made each decision. How the main tools work, checked 15 October 2026
Where deterministic guardrails fit for agents
Agents act through tool calls, so most of what an agent does can be checked before it runs:
| What the agent produces | The question | Checked with |
|---|---|---|
| A tool call | Is this tool allowed? Are the arguments the right type and in range? | Allowlist and argument schema |
| A query the model wrote | Does it change data, read a blocked column or carry an always-true filter? | SQL parser |
| Code the model wrote | Does it call eval, a shell or the network? | AST rules |
| A total or a rate | Does the figure equal what the inputs give? | Recompute with exact arithmetic |
| A workflow step | Is this a valid next state from the current one? | State machine |
| Structured output | Are the required fields there, with the right types? | JSON Schema |
These checks need no second model call, and a denied call comes back with the reason, so the agent can try again within the rules instead of failing outright. Checking AI-generated SQL
Deterministic is not the same as correct
A regular expression is deterministic: it always gives the same answer. It can still be wrong, and an attacker who knows the pattern can write around it. Repeatable and sound are different properties.
- Pattern scans are repeatable but heuristic. They catch known shapes and miss new ones.
- Parsers and schemas check structure exactly, but only the structure.
- Solvers and exact arithmetic prove a stated property, such as a total, a constraint or an identity, for the statement they were given.
QWED keeps these apart in its results: only a proof engine can return VERIFIED, while policy guards return block or hold decisions and never VERIFIED. Even proof engines have had bugs, and they are published. Track record
When the check itself fails
A guardrail can time out, crash or receive input it cannot read. What happens then matters as much as the check. Some libraries let the content through when a check errors; QWED denies it. Fail-closed, explained
What QWED provides
- Proof engines for maths, logic, SQL, code and JSON Schema, which return
VERIFIEDonly with a proof reference. Engines - Policy guards in the core SDK: SystemGuard, ConfigGuard, RAGGuard, MCPPoisonGuard, ExfiltrationGuard, SelfInitiatedCoTGuard, SovereigntyGuard, StartupHookGuard, ProcessVerifier.
- Tool-call guards in QWED Open Responses: tool allowlists, argument types and ranges, recomputed totals, schemas and allowed state changes. Its pattern scanning is a heuristic, and it is not a sandbox.
- A decision record for every check. Audit trails for AI decisions
QWED returns the decision; your agent framework or gateway enforces it.
What QWED does not do
- Content safety. QWED does not classify toxicity, topics, jailbreaks or prompt-injection attempts. Use a model-based guardrail for those, next to QWED.
- Intent. A tool call that follows every rule can still be the wrong thing to do.
- Sandboxing. A guard decides whether a call should run. Isolating what runs is a job for the runtime.