Policy Engine Administration

The Arbitex policy engine evaluates every AI request against an ordered sequence of policy packs. Each pack contains rules that match on request properties (groups, entity types, content patterns, and more) and apply an action when matched. This guide covers all policy administration tasks available under Admin → Policy.

Concepts

• Policy pack — a named collection of rules. Two types exist: bundle packs (managed by Arbitex, read-only) and custom packs (defined by your org, fully editable).
• Policy rule — a condition/action pair within a pack. Each rule specifies when it fires (conditions) and what to do (action). Rules within a pack are evaluated in sequence order.
• Policy chain — the ordered list of packs evaluated for every request. Evaluation proceeds top-to-bottom across packs, and within each pack, rule by rule in sequence order.
• Combining algorithm — controls how the chain resolves multiple matching rules (first match wins vs. deny overrides).

---

Policy Packs

Navigate to Admin → Policy → Packs to see the full list of policy packs.

Pack types

Type	Icon	Description
Bundle	Lock	Arbitex-managed compliance pack. Read-only; you can enable or disable it but cannot add, edit, or delete its rules. Labeled Managed by Arbitex.
Custom	—	Org-defined pack. Full CRUD access to rules.

View pack rules

Click the expand arrow on any pack row to see its rules. Each rule row shows:

• Sequence number
• Rule name
• Direction (input / output / both)
• Action type badge
• Active / inactive status
• Edit button (custom packs only)

Create a custom pack

1. Navigate to Admin → Policy → Packs.
2. Click New Pack.
3. Enter a Name and optional Description.
4. Click Create. The pack is created with is_active: true and added to the list.

Enable or disable a pack

Toggle the active/inactive switch on any pack row to enable or disable it without deleting it. Disabled packs are skipped during chain evaluation.

Delete a custom pack

Click Delete on a custom pack row and confirm. Bundle packs cannot be deleted.

API reference

# List all policy packs
GET /api/admin/policy-packs/

# Create a custom pack
POST /api/admin/policy-packs/
{
  "name": "Engineering Overrides",
  "description": "Custom rules for the engineering group",
  "pack_type": "custom",
  "version": "1.0",
  "is_active": true
}

# Update a pack (name, description, is_active)
PUT /api/admin/policy-packs/{pack_id}

# Delete a custom pack
DELETE /api/admin/policy-packs/{pack_id}

---

Policy Rules

Rules live inside custom packs. Click the expand arrow on a custom pack row, then click + Add Rule to open the rule editor.

Conditions

Each rule can match on any combination of the following conditions. All specified conditions must match for the rule to fire (logical AND).

Condition	Type	Description
User groups	Tag list	Matches requests from users who belong to any of the listed groups (logical OR within the list)
Entity types	Multi-select chips	Matches when the DLP pipeline detects any of the selected entity types in the request content (e.g., credit_card, ssn, api_key, bearer_token)
Entity confidence min	Slider (0–1)	Only shown when entity types are selected. Minimum confidence score for the detection to trigger the rule.
Content regex	Text + Test button	Matches when the request content matches the provided regular expression. Click Test to validate the regex against a sample string using /api/admin/dlp-rules/test.
Providers	Multi-select chips	Matches requests routed to any of the selected AI providers
Models	Tag list	Matches requests targeting any of the listed model IDs
User risk score min	Number (0–1)	Matches users whose calculated risk score meets or exceeds this threshold
Channel	Checkboxes	Matches requests from interactive (web UI) or api (programmatic) channels, or both
Intent complexity	Radio (simple / medium / complex)	Only shown when no entity types are selected. Matches based on the detected complexity of the user’s intent.

A rule with no conditions matches all requests.

Direction

Specify when the rule applies:

• Input — evaluate on the user’s prompt before it is sent to the model
• Output — evaluate on the model’s response before it is returned to the user
• Both — evaluate on both the prompt and the response

Actions

Each rule has exactly one action:

Action	Description
ALLOW	Explicitly permit the request. Stops evaluation (terminal).
BLOCK	Reject the request. Optional: provide a custom message returned to the user. Terminal.
CANCEL	Cancel the in-flight model call and return an error. Terminal.
REDACT	Replace matched content with a redaction string (default: [REDACTED]). You can set a custom replacement string. Non-terminal — evaluation continues after redaction.
ROUTE_TO	Redirect the request to a specified tier (haiku / sonnet / opus) and optionally a specific model. Terminal.
PROMPT	Surface a challenge message to the user before proceeding. Terminal.
ALLOW_WITH_OVERRIDE	Permit the request but record that the user acknowledged a policy notice. Provide the notice message. Terminal.

Note

REDACT is the only non-terminal action. A request can be redacted by multiple rules in sequence before a terminal action fires.

Create or edit a rule

1. Expand a custom pack and click + Add Rule (or the edit pencil on an existing rule).
2. Enter a Rule Name.
3. Set the Direction (input / output / both).
4. Configure one or more Conditions.
5. Select an Action and fill in any action-specific fields.
6. Click Save Rule.

API reference

# Create a rule in a pack
POST /api/admin/policy-packs/{pack_id}/rules/
{
  "name": "Block SSN in output",
  "applies_to": "output",
  "conditions": {
    "entity_types": ["ssn"],
    "entity_confidence_min": 0.85
  },
  "action": "BLOCK",
  "action_config": {
    "message": "Social security numbers cannot be returned in responses."
  },
  "is_active": true
}

# Update a rule
PUT /api/admin/policy-packs/{pack_id}/rules/{rule_id}

# Test a regex condition
POST /api/admin/dlp-rules/test
{ "pattern": "\\b\\d{9}\\b", "sample": "My SSN is 123456789" }

---

Policy Chain

