---
title: "Guardrails"
url: "/guardrails"
description: "Per-agent safety controls enforced by the runtime — what each setting does, and which ones you cannot turn off."
productArea: guardrails
audience: ["business-user", "admin"]
tags: ["guardrails", "safety"]
lastReviewed: 2026-08-17
---

# Guardrails (/guardrails)





Guardrails are safety controls enforced by the KlicForge runtime — not merely suggestions in the
prompt. They scan input before it reaches the model, validate output before it is returned, and
enforce tool policy throughout.

Configure them per agent on the **Guardrails** tab.

## How a request flows [#how-a-request-flows]

```text
User message → injection scan → PII redaction
       ↓
knowledge retrieval → chunk injection scan
       ↓
prompt files + guardrail rules
       ↓
model call
       ↓
response validation → safe fallback if needed
       ↓
guardrail events logged
```

## What you can change [#what-you-can-change]

These are the settings that are genuinely yours to configure.

| Setting                                 | Default         | What it does                                                                                    |
| --------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------- |
| **Answer mode**                         | `grounded_only` | Where the agent may source answers from. See [answer modes](/guardrails/answer-modes)           |
| **Allowed topics**                      | empty           | Topics the agent may discuss. Empty means no restriction                                        |
| **Off-topic message**                   | a default       | What the agent says when a question is out of scope                                             |
| **PII redaction**                       | **on**          | Removes email, phone, card and similar patterns from the message before the model sees it       |
| **Prompt injection checking**           | on              | Scans messages, knowledge passages and tool output for injection attempts                       |
| **Tool argument validation**            | on              | Validates arguments against a tool's schema before running it                                   |
| **Response validation**                 | **off**         | Runs pattern validation on every response before returning it                                   |
| **Safe fallback on validation failure** | **off**         | Replaces a failing response with a safe message instead of returning it                         |
| **Child-safe mode**                     | **on**          | Injects strict content moderation. Turn off only for agents explicitly aimed at adult audiences |
| **Tool error classification**           | on              | Stops the agent inventing a successful outcome when a tool fails, and retries transient errors  |
| **Log guardrail events**                | on              | Emits structured events for observability                                                       |
| **Include source provenance**           | off             | Adds knowledge source IDs to response metadata                                                  |

<Callout type="warn">
  **PII redaction is on by default.** That means personal data in a user's message is masked before
  the model sees it. If your agent legitimately needs to act on what the user typed — "my email is
  X, please update it" — you will need to account for this when designing the flow.
</Callout>

<Callout type="info">
  **Child-safe mode is on by default**, not off. It is an opt-out, not an opt-in. Leave it on unless
  you have a specific reason.
</Callout>

## What you cannot turn off [#what-you-cannot-turn-off]

These are enforced for every agent regardless of configuration:

* Guardrails themselves cannot be disabled.
* **Topic boundary enforcement** — keeps the agent inside its defined scope. This constrains
  nothing while **Allowed topics** is empty, which is why the topic list above is yours to set
  even though the enforcement itself is not.
* **Capability boundary enforcement** — blocks responses claiming abilities the agent does not have.
* **Tool allowlist enforcement** — rejects calls to tools not enabled on the agent.
* **No fake tool usage** — blocks responses claiming a tool ran when none did.
* **Prompt leak protection** — stops system prompt content appearing in replies.
* **Secret leak protection** — stops credentials and keys appearing in replies.
* **Reasoning leak protection** — stops a model's internal reasoning appearing in a reply. See
  [reasoning effort](/agents/models#reasoning-effort).
* **Tool output as data only** — strips instruction-like patterns from tool output.
* **Hallucination prevention** and **no fabrication**.

## Safe fallback messages [#safe-fallback-messages]

When safe fallback is enabled and a response fails validation, the agent returns one of:

* *"I do not have enough verified information in my available knowledge or tools to answer
  that."*
* *"I cannot perform that action with my current capabilities."*
* *"I was unable to generate a verified response. Please rephrase your question or contact
  support."*

## Choosing settings [#choosing-settings]

For a **public-facing support agent**: keep the defaults. `grounded_only`, PII redaction on,
child-safe mode on. Consider enabling response validation and safe fallback for extra caution.

For an **internal assistant**: `grounded_with_limited_inference` is often more useful, and you
may want to relax topic boundaries.

For an agent that **must never guess**: `grounded_only` plus response validation and safe
fallback.

## Related pages [#related-pages]

* [Answer modes](/guardrails/answer-modes)
* [Knowledge sources](/knowledge)
* [Tools](/skills-and-tools/tools)
* [Security and privacy](/organization/security-and-privacy)