Blocked content
Two lists in the policy wizard’s Content Policy step decide what a request may not contain. Unlike topic restrictions, these are enforced by the platform — a blocked request is stopped before the provider sees anything.
Blocked Keywords
Plain words or phrases. Case-insensitive, matched anywhere in the text.
Type a word, press Enter, and it appears as a chip. Add as many as you need.
confidential
internal only
project falconA request containing any of them, in any casing, anywhere — including inside a longer word — is refused.
This is the one most people want. It needs no special syntax, does exactly what it looks like, and is easy to explain to whoever asked for the restriction.
Blocked Patterns
Regular expressions, for cases where a word list isn’t enough — matching a shape rather than a term.
password.*=.*
api[_-]?key
ACC-[0-9]{6}Limits, enforced when you save:
- At most 50 patterns
- At most 1000 characters per pattern
- Patterns with nested quantifiers are rejected, because they can make matching hang
If a pattern breaks one of those rules you’ll get an error naming the problem, and the policy won’t save until you fix it.
Patterns are matched against the whole message, so a broad pattern blocks more than you expect. [0-9]{6} will refuse any message containing a six-digit number — including an order reference. Test on realistic input before publishing.
Which to use
| You want to block | Use |
|---|---|
| A known word or phrase | Blocked Keywords |
| A code, ID or credential shape | Blocked Patterns |
| A subject or theme | Neither — use topic restrictions |
Keywords and patterns are both hard blocks. Topics are an instruction to the model, which is a different guarantee.
What the user sees
When a request is blocked, the agent replies with a short refusal explaining that the request couldn’t be processed because of a content policy. It reads as a normal message, not an error, and it behaves the same whether the reply streams or arrives whole.
Blocked content in conversation history
A blocked word affects the message it appears in — not the rest of the conversation.
The new message is refused. Earlier turns already in the conversation are filtered instead: the offending text is removed before the request goes out, and the conversation continues normally. The same applies to an agent’s persona or system prompt — if it happens to contain a blocked word, that word is stripped rather than the agent becoming unusable.
So a customer who types a blocked word gets a refusal for that message, and their next question is answered as normal. The blocked text still never reaches the provider.
Common issues
- A pattern was rejected on save — check it against the three limits above. The error message names which one it broke.
- A pattern doesn’t match — it’s a regular expression, not a wildcard.
password*matchespasswor,password,passworddd; you probably wantpassword.*. - Too much is being blocked — patterns match anywhere in the message. Anchor them, or use a keyword instead.
- Nothing is blocked — confirm the policy is published, attached and saved. See Troubleshooting.
Next
- Topic restrictions — steering what the agent will discuss.