---
title: "Deterministic guardrails for AI agents"
description: "What makes a guardrail deterministic, how it differs from a model-based guardrail, where each one fits for AI agents and tool calls, and why deterministic is not the same as correct."
url: https://qwedai.com/guides/deterministic-guardrails
---

# 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](https://qwedai.com/compare)

## 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](https://qwedai.com/guides/ai-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](https://qwedai.com/security#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](https://qwedai.com/guides/fail-closed)

## What QWED provides

-   **Proof engines** for maths, logic, SQL, code and JSON Schema, which return `VERIFIED` only with a proof reference. [Engines](https://qwedai.com/engines)
-   **Policy guards** in the core SDK: SystemGuard, ConfigGuard, RAGGuard, MCPPoisonGuard, ExfiltrationGuard, SelfInitiatedCoTGuard, SovereigntyGuard, StartupHookGuard, ProcessVerifier.
-   **Tool-call guards** in [QWED Open Responses](https://qwedai.com/platform/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](https://qwedai.com/guides/ai-audit-trail)

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.

[Everything QWED does not verify](https://qwedai.com/limits)