> ## Documentation Index > Fetch the complete documentation index at: https://koreai.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Safety and guardrails Configure enforcement layers, guardrail policies, providers, and input/output safety rules to protect agents from misuse and ensure compliance. The platform uses three enforcement layers to control agent behavior and protect against misuse, sensitive data exposure, and policy violations. | Enforcement layer | Description | Example | | - | - | - | | [Guardrails](#input-guardrails) | Safety and quality checks applied to agent input and output content. | Blocking abusive language or redacting sensitive information from responses. | | [Limitations](https://koreai.mintlify.site/agent-platform/create-agents.md#define-identity-and-persona) | Reasoning-based guidance enforced through the model. Defines how the agent behaves, what it avoid, and the scope it operates within. | Instructing an agent to avoid financial advice or remain within a support domain. | | [Constraints](https://koreai.mintlify.site/agent-platform/concepts.md#constraints-and-guardrails) | Runtime business-rule validations that prevent execution when required conditions aren't met. | Requiring a customer ID before allowing an order lookup or payment action. | ## Constraints vs. guardrails Constraints and guardrails operate at different layers of agent execution: | Feature | Constraints | Guardrails | | - | - | - | | Purpose | Enforce business rules. | Enforce safety and content policies. | | Scope | Agent logic and tool execution. | LLM input and output content. | | Evaluation | Runtime data and conditions. | Message and response content. | | Typical usage | Eligibility checks, required inputs. | Content moderation, PII detection. | *** ## Guardrails Guardrails evaluate agent inputs and outputs against configurable safety categories. Depending on configuration, they can block content, warn users, redact sensitive information, escalate interactions, request rephrasing, or automatically sanitize responses. The following shows a typical runtime flow: ```mermaid actions={false} theme={null} %%{init: {'theme': 'base', 'themeVariables': {'background': 'transparent', 'primaryColor': '#EAF8E4', 'primaryTextColor': '#1a1a1a', 'primaryBorderColor': '#5CC83A', 'lineColor': '#5CC83A', 'secondaryColor': 'transparent', 'tertiaryColor': 'transparent', 'clusterBkg': 'transparent', 'clusterBorder': '#5CC83A', 'titleColor': '#1a1a1a', 'clusterLabelBackground': 'transparent', 'edgeLabelBackground': '#EAF8E4'}}}%% flowchart TD A[User Input] --> B[Input Guardrails] B --> |PII detection\nPrompt injection\nTopic checks| C[Agent / Model Processing] C --> D[Output Guardrails] D --> |Toxicity checks\nPII redaction\nContent filtering| E[Final Response Returned to User] ``` ### Guardrail checkpoints A guardrail rule's `kind` sets which single item it checks. A check sees only that one item -- never the conversation history or the system prompt -- so write each rule to judge one message on its own. | Checkpoint | `kind` | What the check sees | When it runs | | - | - | - | - | | Input | `input` | The customer's message. Model-based tiers see it with PII already tokenized. | Before the model is called. | | Output | `output` | The final reply, plus up to 20 of this turn's tool results (4,096 characters each) when built-ins are enabled. | Before the reply is delivered. | | Tool call | `tool_input` | The tool's arguments, as JSON. | Before the tool runs. | | Tool result | `tool_output` | The result as the model would see it. | After the tool runs, before the model reads it. | | Handoff | `handoff` | The context being passed, and the source and target agents. | Before the context is transferred, using the source agent's rules. | `kind: both` is shorthand for `input` plus `output`. See [Tool and handoff guardrails](#tool-and-handoff-guardrails) below for `tool_input`, `tool_output`, and `handoff`. > [!NOTE] > > A check that reads `content`, `session_state`, or `tool_results` needs `EXECUTION: guardrail_builtins: true`. Without it, the check errors and -- under the default Open fail mode -- the message it would have checked is let through. *** ### Guardrail configuration levels Guardrails can be configured at two levels: | Scope | Purpose | Where managed | Typical usage | | - | - | - | - | | Project guardrails | Centralized governance and reusable safety policies across agents. | **Govern > Guardrails** | Enterprise-wide safety enforcement. | | Agent guardrails | Agent-specific runtime safety checks. | **Agent > Guardrails** | Localized rules for individual agents. | Project-level policies apply in addition to agent-specific guardrails. **Use project guardrails when you want:** * Consistent governance across multiple agents. * Shared moderation providers. * Organization-wide safety controls. * Centralized runtime management. **Use agent guardrails when:** * Safety rules are specific to one agent. * Runtime behavior must be customized locally. * Shared project-level governance isn't required. *** ## Guardrail policies Policies are reusable governance containers that define runtime safety behavior across agents and projects. Each policy contains one or more rules. Each rule defines what to evaluate, where to evaluate it, which provider to use, and what action to take when triggered. Rules can support input and output evaluation, streaming responses, pattern matching, model-based moderation, and LLM-based classification. Go to **Govern > Guardrails > Policies**. > [!NOTE] > > Only one policy can be active per project at a time. Activating a new policy automatically deactivates the previously active one. ### Policy scopes **Project-level scope** — Apply the policy to all agents in the project: ```yaml theme={null} { "scopeType": "project" } ``` **Agent-level scope** — Apply the policy only to a specific agent: ```yaml theme={null} { "scopeType": "agent", "agentDefId": "agent-definition-id" } ``` ### Create a guardrail policy 1. Go to **Govern > Guardrails**. 2. On the **Policies** tab, click **Create policy**. 3. Enter a policy name and description. 4. Select the policy scope to specify whether the policy applies to all agents in the project or only to a specific agent. 5. Configure the required rules, coverage, and runtime settings. 6. Click **Save**. #### Rules | Field | Description | | - | - | | Applies To | Where the rule is evaluated: Input, Output, or Both. | | Action | What happens when the rule is triggered: Block, Warn, Redact, Escalate, Fix, Reask, or Filter. | | Provider | The provider used for guardrail evaluation. | | Category | The safety or content category evaluated by the rule. | | Severity Threshold | The numeric threshold that triggers the configured action. Enter a value from 0.01 to 1.0, or use Low, Medium, or High as a shortcut. | | Action Message | The message shown or logged when the rule is triggered. | #### Runtime settings | Setting | Description | | - | - | | Fail Mode | Controls whether execution continues or is blocked if guardrail evaluation fails. **Open** allows execution to continue if evaluation fails or times out. **Closed** blocks execution if guardrail evaluation fails or cannot complete, making it suitable for high-security or compliance-sensitive applications. | | Coverage | Determines which parts of the agent's execution are evaluated. **All model I/O** checks model-to-model messages, tool arguments, tool results, sub-agent handoffs, and customer-facing input and output. **User boundary** checks only the customer's input and the responses the agent sends to the customer. | | Local Timeout | How long the platform waits for local guardrail evaluation. | | Model Timeout | How long the platform waits for model-based provider evaluation. | | LLM Timeout | How long the platform waits for LLM-based evaluation. | | Streaming Evaluation | Enables guardrail evaluation while responses are streamed. | | Chunk Interval | Whether streamed responses are evaluated by sentence, token, or chunk size. | | Early Termination | Stops evaluation on the first guardrail trigger. | *** ## Guardrail providers Providers are the evaluation engines used to classify or inspect content during runtime. They can detect unsafe content, identify PII, classify toxicity, evaluate prompt injection attempts, and perform model-based moderation. ### Select guardrail providers Project authors can select which workspace-configured guardrail providers the project can use. Providers that are not selected are not used by the project, even if they are configured at the workspace level. Ask your workspace administrator to add and configure a guardrail provider in the Admin Console before you select it for the project. For more information on configuring guardrail providers, see [Guardrail providers](https://koreai.mintlify.site/agent-platform/administration/ai-configuration.md#guardrail-providers). *** ## Input guardrails Input guardrails evaluate user messages before they reach the LLM. Use them to detect unsafe content, identify prompt injection attempts, protect sensitive information, and enforce topic or policy restrictions. Use `kind: input` to evaluate user messages before they reach the LLM: ```yaml theme={null} GUARDRAILS: profanity_filter: kind: input action: block ``` Input guardrails support: * Pattern-based detection. * Provider-based moderation. * LLM-based classification. * Severity-based actions. * Runtime priority ordering. *** ## Output guardrails Output guardrails evaluate generated responses before they're returned to the user. Use them to prevent unsafe responses, redact sensitive information, apply moderation checks, and inspect streaming output during generation. Use `kind: output` to evaluate generated responses: ```yaml theme={null} GUARDRAILS: pii_output_prevention: kind: output action: block ``` Use `kind: both` to apply the same rule to both input and output: ```yaml theme={null} GUARDRAILS: phone_number_check: kind: both action: warn ``` Enable streaming evaluation for responses while content is still being generated: ```yaml theme={null} GUARDRAILS: streaming_safety: kind: output streaming: true ``` Output guardrails support: * PII detection and redaction. * Toxicity scoring. * Streaming response evaluation. * Bidirectional guardrails. * Automatic response cleanup and fix strategies. *** ## Tool and handoff guardrails Beyond `input`, `output`, and `both`, a rule's `kind` can target a tool call, a tool's result, or a handoff to another agent. Use `kind: tool_input` to check a tool's arguments before the call runs: ```yaml theme={null} GUARDRAILS: block_large_transfers: kind: tool_input check: abl.matches_pattern(tool_input.amount, "^[0-9]{6,}$") action: block message: "That transfer amount needs manual review." ``` Use `kind: tool_output` to check a tool's result before the model reads it: ```yaml theme={null} GUARDRAILS: scrub_tool_pii: kind: tool_output check: abl.contains_pii(tool_output) action: redact ``` Use `kind: handoff` to check the context passed to another agent. It is evaluated with the source agent's rules before the transfer happens: ```yaml theme={null} GUARDRAILS: handoff_review: kind: handoff llm_check: "Does this handoff include unredacted financial account numbers?" action: block message: "This conversation needs a different routing path." ``` A `block` at any of these checkpoints withholds the call, result, or handoff and returns an error to the model instead of ending the conversation. Pair `escalate` with your own routing setup -- see [Agent transfer](https://koreai.mintlify.site/agent-platform/administration/agent-behavior-settings.md#agent-transfer) -- since a guardrail `escalate` action only sends the escalation message and doesn't transfer the conversation by itself. *** ## DSL and UI mapping The platform maintains a one-to-one mapping between the UI configuration and the DSL/ABL definition. This lets you: * Configure guardrails visually. * Manage guardrails as code. * Version and compare configuration changes. * Switch between UI and DSL-based editing workflows. When you add a guardrail rule in the UI, the platform generates the corresponding `GUARDRAILS:` block in the DSL/ABL. Updating the `GUARDRAILS:` block directly in the DSL/ABL updates the same rule in the UI. *** ## Best practices * Use project guardrails for centralized governance; use agent guardrails for localized runtime behavior. * Start with `warn` before enabling `block` to understand impact before enforcement. * Test regex patterns carefully to reduce false positives. * Enable streaming guardrails for high-risk applications. * Use fail-closed behavior for compliance-sensitive workloads. * Separate business constraints from safety guardrails. * Use providers with caching and budget controls for large-scale deployments. *** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.