> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.lakera.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.lakera.ai/_mcp/server.

# Custom Guardrails

Custom guardrails detect what you describe in plain language; no code or regular
expressions are required. A built-in AI assistant compiles your description into a
detection policy and asks a clarifying question when the scope is ambiguous. Check
Point managed guardrails cover fixed threat categories; custom guardrails cover
requirements specific to your organization. Both run in the same policy.

> **Note**
>
> Custom Guardrails is a beta release. We recommend running projects that use custom
> guardrails in [Detect mode](/docs/projects#project-mode) before switching to
> enforcement.

## What you can detect

A custom guardrail is built from one or more rules. The assistant suggests which rule
type fits your description:

1. **Patterns and structured formats.** A plain description such as "flag any IP
   address" is enough: the assistant recognizes it as a structured format and builds
   the matching rule automatically. This works for IP addresses, national identifiers such
   as tax codes or social security numbers, and internal account or ticket ID
   schemes. Pattern rules are deterministic, with no threshold to tune.
2. **Semantic content and intent.** For rules such as "flag messages that give financial
   advice", detection is based on meaning rather than fixed phrases. Semantic rules
   catch paraphrases and work across languages with no configuration. Each semantic rule
   has a detection threshold — `LOW`, `MEDIUM`, or `HIGH` — with `HIGH` as the default.
3. **Combinations.** A single guardrail can mix pattern and semantic rules, connected by
   logic you describe naturally: "flag Italian fiscal codes and any mentions of
   financial advice".

## Building a custom guardrail

From the [policies page](https://platform.lakera.ai/dashboard/policies), select **New
Policy**, then **Build Custom Policy**, then **Configure** or add a custom guardrail
from the catalog.

Describe what you want to detect in the chat. The assistant compiles the guardrail and
shows it beside the conversation as it is built. You can review the rules and the flag
condition before saving anything.

![The guardrail builder compiling a guardrail with a pattern rule for the Italian Codice Fiscale and a semantic rule for financial advice](/_fern-img/0c799f2d89f257d6cd361ec2c6111fcf4346e714cc0370f559ead7d34ba7ed68.webp)

## Testing a guardrail

Once the guardrail is compiled, you test it on example sentences in the same interface.
The assistant runs a first set of tests itself, and you can submit your own. Each result
shows whether the input was flagged, with a breakdown of which rule triggered.

![Test results in the guardrail builder showing flagged and not-flagged examples with a per-rule breakdown](/_fern-img/020d5ad275aaf4c5518ce2d6dd97d93fd235c80b9c772c99d23efa6336796dd7.webp)

If a test surfaces a false positive or false negative, describe the change and the
guardrail updates immediately. Two settings control whether a semantic rule fires:

1. **Wording** — the description of what the rule detects.
2. **Threshold** — a lower threshold flags more borderline content, which raises recall
   and makes false positives more likely.

When a test behaves unexpectedly, the assistant proposes a change to one or the other
and states the trade-off.

## Screening roles

Each custom guardrail is scoped to [screening roles](/docs/api/screening-roles), by
default `user` and `assistant`. Scoping matters for rules that overlap with everyday
language. A rule that flags destructive SQL such as `DROP TABLE` will also fire on a
user asking "what does DROP TABLE do?". Scoped to tool calls
(`assistant::tool_call`), it fires only on the SQL an agent actually sends to a
database tool.

## Writing effective guardrails

Custom guardrails work best when the detection target is well-bounded:

1. A single bounded topic, such as financial, legal, or medical advice.
2. Patterns: national identifiers, employee numbers, internal ticket or account ID
   schemes.
3. Named lists, such as competitor or person names. If your description references a
   list without providing it, the assistant asks for the entries.

Keep in mind:

1. A rule sees one message at a time and nothing else. Conversation history is not
   available to it, so a rule cannot depend on what was said in an earlier turn.
2. For threat categories a managed guardrail already covers — prompt attacks
   ([Prompt Defense](/docs/prompt-defense)), harmful content
   ([Content Moderation](/docs/content-moderation)), PII and sensitive data
   ([Data Leakage Prevention](/docs/data-leakage-prevention)) — use the managed
   detector. These are adversarial detection problems where attack techniques change
   constantly; the managed guardrails are models trained for those threats and updated
   daily against new attack data, and a description-based rule will not match their
   coverage.
3. Pattern rules that overlap with natural language, such as SQL keywords, can flag
   benign messages; scope them to the right role or combine them with a semantic
   condition.

## How detection runs

The AI assistant is only involved while you design a guardrail — the builder is not on
the request path. At screening time, no LLM is involved and no external calls are made:
evaluation runs inside Guard, in the same request as the Check Point managed
guardrails.