Policies in Studio
A walkthrough of Settings → Policies, the policy editor, the Policy tab on an object, and how policy decisions appear in runs.
Studio → Settings → Policies is a desktop screen. Nothing on it is hidden for lack of a permission or an edition: the control stays visible and disabled, with the reason.
The tabs
| Tab | What it shows | Needs |
|---|---|---|
| Policies | Every policy | policy.view |
| Activity | The decision log | audit.view |
| Classified sources | Every declared source, with an Edit link to its settings | policy.view |
| Detection library | Built-in patterns, Name recognition, Custom patterns, Keyword dictionaries | policy.view; custom items Enterprise |
| Evidence export | The evidence and AI inventory exports | Enterprise, reports.generate |
Policies
The list shows each policy's scope, mode, version, how many objects it applies to, its decisions and failures over the last 7 days, and who last changed it. Filter by scope, mode and status; archived policies appear only when you ask for them. A row's menu has Duplicate as draft, Switch to Monitor/Enforce… and Archive….
Activity
A summary (decisions by outcome, severity, and the latest failure), filters (time, severity, outcome, rule kind, category, boundary, object, policy) and a search for a REF- reference, which must match exactly. Opening a row shows the decision in a drawer. Monitor decisions read "would".
Detection library
Filter by search, category, framework and whether an item is used. A built-in pattern opens read-only, with what it detects, examples, the policies that use it and its 7-day decisions; only your mappings on it can be edited. The custom pattern editor validates as you type and runs the samples and test area in your browser, so their text does not leave the page; Save as vN writes a new version. See Custom patterns and keyword dictionaries.
The policy editor
+ New policy starts from a template or a blank policy. The left navigation has Rules and Versions. The right rail states the policy in plain language and lists its warnings and blocking items.
| Section | Sets |
|---|---|
| General | Name, description, scope (fixed once saved), mode |
| Compliance mappings | Your mappings (Enterprise) |
| What agents may do | Tools, approvals, network, code execution |
| What data may cross | Actions per category, name recognition, real values, exclusions |
| Where data may be processed | Model allowlist and rules that depend on the data (the latter Enterprise) |
Save draft keeps your edits without changing what is in force. A changed item shows what the active version says. Discard draft drops the draft.
Review & activate is refused while a blocking item remains (invalid rules, a capability the edition lacks, a value above a deployment ceiling, a loosening of a parent, no permitted model). Otherwise it shows the diff against the version in force, who is affected, the existing tool bindings it forbids and the mode, and takes a version note, which is recorded and appears in evidence.
Switch to Enforce first shows the last 7 days' would-have counts with examples and the runs that would have failed. Archive names the objects still governed and what they lose. Versions opens any version read-only, with Duplicate as new draft.
The Policy tab on an object
An Agent, a Team, a Workflow (canvas header) and a Project (Settings → Projects → a project → Policy) each have a Policy view. It needs policy.view or policy.effective.view, so an Editor can read it.
- What applies here: the policies in force and how they combine, with + Attach policy and Override….
- Effective policy: every rule, with every policy that set it, and Show only conflicts.
- A banner while the object runs on an override, and one for each existing tool binding the policy now denies.
- A locked card for a Package floor.
- Side cards: what is attached, recent decisions with a link to Activity, and a Team's members or what is inside a Project.
Attaching a policy needs policy.create and policy.update.
In a run
- The builder's test thread folds decisions into each step, strikes through a blocked step and shows an approval card with Approve and Deny. In Monitor a dashed banner says nothing was blocked. Show what the model saw opens the stored model input, placeholders highlighted.
- What an end user sees is a plain message and the reference, with no policy name, category or placeholder.
- The canvas marks a blocked Code node WON'T RUN. The node panel's Policy check on this step lists what applies to an outbound step. After a run, the stopped step is red, later steps read Not run, and a masked or blocked step shows What was sent.
- A run trace has a policy lane and a Policy spans only filter; each span links to its decision.
- A voice call's transcript shows policy lines at their time. The stored speech itself is not scrubbed; see what is not scrubbed.
Introduction
What Policy Management controls, how policies at different scopes combine, monitor and enforce mode, and what each edition includes.
Rules
Tool ceilings, approvals, network destinations, code execution and the model allowlist — the rules under "What agents may do" and "Where data may be processed".