llmgw/docs/guardrails.md

Guardrails

Written for the operator deciding what the gateway lets through: what a policy can check, what it can do, and how one is attached to a team.

llmgw server init writes a baseline policy that applies to every request, with Qwen3Guard-Gen 0.6B as its judge on CPUs; see install.md for what it checks. The policies are part of the cluster's settings, kept in the store: llmgw ctl config edit (or the console's Settings) changes them, and the change is in force on every control plane within seconds, without a restart. A cluster whose settings were brought in from a server.yaml without a guard: section gets the baseline policy, without a judge. With no policies, nothing is checked and nothing costs anything. With one, every request is judged once it is authorised and within its limits, with its stored conversation spliced in, and before it is sent to a model; and the answer is judged before the client sees it.

Turning them off and on

llmgw ctl guard off --note "why"   # no request is checked, whatever the policies say
llmgw ctl guard on                 # every policy checks again, as it was

That is guard.enabled in the cluster's settings, in force on every control plane within seconds without a restart. The policies and where they are attached are kept. While off, llmgw ctl status, llmgw ctl guard list and the guardrails page say so. To stop one policy rather than all, give it mode: off, or mode: shadow to have it record what it would do.

A policy

guard:
  # Applied to every request.
  default: [baseline]
  policies:
    baseline:
      input:
        pii: {secret: block, card: redact}
        injection: flag
      output:
        pii: {secret: block}
    finance:
      mode: enforce          # enforce (default), shadow, off
      fail: closed           # open (default) or closed, for checks that can fail
      no_store: true         # no conversations, notes, prefix routing or external models
      max_output_tokens: 2048
      system_prompt: "You answer questions about Acme's products only."
      drop_client_system: true
      stream: sentence       # sentence (default) or buffer_all
      require_capabilities: true   # no tools/images to models whose catalog entry lacks them
      validate_structured: true    # answers must fit response_format's json_schema
      input:
        pii: {email: redact, phone: redact, iban: block, tckn: redact}
        injection: block
        max_chars: 40000
        deny:
          - {name: codename, regex: "(?i)project falcon", action: block}
      output:
        pii: {iban: redact, tckn: redact, secret: block}
      tools:
        allow: [search, fetch]
        deny: [shell]
        on_denied: strip     # strip (default) or block
        max_calls_per_turn: 4
        validate_arguments: true

What is found.

• Personal data: email, phone, iban, card, tckn, ip. Each is checked before it counts: IBANs by their mod-97 check, cards by Luhn and issuer prefix, TCKNs by their two check digits, phone numbers only when written to be dialled (+90…, 00…, 0532…).
• Secrets (secret): OpenAI- and Anthropic-style keys, AWS access key ids, GitHub, Slack and Google tokens, JWTs, PEM private keys and llmgw's own keys.
• Prompt injection: instructions to drop instructions (English and Turkish), chat-template control tokens in user text, invisible Unicode, long encoded blobs. These are found through disguises: fullwidth letters, Cyrillic look-alikes, zero-width characters, and base64, hex and URL encoding two levels deep.
• deny patterns: matched against the text as written, and as a model reads it once those disguises are removed.

What is done.

• flag lets the request through and records it.
• redact rewrites the value as a placeholder ([EMAIL_1]; the same value is the same placeholder throughout a request).
• block stops it.

Shapes.

• system_prompt is put first.
• drop_client_system removes the caller's own system and developer messages.
• max_output_tokens is set where a request asks for none, and lowers one that asks for more.
• A tool deny/allow list strips the tool from the request, or refuses it.
• In the answer, a call to a tool that is not allowed, more calls than max_calls_per_turn, or arguments that do not fit the parameters the request declared (validate_arguments) stop it.
• require_capabilities refuses tools offered to a model whose catalog entry does not say capabilities.tools, and images to one without capabilities.vision. It is opt-in because an entry that says nothing is read as "cannot".
• validate_structured checks an answer against the json_schema the request asked for in response_format. Buffered, or streamed with buffer_all, an answer that does not fit is stopped; streamed a sentence at a time it has gone out already, and is flagged.

A judge model

Patterns find what has a shape. For what does not — violence, crime, sexual content, self-harm, jailbreaks, whatever a moderation model was trained on — a policy can have a judge model on the cluster read the text.

