LLM Policies overview

An agent that talks to customers will eventually be handed a phone number, an account number, or a question it has no business answering. An LLM policy is where you decide what happens next.

A policy is a named set of rules. You create it, publish it, and attach it to an agent. From then on every request that agent makes to a language model passes through it.

The LLM Policies tab showing policy cards with status badges

What a policy controls

Rule	What it does
PII detection	Finds personal data in a prompt and redacts it, blocks the request, or just records it
Blocked content	Refuses requests containing particular words, phrases or patterns
Topic restrictions	Instructs the model to refuse certain subjects, or to stay within a set of approved ones
Remove active content	Strips scripts and unsafe markup out of what the model sends back
Response cache	Whether identical requests may reuse a stored answer

What a policy does not control

Worth stating plainly, because these are reasonable things to assume:

It doesn’t choose the model. That’s LLM Settings and the agent’s own configuration.
It doesn’t cap spend. Cost is governed by your plan’s credits and entitlements, not by a policy.
It doesn’t cover indexing. Adding documents to a Content Store, or writing agent memory, doesn’t pass through a policy. Policies apply to the model calls an agent makes.
It isn’t inherited by sub-agents. If a Task Agent calls another agent, that agent runs under its own policy — a restrictive parent doesn’t constrain a permissive child.
It isn’t project-wide. A policy takes effect only on agents it is explicitly attached to.

ℹ️

Secret redaction happens on every request, with or without a policy. Anything shaped like an API key, token, private key or database URL is stripped from prompts before they reach a provider. That’s platform behaviour and there’s no setting for it.

How a policy takes effect

Three things have to be true:


1. the policy is ACTIVE  ──▶  published, not a draft
2. it is attached to an agent  ──▶  AI Agent or Task Agent
3. the agent is saved  ──▶  on an AI Agent this is a separate step

Miss any one and the agent runs with no policy and no warning. If a policy seems to be doing nothing, Troubleshooting walks these in order.

Where rules are applied

Different rules act at different points, which explains why they behave differently:

Rule	Applied
PII detection, blocked content	On the way in, before the provider sees the prompt
PII detection, remove active content	On the way out, on the model’s reply
Topic restrictions	As an instruction added to the system prompt
Response cache	Around the call itself

The topic one matters most. Blocked content is enforced by the platform — the text never leaves. Topic restrictions are enforced by the model, because you’re telling it what to refuse. See Topic restrictions.

What’s in this section

Getting started

Create a policy — the three-step wizard, and the templates that pre-fill it.
Apply a policy to an agent — the step that makes it real.
Publish & versions — draft, active, deprecated, and what editing a live policy does.

The rules themselves

PII detection · Blocked content · Topic restrictions · Remove active content · Response cache

When it doesn’t work

Troubleshooting

Create a policy — start from a template or from scratch.