Introduction
What Policy Management controls, how policies at different scopes combine, monitor and enforce mode, and what each edition includes.
Studio → Settings → Policies is where an Organization's Owners and Admins decide what Agents, Teams and Workflows may do and what data may cross a boundary. Every check the policy engine makes is written to a decision log, and the log can be exported as audit evidence.
A policy is a set of rules. It does not run on its own: it applies to the objects in its scope, and every run of those objects is checked against it.
What a policy controls
| Rule family | What it decides | Page |
|---|---|---|
| Tools | Which tools, MCP servers, API tools, app operations, Data Table actions and Skills an Agent may use | Rules |
| Approvals | Which tool calls wait for a person to approve them | Approvals and overrides |
| Network | Which hosts a run may reach | Rules |
| Code execution | Whether Code nodes and Skill scripts may run, and their time and memory limits | Rules |
| Models | Which model configurations a call may use, by provider type, region or configuration | Rules |
| Data | What happens when personal data, financial data, confidential business data or a credential is found in a payload | Data protection |
| Outbound | What a workflow step such as Send Email or HTTP Request may send | Data protection |
| Routing | Which models may process a given category of data, and what to do when the configured one may not (Enterprise) | Data protection |
Where rules are checked
The engine checks every run at four fixed points. A policy chooses which rules act at each; it cannot add, remove or skip one, and no run path opts out (chat, the public API, async jobs, Teams, workflow nodes and voice calls are all checked).
| Boundary | Checked | What a deny does |
|---|---|---|
| Model calls | The fully assembled prompt of every model call, before it is sent | The model is not called and the run ends as policy_denied. Chat shows "This request was blocked by your organization's policy", the API answers 403 policy_denied, a workflow node fails, a voice call plays a fixed spoken refusal. |
| Tool calls | The tool and its arguments before the call, and its result before it goes back to the model | The tool is not called (or its result is dropped). The model is told policy_denied and the run carries on, so it can explain. |
| Agent output | The answer before it reaches the user, a sentence at a time when it is streamed | The held sentence and everything after it are replaced by the refusal. Sentences already sent stay sent. |
| Outbound | Where a request goes (network egress), and what a workflow step sends | The request is not sent. A workflow run stops as Stopped by policy. |
A denial shown to an end user carries a reference such as REF-7HQ2K6XM. The message names no category, detector or value; an admin finds the decision by searching that reference in Activity.
If the engine cannot apply a rule (a detector fails, the policy cannot be loaded), it denies. Nothing is let through because a check broke.
Scopes
A policy is created at one scope, and the scope cannot be changed afterwards.
| Scope | Applies to |
|---|---|
| Organization | Everything in the Organization |
| A project | Every Agent, Team and Workflow in that Project |
| A specific object | One Agent, Team or Workflow. Studio attaches the policy to it for you. |
| Package | Created by a Package install, never by hand. See Package floors. |
An Organization or Project policy needs no attachment. An object policy applies only to the object it is attached to, and only to that one.
The effective policy
An object runs under its effective policy: the Organization's active policies, its Project's active policies and the policies attached to it, combined so that the most restrictive value wins:
| Kind of rule | Combined as |
|---|---|
| An allowlist (hosts, provider types, regions, …) | Intersected: a value must be allowed by every policy |
| A tool decision | The strictest: deny, then approval, then allow |
| A data action | The strictest: deny, then escalate, then redact, then allow |
| A limit (code run time, memory) | The lower |
| An on/off switch (code execution) | Off wins |
| An approval group | On wins |
Two allowlists that share nothing allow nothing, never everything.
A child scope can only restrict. A Project policy that would loosen an active, enforcing Organization policy, or an object policy that would loosen its Organization's or Project's, is refused when it is saved, with a message naming the parent policy and the rule (policy_loosens_parent). The same check runs again at activation, against the parents as they are then. To relax an inherited rule for one object or Project, use an override (Enterprise).
Each object's Policy tab shows its effective policy, with every policy that contributed to each rule. See Studio.
Teams and AI Agent nodes
When an Agent runs as a Team member or inside a workflow AI Agent node, most rules come from the Team's or the Workflow's effective policy, not the Agent's. See Policies in a Team run and Policies inside a workflow.
Draft, active, archived
- A new policy is a draft. A draft applies to nothing.
- Review & activate turns the draft into version 1, and the policy is active. Versions are immutable: editing an active policy opens a single draft beside the version in force, and activating it writes the next version. The version in force keeps applying until then.
- Archive stops the policy applying at the next run. Its versions and every decision they made are kept.
Any version can be opened read-only and duplicated as a new draft.
Monitor and enforce
Every activation records a mode:
- Enforce: the rules decide.
- Monitor: every rule is evaluated and its verdict is logged as what it would have done ("would have denied"), but nothing is blocked, masked, rerouted or held for approval.
Monitor is how you try a policy on real traffic before it can stop anything. Policies created from a template, and blank policies created in Studio, start in Monitor. When the would-have decisions look right, Switch to Enforce activates a new version with the same rules and shows the last 7 days' would-have counts first.
When enforce and monitor policies apply to the same object, the enforce rules decide and the monitor rules are only logged. A monitor policy is not a parent for the restrict-only check: only active, enforcing parents are.
Community and Enterprise
Studio never hides an Enterprise feature. On Community it is shown, disabled, with an ENTERPRISE pill and a one-line reason. The API refuses it with 403 policy_capability_not_licensed, naming the capability, and a policy that uses one is not saved: a rule you believe is in force is never stored and ignored.
| Community | Enterprise adds |
|---|---|
| Policies, versions, scopes, inheritance, monitor mode | Name recognition (people, organisations, places) |
| Tool ceilings, approvals, the host allowlist, code execution controls | Redaction: placeholders instead of values, and restoring them where allowed |
| Model allowlist by configuration, provider type and region | Routing by data category |
| Built-in detectors with allow, deny and escalate | Custom patterns, keyword dictionaries and compliance mappings |
| Declared source classification | Overrides of an inherited policy |
| Allow and deny on outbound workflow steps | Redact on outbound Send Email |
| The decision log and Activity | Failure alerts and the daily digest, in-app and by email |
| Pattern-based scrubbing of traces and logs | Name recognition in scrubbing |
| — | Evidence export and the AI inventory export |
| — | Templates (GDPR baseline, Financial services (DORA)) |
Permissions
| Permission | Allows | Built-in roles |
|---|---|---|
policy.view | Reading policies, the Classified sources and Detection library tabs | Owner, Admin |
policy.create | Creating a policy | Owner, Admin |
policy.update | Saving a draft, attaching a policy to an object, classifying a source (with the source's own update right) | Owner, Admin |
policy.activate | Activating a version, switching mode | Owner, Admin |
policy.delete | Archiving | Owner, Admin |
policy.effective.view | Reading one object's effective policy on its Policy tab | Owner, Admin, Editor |
policy.pattern.manage | Managing custom patterns, keyword dictionaries and mappings (Enterprise) | Owner, Admin |
policy.override_parent | Attaching and removing overrides (Enterprise) | Owner, Admin |
audit.view | The Activity tab and the decision drawer | Owner, Admin |
reports.generate | Evidence and AI inventory exports (Enterprise) | Owner, Admin |
A control you lack the permission for stays visible, disabled, with the permission it needs. See Members & Roles for custom roles.
Related pages
- Network egress: the host allowlist in depth, and default-deny for Docker Compose.
- Personal data in traces and logs: what is scrubbed or encrypted before run data is stored, whatever your policies say.
- Manifest
policy_set: the policy a Package brings with it.