Guardrail policies

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 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 to connect one.

​

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.

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

To change a policy later, open it from the list and select Edit. To remove one, select Delete.

​

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.