> ## Documentation Index > Fetch the complete documentation index at: https://docs.flintai.dev/llms.txt > Use this file to discover all available pages before exploring further. # Guardrail policies > Create guardrail policies that alert on, block, or redact unsafe content in your agents' live traffic A guardrail policy decides what your agents are allowed to say and do at runtime. It's a named set of detectors, each one watching for a single kind of problem, such as a jailbreak attempt, leaked credentials, or a phone number in a reply, and each carrying an action that says what to do when it fires. Guardrails run on live traffic in two directions: * **Incoming** content (the prompt on its way to the model) is checked by the detectors you assign to the **User** role. * **Outgoing** content (the model's response on its way back to the caller) is checked by the detectors you assign to the **Assistant** role. Your organization already has a [default policy](#the-default-policy) set up to monitor traffic in both directions, so your first decision is usually whether to move any of it from alerting to blocking or redacting. For guardrails to act, your agent's traffic has to reach Flint AI. You connect an agent with the Flint AI SDK, and from then on its prompts and responses pass through guardrails on the way to and from the model. Until you connect an agent, a policy has nothing to act on. See [Monitor and protect your agents](/flintai/platform/getting-started/runtime) to connect one. **These are not the same detectors as Flint AI Eval in the CLI.** Platform guardrail detectors act on live traffic, with a role, an action, and a required severity. The CLI's Eval detectors score responses in a test run and enforce nothing. They share several names and none of the behavior. See [How evaluation works](/flintai/cli/eval/how-evaluation-works) for the CLI side, and don't carry facts between the two. ## Supported model providers Guardrails inspect traffic on its way to and from the model, so the model has to be served by a provider Flint AI can read. Guardrails currently support: * **Anthropic** * **Google Gemini** * **OpenAI** Other providers, such as Amazon Bedrock, aren't supported yet, though support may broaden over time. If your agents call models through a provider that isn't listed, point them at a supported one so their traffic can be inspected. ## The guardrail policies page To open the page where you manage your policies: 1. Log in to your Flint AI instance. 2. Select the **Settings** icon . 3. Under **Configurations**, select **Guardrail policies**. This page is where you manage guardrail policies and detectors across your agents. It lists every policy in your organization, one per row. Each row has these columns: * **Policy ID** is the identifier your SDK sends to apply the policy. Select the copy icon to copy it. * **Policy name** is the name you gave the policy. * **Detectors** shows what the policy checks for, split into the **User** and **Assistant** roles, with a chip for each one. If there are too many to fit on the row, you'll see a **+N** chip covering the rest. A toolbar above the list tells you how many policies you have, along with these controls: * **Search** filters the list by name as you type. * The **Columns** control lets you show or hide any of the columns above, so you only see what you need. * **Add policy** opens the form to create a policy. See [Add a policy](#add-a-policy). This list is your whole organization's set of policies. If they run to more than one page, use the pagination controls at the bottom to move between them. Select any policy to open it in its own view, where you can see its full detector setup and edit it. ## What a policy contains A policy has a name, an optional description, and a set of detector entries grouped by role. There's no global threshold and no separate trigger list. Instead, each detector entry carries its own action and its own severity, so one policy can alert on some content and block or redact other content. ## Actions When a detector fires, it takes the action you set for that role: * **Block** stops the content. A blocked prompt never reaches the model, and a blocked response never reaches the caller. Either way, the caller gets a blocked result in place of the original. * **Redact** removes the matched text in transit and passes the rest through, so the model or the caller receives the content with the sensitive part taken out, not the original. Redaction is available only on the detectors that extract specific data: the PII detectors, Secrets, and Regex. * **Alert** records the event as a finding and lets the content through. This is monitoring, not enforcement. ## Detectors The interface groups detectors into the categories below. For each detector you turn on, you choose the roles it runs on and set an action and a severity for each role. In the interface, each detector can be turned on once per role, so a role holds at most one entry of each detector. * **Roles** decide which traffic the detector inspects. Assign it to the **User** role for incoming content and the **Assistant** role for outgoing content. Some detectors support only one role, and the interface shows **Not applicable** for a role a detector doesn't support. * **Severity** is required on every role you enable. You assign it (**Low**, **Medium**, **High**, or **Critical**), and it labels the findings the detector produces. It doesn't change what the detector matches. ### Content safety Content safety detectors guard against inputs that try to manipulate the model and against harmful language in either direction. #### Jailbreak Detects prompt injection and jailbreak attempts. Runs on the **User** role, with the **Block** or **Alert** action. #### Toxicity Identifies toxic, harmful, or offensive content. Runs on the **User** or **Assistant** role, with the **Block** or **Alert** action. ### PII detection PII detectors find personal data in traffic. Each one supports redaction, so you can strip the matched value in transit instead of blocking the content or only alerting on it. #### Credit card Detects credit card numbers. Runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. #### Email Detects email addresses. Runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. #### Phone Detects phone numbers. Runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. #### SSN Detects social security numbers. Runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. #### IP address Detects IP addresses. Runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. ### Data protection The **Secrets** detector finds API keys, tokens, passwords, and other embedded secrets. It runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action. ### Pattern matching The **Regex** detector finds text that matches custom regular-expression patterns you define. It runs on the **User** or **Assistant** role, with the **Block**, **Redact**, or **Alert** action, and adds these settings: * **Custom name** is an optional label for the detector, for your own reference. * **Patterns** takes up to **10** regular expressions, one per line. Put every pattern you need into this one Regex detector, since a role holds only one instance of it. ### Tool permissions The **Tool permissions** detector controls which tools your agent is allowed to call. It runs on the **Assistant** role only, with the **Block** or **Alert** action, and adds these settings: * **Custom name** is an optional label for the detector, for your own reference. * **Mode** is either **Blocklist**, which denies the listed tools, or **Allowlist**, which permits only the listed tools. * **Tools** takes the tool names the mode applies to. Search your existing tools or type a name. ### Topic control The **Topic Control** detector keeps prompts on the topic you define, flagging those that stray from it. It runs on the **User** role only, with the **Block** or **Alert** action, and adds these settings: * **Agent objective** describes the agent's primary goal or purpose, such as "Help users track and analyze personal expenses". * **Guidelines** takes behavioral guidelines for the agent, one per line, such as "Only discuss the user's own financial data" and "Do not give tax or investment advice". ### PHI detection The **PHI** detector finds protected health information. It runs on the **User** or **Assistant** role, with the **Alert** action only, and adds toggles for the kinds of identifier to look for: * **Direct IDs** covers names, addresses, dates, phone, email, SSN, record and account numbers, and similar direct identifiers. * **Quasi IDs** covers demographics, geographic and time information, medications, and medical details. ## Policy limits These limits apply to every policy, whatever mix of detectors it uses: * A policy name is up to **64 characters**, must start with a letter or number, and may contain letters, numbers, spaces, hyphens, underscores, parentheses, and periods. A custom name follows the same rules. * A description is up to **256 characters**. * A list setting, such as regex patterns or tool names, holds up to **10 items**, each up to **256 characters**. ## The default policy Every new organization starts with a seeded policy called **Baseline Monitoring (Alert)**. It watches for a starting set of issues on both incoming and outgoing content, and every detector in it is set to **Alert**. A new organization is therefore *monitoring* its agents, not *enforcing* anything: nothing is blocked or redacted until you create a policy, or edit this one, to do so. An organization always keeps at least one policy. You can edit or replace the baseline, but the interface won't let you delete your only policy. ## Add a policy On the [guardrail policies page](#the-guardrail-policies-page), select **Add policy**. The form opens with the policy's details at the top and the detectors below. Give the policy a name, which is the only required field, and an optional description. The name is how you'll recognize the policy in the list, so make it descriptive. Detectors are grouped by category. Turn on a detector to reveal its settings. For each role you want it to act on, enable the role and set its **Action** and **Severity**. Use the **User** role for incoming content and the **Assistant** role for outgoing content. A role the detector doesn't support shows **Not applicable**. Some detectors need more than an action and a severity. For **Regex**, **Tool permissions**, **Topic Control**, and **PHI**, complete the extra fields shown when the detector is enabled: patterns, tool lists, objective and guidelines, or the PHI toggles. Select **Create policy**. It appears in the list right away and is ready to apply to your agents. To change a policy later, open it from the list and select **Edit**. To remove one, select **Delete**. You can't delete your only policy. ## Apply a policy to your agents Creating a policy doesn't attach it to anything on its own. A policy takes effect when your agent's SDK sends the policy's ID with each request. Copy the policy ID from the **Guardrail policies** list, or from the SDK snippet on an agent's **Sessions** tab, and set it as your `policyId` (`FLINTAI_POLICY_ID`) in the SDK. Policies live at the organization level, and they take effect per agent. A policy isn't tied to a particular agent, so any agent that sends its ID uses it. You can apply one policy across several agents, or give each agent its own. There's no confirmation step in the interface: the policy is working once interactions start flowing through on the agent's **Sessions** tab, where you can see which were alerted, blocked, or redacted. Wrap your agent and start routing traffic through guardrails Point your SDK at the policy you created See what your guardrails alerted, blocked, and redacted Set the policy ID from the TypeScript SDK