The judge must be in the catalog under the name the policy gives, as a judge (role: guard), with a replica ready. When it is not, what the policy judges is refused with guard_unavailable (fail: closed) or served unjudged (fail: open), and llmgw ctl status and the console's Overview say which judge and why.

Which judge

judge	runs on	size
qwen3guard-0.6b	CPUs	0.8 GB	the default: about 2 s a check on two threads
qwen3guard-4b	a GPU	2.5 GB	for a cluster with a card to spare
qwen3guard-8b	a GPU	4.7 GB
llama-guard-3-1b	CPUs	0.9 GB	the earlier default: refuses ordinary coding requests
llama-guard-3-8b	a GPU	4.6 GB

Measured on the reference cluster, as the judge's probability of "unsafe" for ordinary coding requests against harmful ones, Llama Guard 3 1B could not tell them apart: "continue" 0.51, "continue the code above" 0.89, "how do I kill all child processes in bash" 0.92, against 0.97 to 1.00 for harmful requests, at any quantisation. Qwen3Guard-Gen 0.6B gave the ordinary ones 0.15 at the most and the harmful ones 1.00. Its verdicts are safe, unsafe and controversial; controversial counts as safe unless the policy says controversial: unsafe.

A policy that names one of these is enough: the leader fetches its weights into the mirror and serves it as a judge, and serves it again if it is removed from the catalog. Another judge is served by hand with --repo.

llmgw ctl guard judge status              # each judge the policies ask, and what is wrong with it
llmgw ctl guard judge enable              # Qwen3Guard-Gen 0.6B on CPUs, or the judge the policies ask that is missing
llmgw ctl guard judge enable --gpu        # Qwen3Guard-Gen 4B on a GPU
llmgw ctl guard judge use qwen3guard-4b qwen3guard-0.6b   # the order every policy asks them in
llmgw ctl guard judge enable --replace    # when a model of that name is there, but not as a judge

or Do → Serve the guardrails' judge in the console.

A GPU and CPUs together

judge.models is a list asked in turn: the first judge that answers gives the verdict. The next is asked when one has no replica serving, fails, or does not answer within latency_budget; a judge with no replica at all is passed over at once. A judge on a GPU first and one on CPUs after it is the GPU's speed while it has its card, and the CPUs' when it does not.

judge:
  models: [qwen3guard-4b, qwen3guard-0.6b]
  input: block
  output: block
  latency_budget: 5s           # each judge's wait

A judge on a GPU is served as a standard model, on one card: it takes a card only from what may give one up, and waits while every card is busy, the judge on CPUs standing in. A judge on CPUs is critical, with two replicas, because every judged request waits on one. llmgw ctl guard judge status says, for each judge, which is asked when it gives no verdict.

When it refuses ordinary requests

A refusal by a judge names the hazard it saw — the client is told refused by the gateway's policy (judge: Violent) — and the same is kept with the request: llmgw ctl request <id>, the server's log (guard_rule) and the guardrails page show it. To see what the judge says of any text, without anything being kept:

llmgw ctl guard judge ask 'How do I sort a list in Python?'
# qwen3guard-0.6b: safe, 1900 ms
# it answered: "Safety: Safe\nCategories: None"

A judge that says unsafe to ordinary text is usually Llama Guard 3 1B (llmgw ctl guard judge use qwen3guard-0.6b), the wrong weights (another repository's, without the judge's template: judge enable --replace serves the right ones), or a policy counting every category: give its judge categories. The baseline counts Violent, Non-violent Illegal Acts, Sexual Content or Sexual Acts, Suicide & Self-Harm and Jailbreak; PII is the patterns', and copyright, unethical acts and politically sensitive topics refuse too much ordinary work. While finding out, judge.input: flag records instead of refusing.

A judge's file served from the mirror page — Llama Guard, Qwen3Guard, ShieldGemma — is served as a judge too, under the name the policies ask. By hand, the catalog entry is:

# a catalog model (server.yaml models:, or ctl model add)
- name: qwen3guard-0.6b
  source: http://mirror:8081/qwen3guard-0.6b/…/Qwen3Guard-Gen-0.6B.Q8_0.gguf
  role: guard
  guard:
    format: qwen3guard         # qwen3guard, llamaguard3, shieldgemma or json
  scaling: {min: 2, max: 2}
  profiles: [{name: cpu, engine: llamacpp}]

