Policy Engine — User Guide

This guide explains the Policy Engine from the perspective of an organization admin or end user. It describes how policy packs are structured, how chains and combining algorithms determine the final enforcement action, and what users see when a policy triggers. For admin configuration steps, see Policy Engine admin guide.

How the Policy Engine evaluates requests

Every AI request passes through the Policy Engine before being forwarded to the provider. The engine evaluates the request against configured policy rules and returns an enforcement action.

Evaluation proceeds in two stages:

Input evaluation — the prompt text is evaluated before it reaches the model.
Output evaluation — the model response is evaluated before it is returned to the user.

The same policy chain is evaluated for both stages. Rules specify which direction they apply to (input, output, or both).

Evaluation order

The engine follows a Palo Alto firewall model:

1. User chain (personal overrides, if configured)
2. Org chain (primary policy chain)
   └─ Pack 1 → rules in sequence order
   └─ Pack 2 → rules in sequence order
   └─ Pack N → ...

Within each chain, packs are evaluated in the order they appear. Within each pack, rules are evaluated in sequence order. The evaluation stops as soon as a terminal rule matches (in first_applicable mode — see Combining algorithms).

If no rule matches anywhere, the default action is ALLOW.

Policy packs

A policy pack is a named collection of rules. Packs are the unit of organization within the Policy Engine.

There are two pack types:

Type	Description
Bundle	Pre-configured packs managed by Arbitex. Contain rules for specific compliance standards (PCI-DSS, HIPAA, GDPR, GLBA, SOX, CCPA, SEC 17a-4). Read-only.
Custom	Org-defined packs. You create and manage the rules.

Bundle packs

Bundle packs appear in the Policy Packs table with a lock icon. The rules inside bundle packs are read-only — Arbitex controls rule content and versions. You can enable or disable an entire bundle pack for your org, but you cannot modify individual rules within it.

Bundle packs are keyed to compliance standards:

Pack	Standard
PCI-DSS Bundle	PCI-DSS
HIPAA Bundle	HIPAA
GDPR Bundle	GDPR
GLBA Bundle	GLBA
SOX Bundle	SOX
BSA/AML Bundle	BSA/AML
CCPA Bundle	CCPA
SEC 17a-4 Bundle	SEC 17a-4

Custom packs

Custom packs are created by org admins. To create a custom pack:

Navigate to Settings → Policies → Policy Packs.
Click New Policy Pack.
Enter a name and optional description.
Click Create Pack.

The new pack is active by default with no rules. Add rules to it using the Policy Rule Editor.

Policy rules

Each rule within a pack defines:

Conditions — the criteria that must match for the rule to fire
Action — what happens when the rule fires
Direction — whether the rule applies to request input, model output, or both
Sequence — the order in which the rule is evaluated within the pack

Rules are evaluated in ascending sequence order within a pack. A rule with sequence 1 is evaluated before a rule with sequence 2.

Conditions

A rule matches when all of its conditions are satisfied (AND logic). Available condition types:

Condition	Description
`user_groups`	User must be a member of at least one of the listed groups
`entity_types`	DLP must have detected at least one entity of the specified types above the confidence threshold
`content_regex`	The prompt text must match the specified regular expression
`providers`	Request must be directed at one of the listed providers
`models`	Request must be directed at one of the listed models
`user_risk_score_min`	User risk score must be at or above the threshold
`intent_complexity`	Computed intent complexity must match (`simple`, `medium`, or `complex`)
`channel`	Request channel must be in the list (`interactive` or `api`)

A rule with no conditions set is an unconditional match — it matches every request.

Actions

Action	Terminal	Description
`ALLOW`	Yes	Request proceeds without modification
`BLOCK`	Yes	Request is rejected; user sees a block message
`CANCEL`	Yes	Request is silently cancelled
`REDACT`	No	Matched content is replaced with a redaction string; evaluation continues
`ROUTE_TO`	Yes	Request is routed to a specific model or tier instead of the originally requested model
`PROMPT`	Yes	User is presented with a governance challenge in the interactive channel
`ALLOW_WITH_OVERRIDE`	Yes	Request is allowed after user acknowledges an override message