The policy chain defines the evaluation order of packs. Navigate to Admin → Policy → Chain to manage it.

How evaluation works

Packs are evaluated top-to-bottom. Within each pack, rules are evaluated in sequence order. The first terminal match (BLOCK, CANCEL, ALLOW, ROUTE_TO, PROMPT, ALLOW_WITH_OVERRIDE) stops evaluation. REDACT is non-terminal and does not stop evaluation.

Reorder packs

Drag a pack card to a new position using the drag handle, or use the ↑ / ↓ buttons to move a pack up or down in the chain. Changes take effect after you save.

Combining algorithm

Algorithm	Behavior
First match (first_applicable)	The first terminal rule that matches determines the outcome. Recommended for most organizations.
Deny overrides (deny_overrides)	Any BLOCK or CANCEL match in any pack overrides ALLOW matches. Use when strict blocking policy is required.

Select the algorithm from the dropdown in the chain editor header.

Group filter

Use the Group filter dropdown to preview how the chain applies to a specific group. When a group is selected:

• Packs containing rules that match the group are highlighted with a Has rules for this group badge.
• Non-matching packs are dimmed.
• A posture summary shows the count of ALLOW, DENY (BLOCK/CANCEL), and REDACT rules from matching packs.

The selected group is saved to sessionStorage and used to pre-fill the group field in the Policy Simulator.

Save the chain

Click Save Chain to persist the current pack order and combining algorithm.

PUT /api/admin/policy-chains/org
{
  "packs": [
    { "id": "<pack-uuid>", "sequence": 1 },
    { "id": "<pack-uuid>", "sequence": 2 }
  ],
  "combining_algorithm": "first_applicable"
}

---

Policy Simulator

The simulator lets you test the policy chain against a sample request before deploying changes. Navigate to Admin → Policy → Simulator.

Run a simulation

1. Enter a Prompt — the text content to evaluate.
2. Optionally select a Provider and enter a Model to test provider/model-specific rules.
3. Add one or more User groups to simulate the groups the requesting user belongs to. If you set a group filter in the chain editor, it pre-fills here.
4. Click Run Simulation.

Interpret results

The result panel shows:

Field	Description
Action	The final decision (ALLOW / BLOCK / CANCEL / REDACT / ROUTE_TO), color-coded
Matched pack	The name of the pack that produced the terminal match
Matched rule	The name of the specific rule that fired
Match reason	A human-readable explanation of what condition triggered the match
Action details	JSON payload of the action configuration (e.g., the BLOCK message or the ROUTE_TO tier)

Evaluation trace

Below the result, the Evaluation trace shows every pack and rule evaluated, in order. Each row shows:

• Pack name → rule name
• Pass (✓) or fail (✗) indicator
• “group match” tag when the user_groups condition was the trigger

Use the trace to understand why a particular rule fired and which earlier rules were skipped.

API reference

POST /api/admin/policy-chains/simulate
{
  "prompt": "My SSN is 123-45-6789",
  "provider": "anthropic",
  "model": "claude-sonnet-4-6",
  "user_groups": ["engineering", "contractors"]
}

# Response:
{
  "matched": true,
  "matched_pack_name": "PCI-DSS Bundle",
  "matched_rule_name": "Block SSN in input",
  "action": "BLOCK",
  "match_reason": "Entity type ssn detected with confidence 0.97",
  "evaluation_trace": [
    {
      "pack": "Allow All Bundle",
      "rule": "Default allow",
      "passed": false,
      "tags": []
    },
    {
      "pack": "PCI-DSS Bundle",
      "rule": "Block SSN in input",
      "passed": true,
      "tags": ["group match"]
    }
  ]
}

---

Custom DLP Patterns

The Pattern Browser under Admin → Policy → Patterns shows all active DLP detection patterns and allows you to create org-specific regex-based patterns.

Browse patterns

Patterns are organized by category:

• secret — API keys, tokens, credentials
• pii — names, emails, phone numbers, government IDs
• financial — card numbers, bank accounts, routing numbers
• medical — diagnoses, drug names, patient identifiers
• infrastructure — IP addresses, hostnames, internal URLs

Use the category filter chips and search box to locate patterns. Each PatternCard shows the pattern name, entity type, confidence threshold, and action tier badge.

Action tiers

Tier	Behavior
log_only	Log the detection event; allow the request to proceed unmodified
redact	Replace the matched content with a redaction marker
block	Block the request
prompt	Surface a challenge to the user before proceeding

Create a custom pattern

1. Navigate to Admin → Policy → Patterns.
2. Click New Pattern.
3. Fill in the fields:

Field	Description
Detector name	Human-readable identifier for this pattern
Entity type	The semantic category this pattern detects (e.g., internal_project_code)
Action tier	What happens when the pattern matches (log_only / redact / block / prompt)
Confidence threshold	Minimum match confidence (0–1, step 0.05) required to trigger the action
Regex pattern	A valid Python-compatible regular expression

4. Click Save Pattern.

API reference

# Create a custom regex DLP pattern
POST /api/admin/dlp-rules/
{
  "detector_name": "Project codename detector",
  "detector_type": "regex",
  "entity_type": "internal_project_code",
  "action_tier": "redact",
  "enabled": true,
  "confidence_threshold": 0.9,
  "config_json": {
    "pattern": "\\bPROJ-[A-Z]{2,6}-\\d{3,6}\\b"
  }
}

---

See also

• Policy Engine Overview — architectural overview and concepts
• Policy Rule Reference — complete condition and action field reference
• DLP Overview — DLP pipeline stages and detector types
• Allow-with-Override — user-facing override workflow
• User and Group Management — managing groups referenced in policy rules
• Routing and Model Controls — configuring the ROUTE_TO action targets