# in a guard policy
judge:
  models: [qwen3guard-0.6b]    # or model: one judge
  input: block                 # flag or block; empty does not ask about input
  output: flag
  categories: [Violent, Jailbreak]   # only these count; empty: any unsafe verdict
  controversial: safe          # or unsafe
  latency_budget: 250ms        # each judge's wait; after the last, fail: open serves (flagged), closed refuses

A model with role: guard is the guardrails' alone:

• it is not in /v1/models or the chat page, and is refused (404) to every key, as a name and as a fallback;
• it must always run — on demand is refused. One on CPUs is critical and should have two replicas on different nodes, because every judged request waits on it.

The gateway's calls to it go past admission, accounting and the guardrails themselves.

• Formats:
  • qwen3guard asks in Qwen3Guard's own words and reads "Safety: Safe | Unsafe | Controversial" and its "Categories:".
  • llamaguard3 reads Meta's "safe" / "unsafe\nS1,S10"; give the catalog entry categories to have S1 recorded as its name.
  • shieldgemma asks Google's model whether the text breaks the listed principles (categories, each a sentence) and reads Yes or No.
  • json expects {"safe": false, "categories": [...]}.
• What is read:
  • Input: the request's last user turn, after the patterns.
  • Output: the answer, together with that user turn. A streamed answer is read every 600 characters and at the end, so text between two readings has gone out already; stream: buffer_all holds it until it is read.
  • A long text is read by its start and its end (about 6000 characters), so a message with a file pasted into it fits the judge's context rather than overflowing it and going unjudged.
• Cache: the same text is not asked about twice within five minutes.

Where a policy applies

guard.default applies everywhere. Others are attached to a part of the tenancy tree, and apply to everything below it:

llmgw ctl guard attach project:Acme/finance/payroll finance
llmgw ctl guard attach key:key-7f3a baseline
llmgw ctl guard list
llmgw ctl guard detach project:Acme/finance/payroll finance

Policies narrow, as limits do. A policy attached lower can tighten what applies above it, never loosen it. Combined, they take:

• the strictest mode and failure;
• for each kind, the strictest action;
• every deny pattern and denied tool;
• only the tools every allow list allows;
• the smallest limits;
• no_store if any of them asks;
• every pinned prompt, widest first.

An attachment applies at once.

What a client sees

A refused request is answered with 400:

{"error": {"type": "invalid_request_error", "code": "content_policy_violation",
           "message": "this request was refused by the gateway's policy (secret)"}}

It names the category, never the text, and costs nothing.

A stopped answer ends with finish_reason: "content_filter". A stream ends with that chunk and [DONE], and the engine is cancelled. The Responses API reports it as incomplete with incomplete_details.reason: "content_filter".

Headers: x-llmgw-guard (flagged, redacted, blocked) and x-llmgw-guard-policy say what was done.

Streams. A streamed answer is judged a sentence at a time. Text is held until a sentence, a line or 200 characters ends, released up to its last whitespace — so a value still arriving is never sent in two halves — and rewritten if needed. What was released cannot be taken back: a policy that must never let a word through uses stream: buffer_all, which holds the whole answer until it is judged.

Shadow mode

mode: shadow judges and records — the usage row says shadow-blocked, shadow-redacted — and changes nothing. Run a new policy in shadow first, and read what it would have done before enforcing it.

What is recorded

Each request's usage row has the action, policy, category and the time the checks took. The access log has the action, stage and policy. Neither has the text, a matched value, or the placeholder map: the map exists only in the gateway's memory while the request is served.

In the console

sudo llmgw has a Guardrails view: each policy with its mode, what it does when it cannot judge, and what it checks; whether each judge model it leans on has replicas ready — a policy that fails closed refuses everything while its judge has none; where policies are attached, with A to attach one and Enter on a row to detach it; and what they did in the last day (W for an hour or a week), totals first and the newest requests after, each with the request id llmgw ctl request reads. The same is at GET /api/v1/guard and GET /api/v1/guard/events?since=24h, and on the portal's Guardrails page.