REDACT is non-terminal. When a REDACT rule matches, the content is redacted and evaluation continues to the next rule. Multiple REDACT rules can accumulate before a terminal action is reached. All accumulated redactions are applied to the final request.

Combining algorithms

Each policy chain has a combining algorithm that determines how the rules within it interact when multiple rules match.

first_applicable (default)

The first terminal rule that matches wins. Subsequent rules are not evaluated. This is the standard firewall model.

Example:

Pack 1: Rule 1 (ALLOW, for group=engineering)
        Rule 2 (BLOCK, for entity_type=SSN)
Pack 2: Rule 1 (BLOCK, unconditional)

For a request from an engineering user with no SSN detected:

Pack 1, Rule 1 matches → action is ALLOW → evaluation stops
Pack 1, Rule 2 and Pack 2 are never reached

deny_overrides (XACML-style)

All rules across all packs are evaluated. Any rule with a BLOCK or CANCEL action takes precedence over any ALLOW. Use this mode when organizational policy requires that any explicit denial override all other rules regardless of sequence.

Behavior in deny_overrides mode:

BLOCK and CANCEL are immediately terminal — evaluation stops as soon as one fires
ALLOW and ROUTE_TO are collected but do not stop evaluation
REDACT is accumulated as usual
If no BLOCK or CANCEL fired, the most severe collected action is returned

What users see when a policy triggers

BLOCK

The user receives an error response. The block message is configurable per rule:

{
  "error": "Request blocked by policy",
  "message": "This request contains content that is not permitted under your organization's policy."
}

The specific message text is set by the admin in the rule’s action configuration.

CANCEL

The request is silently cancelled. The user receives a generic error (similar to a network timeout). No block message is shown. Use CANCEL when you want to suppress a request without revealing that a policy matched.

REDACT

The user’s prompt text reaches the model with matched content replaced by the configured redaction string (e.g., [REDACTED]). The user is not notified that redaction occurred unless the admin has configured a notification. The model responds based on the redacted text.

ROUTE_TO

The request is forwarded to a different model than the user requested — either a specific model (route_to_model) or a tier (haiku, sonnet, opus). The user receives a response, but from the routed model. No notification is shown to the user.

PROMPT (interactive channel only)

The user is presented with a governance challenge dialog before the request proceeds:

[Admin-configured challenge message]

[ Acknowledge and continue ]  [ Cancel ]

If the user acknowledges, the request is allowed. If the user cancels, the request is not sent. PROMPT only fires for channel=interactive requests (browser/SSE clients). API channel requests are not affected by PROMPT rules.

ALLOW_WITH_OVERRIDE

Similar to PROMPT, but the user sees an override acknowledgment message and explicitly consents before the request proceeds:

[Admin-configured override message]

[ I understand, continue ]  [ Cancel ]

Policy simulation

Before deploying a new rule or pack to production, use the Policy Simulator in the admin UI to test how a given request would be evaluated:

Navigate to Settings → Policies → Simulator.
Set the evaluation context: user, group memberships, provider, model, and sample prompt text.
Click Simulate.
The simulator returns the action that would be taken, the matched rule, and the evaluation trace.

The simulator evaluates against the currently saved (not yet published) policy configuration. Use it to verify rule behavior before enabling a new pack.

Common scenarios

Block requests containing SSNs from all users

Create a rule in a custom pack:

Direction: both
Condition: entity_types: ["SSN"], entity_confidence_min: 0.85
Action: BLOCK
Message: “Requests containing Social Security Numbers are not permitted.”

Allow engineering group to bypass a content restriction

Create a rule before the restriction rule in the same pack:

Direction: input
Condition: user_groups: ["engineering"]
Action: ALLOW
Sequence: lower number than the restriction rule

In first_applicable mode, the ALLOW for engineering fires first and stops evaluation.

Redact credit card numbers before forwarding to the model

Create a rule in a custom pack (or enable the PCI-DSS bundle):

Direction: input
Condition: entity_types: ["CREDIT_CARD"]
Action: REDACT
Redaction string: [CARD REDACTED]

Because REDACT is non-terminal, a subsequent rule can still ALLOW or BLOCK the request after redaction.

Route high-complexity prompts to a more capable model