Configuring Policies

Learn how to configure policies to match your organization's security requirements.

Accessing Policy Configuration

1. Navigate to Policies in the sidebar
2. Browse the All policies, Enabled, or Recommended tab, or search
3. Click a policy to open its detail drawer

Policy Settings

Enable/Disable

Each policy row has a toggle:

• Enabled - The policy actively evaluates and enforces
• Disabled - The policy does not run

Toggling requires the policy-admin permission for the policy's scope.

note

The Edit and View history controls that appear on row hover are not yet wired up. Configure a policy from its detail drawer instead.

Enforcement Action

Every policy stores one of three enforcement actions:

Stored action	User Experience	Alert Created
block	Submission prevented, warning shown to the user	Yes
detect	Event recorded and alert created, user is not blocked	Yes
redact	Matched content masked before the prompt is sent	Yes

caution

The three stored actions are presented under different labels on different screens, which is worth knowing before you compare two policies:

Surface	Labels shown
Create custom policy	Log only, Monitor, Mask, Block
Policy detail drawer (edit)	Monitor only, Block request, Mask evidence
Create from description	Detect (log + alert), Redact (mask matches), Block (deny request)

Log only and Monitor both store detect, so they are indistinguishable once saved — reopening either shows Monitor only in the drawer. Mask / Mask evidence store redact.

tip

Start with a detect-style action for new policies to observe matches before enforcing blocks.

Severity

Custom policies carry an alert severity (Low / Medium / High / Critical) that sets the priority of the alerts they raise.

note

There is no detection-sensitivity control (Low/Medium/High match aggressiveness) and no published false-positive rates. Severity affects alert triage priority, not how aggressively content is matched.

Detection Configuration

The Detection rules step depends on the policy's category.

Custom-category policies

For policies in the Custom category you define matching directly:

• Keywords — add terms one at a time (bounded list)
• Regex patterns — add patterns with live validation, plus a Test button per pattern
• Case-sensitive matching — a single toggle

A Test patterns against sample text box lets you check your regex patterns against sample content while authoring.

All other categories

For every other category, detection is expressed as rule rows combined with AND/OR:

Fields: prompt, response, destination_domain, actor, model

Operators: contains, not_contains, matches_regex, equals, starts_with, ends_with, in_list, not_in_list

note

There is no three-mode Exact/Contains/Regex selector and no per-policy Manage Allowlist with justifications. To exempt legitimate matches, create an exception from the triggering alert — see Exceptions.

Scope Configuration

Organization and Team Scope

A policy's scope is either organization or team. A team-scoped policy applies to the teams you select.

note

There is no user-level policy scope — "Specific Users" and "Exclude Users" do not exist. Per-user exemptions are handled through Exceptions.

Environments and Actor Groups

The scope step also offers Environments and Actor groups selectors, both badged PRO & ENTERPRISE and disabled unless your plan includes team/environment scoping.

The available surfaces are Chat UI, Public API, Batch jobs, and Playground.

note

Policies are not scoped per AI platform. You cannot restrict a policy to ChatGPT but not Claude — a policy applies across the monitored surfaces. Some template names mention a specific platform for context; that naming does not create per-platform targeting.

Site Overrides

Per-site control types are configured separately — see Site Controls, including its caveat about which per-site settings released extension versions consume today.

Creating Custom Policies

Professional

Custom policy creation requires a Professional or Enterprise plan; the limit is enforced server-side.

Three entry points from the Policies page:

• Create from description — describe the rule in plain language and review the generated policy
• Create custom policy — the three-step editor below
• Use template — start from one of the built-in templates in the gallery

The three-step editor

The custom-policy editor has exactly three steps:

1. Basic info — name, category, description
2. Detection rules — keywords/patterns or field-operator-value rules (see above)
3. Action & scope — enforcement action, severity, and scope

note

The editor has no Keyword Match / Pattern Match / Data Type / Blank template picker — templates are chosen from the gallery instead, and the category you pick in step 1 determines which detection editor step 2 shows.

Example: custom keyword policy

Scenario: flag sharing of the project codename "Phoenix"

1. Basic info — name it "Project Phoenix Protection", category Custom
2. Detection rules — add keywords Project Phoenix, Phoenix initiative, Operation Phoenix; leave case-sensitive matching off
3. Action & scope — choose an action, set severity, scope to your organization

Drafts

An in-progress custom policy can be saved as a draft.

note

Saved drafts are not yet listed anywhere in the UI — there is no drafts view to return to. Finish a policy in one sitting, or re-create it.

Policy Testing

The regex Test controls inside the detection step let you check patterns against sample text while authoring. The policy detail drawer also shows illustrative Detection examples for the policy type.

note

There is no policy-level Test Policy tester for arbitrary sample content, and no test/shadow mode that runs a policy without enforcing it. To observe before enforcing, set a detect-style enforcement action.

Policy History

note

Per-policy change history, version comparison, and revert are not shipped — the View history control on the policy row is not wired up. Policy configuration changes are recorded organization-wide on the Activity page under the Policy changes tab.

Archiving a Policy

Deleting a policy from its detail drawer performs an Archive policy action: the policy is disabled and marked archived rather than permanently removed, so its historical alerts stay interpretable.

Bulk Operations

note

Policy import/export (JSON) and bulk enable/disable are not shipped — policies are toggled one at a time. The Enterprise SIEM export covers audit events, not policy definitions.

Best Practices

Policy Naming

• Use clear, descriptive names
• Include what's detected
• Note the category

Documentation

• Record why each policy exists in its description
• Note the business requirement it satisfies

Testing

• Use a detect-style action before switching to block
• Validate regex patterns with the built-in pattern tester
• Watch alert volume for false positives after enabling

Review Cycle

• Review policies periodically
• Adjust based on alert volume
• Archive policies you no longer need

Related Topics

• Policy Overview - How policies work
• Policy Categories - Available categories
• Exceptions - Handle special cases