Policy governance and compliance

The Arbitex Policy Engine provides a Palo Alto firewall-style governance model. Every AI request passes through the policy chain before reaching a model — and again when the model response is returned. This guide covers the governance model end-to-end: action types, how rules are evaluated, how group-based conditions work, and how to configure compliance policies for regulated industries.

For the full technical reference, see Policy Engine — Deep Dive. For PROMPT and ALLOW_WITH_OVERRIDE UX details, see Governance challenge actions.

Source: backend/app/services/policy_engine.py

---

Action types

The policy engine supports seven action types. Six are terminal — once matched, they stop chain evaluation. One (REDACT) is non-terminal and continues evaluation after applying text replacement.

Action	Terminal?	Severity	Description
ALLOW	Yes	0	Permits the request. Default when no rule matches.
PROMPT	Yes	1	Presents an interactive governance challenge. User must confirm before the request proceeds. Best for interactive channels only.
ROUTE_TO	Yes	2	Redirects to a different model or tier. Supports route_to_model (specific model ID) or route_to_tier (haiku/sonnet/opus mapped per provider).
REDACT	No	3	Applies text replacement and continues evaluation. Redacted text is replaced with [REDACTED] (configurable via redact_replacement). Multiple REDACT rules accumulate.
CANCEL	Yes	4	Silently cancels without processing. No error message returned to the caller.
BLOCK	Yes	5	Rejects the request with a configurable error message. Most restrictive action.
ALLOW_WITH_OVERRIDE	Yes	—	Allows but logs an override acknowledgment. Shows override_message to interactive users.

REDACT is the only non-terminal action. All other actions stop chain evaluation immediately when matched in first_applicable mode.

---

Combining algorithms

first_applicable (default)

Rules are evaluated in sequence order. The first matching terminal action wins. This is the default mode — firewall-style ordered evaluation. Rule sequence number determines priority: lower numbers are evaluated first.

deny_overrides

All rules are evaluated regardless of order. Any BLOCK or CANCEL action overrides any ALLOW. If no deny action is found, the most severe non-deny action wins, sorted by severity index. Use deny_overrides for conservative postures where any deny anywhere in the chain should kill the request, regardless of rule order.

---

Policy evaluation flow

Every request passes through a four-stage intake pipeline:

STAGE 1: INTAKE
  └─ Pre-log: partial audit entry (status="received")

STAGE 2: PARALLEL ANALYSIS
  ├─ Payload Analysis:
  │   ├─ Regex DLP (Tier 1)
  │   ├─ NER DLP (Tier 2)
  │   ├─ DeBERTa DLP (Tier 3)
  │   ├─ GeoIP enrichment
  │   ├─ CredInt check
  │   └─ Build PolicyContext with detected_entities
  └─ Quota/Rate Check:
      ├─ Plan tier request count
      ├─ Per-user/group quotas
      └─ Budget check

STAGE 3: POLICY EVALUATION
  └─ evaluate_policy_chain(db, context)
      ├─ USER scope chains (personal overrides — evaluated first)
      └─ ORG scope chains (primary policy chain)
      └─ Default: ALLOW if no rule matches

STAGE 4: AUDIT UPDATE
  └─ Update pre-log with full evaluation result
      ├─ matched_pack_id, matched_rule_id
      ├─ action_taken, stage_latencies
      └─ HMAC chain integrity

USER scope chains are always evaluated before ORG scope chains. This means personal overrides and whitelists take precedence over org-level policy. If a terminal match is found in the user chain, the org chain is never evaluated.

---

User groups and conditions

Condition logic

All non-None conditions within a rule are combined with AND logic — every condition must be satisfied for the rule to match. The one exception is user_groups, which uses OR logic within the list: the user must be a member of at least one listed group, not all of them.

Groups come from SCIM provisioning. They are conditions on rules, not separate chain scopes — there is no per-group chain. Group membership narrows which rules apply to a given user within a shared policy chain.

Condition reference

Condition	Type	Logic	Description
user_groups	list[str]	OR (any match)	User must be a member of at least one listed group
entity_types	list[str]	OR (any match)	DLP-detected entity type must be in list
entity_confidence_min	float	Threshold	Minimum DLP detection confidence (0.0–1.0)
content_regex	str	Pattern match	RE2-compatible regex applied to prompt text
providers	list[str]	OR (any match)	AI provider must be in list
models	list[str]	OR (any match)	Model ID must be in list
user_risk_score_min	float	Threshold	Minimum CredInt/GeoIP risk score
channel	list["interactive"|"api"]	OR	Request origin channel
intent_complexity	str	Exact match	Computed complexity: simple/medium/complex
model_risk_tier	list[str]	OR	Model risk tier from registry

---

Compliance bundles

Arbitex ships eight pre-built compliance bundles aligned to major regulatory frameworks. Each bundle includes a curated set of seed entity types and pre-configured REDACT and BLOCK rules.

Bundle	Framework	Seed Entity Types
PCI-DSS	PCI-DSS	credit_card, cvv, bank_account_number, ach_data
GLBA	GLBA	financial_account_numbers, ssn, account_balances, ein
SOX	SOX	financial_account_numbers, employment_info, contract_numbers, ein
BSA/AML	BSA/AML	ssn, bank_account_number, financial_account_numbers, ein
HIPAA	HIPAA	health_info, ssn, name, date_of_birth, ndc_code, hcpcs_code, icd10_code
GDPR	GDPR	name, email, telephone, ip_address, racial_ethnic_origin, political_opinions, religious_beliefs, health_info, biometric, genetic
CCPA	CCPA	name, email, ssn, geolocation, biometric
SEC Reg FD	SEC Reg FD	insider_info, material_contract, regulatory_action, bank_account_number, email

Bundle invariants

Bundle immutability. System compliance bundles cannot be modified by org admins. Only is_active can be toggled. Rule content, entity type seeds, and combining algorithm are locked.

Override protection. Bundle rules cannot be suppressed by org-level DLP suppressions. Violations are always written to the audit log with a compliance_bundle tag, regardless of any org-level suppression configuration.

Posture scoring. Compliance posture is calculated as enabled_bundle_count / total_available_bundles * 100, yielding a 0–100 score. This score is surfaced in the compliance summary endpoint and the admin dashboard.

---

Compliance scenarios

HIPAA compliance

The HIPAA bundle covers PHI entity types including health information, SSN, name, date of birth, and clinical coding systems (NDC, HCPCS, ICD-10). Typical configuration adds differentiated rules for clinical staff versus the rest of the organization.

// 1. Enable the HIPAA compliance bundle
// POST /api/orgs/{org_id}/compliance/bundles/{hipaa_bundle_id}

// 2. Add a PROMPT rule for healthcare worker groups
{
  "name": "PHI governance challenge",
  "applies_to": "input",
  "conditions": {
    "entity_types": ["health_info", "date_of_birth", "ssn"],
    "entity_confidence_min": 0.8,
    "user_groups": ["clinical-staff"],
    "channel": ["interactive"]
  },
  "action": {
    "type": "PROMPT",
    "prompt_message": "This request contains protected health information (PHI). HIPAA requires documented authorization before processing PHI through AI systems. Confirm you have patient authorization."
  }
}

// 3. Add a BLOCK rule for non-clinical groups
{
  "name": "PHI block — non-clinical",
  "applies_to": "input",
  "conditions": {
    "entity_types": ["health_info", "ssn"],
    "entity_confidence_min": 0.85
  },
  "action": {
    "type": "BLOCK",
    "message": "Protected health information detected. Contact your compliance officer for authorized PHI processing channels."
  }
}

Place the clinical-staff PROMPT rule before the catch-all BLOCK rule in the pack (lower sequence number). In first_applicable mode, clinical staff get the governance challenge while all other users hit the BLOCK rule.

---

PCI-DSS compliance

The PCI-DSS bundle auto-creates REDACT rules for primary account numbers (PAN) and CVV values. Supplement the bundle with explicit BLOCK rules for magnetic stripe data and an ALLOW_WITH_OVERRIDE rule for teams handling tokenized data.

// 1. Enable the PCI-DSS compliance bundle (auto-creates REDACT rules for PAN, CVV)

// 2. Add BLOCK rule for magnetic stripe data
{
  "name": "Block magnetic stripe data",
  "applies_to": "input",
  "conditions": {
    "content_regex": "(%B\\d{13,19}\\^|;\\d{13,19}=)"
  },
  "action": {
    "type": "BLOCK",
    "message": "Magnetic stripe data detected. Transmission of track data through AI systems violates PCI-DSS Requirement 3.2."
  }
}

// 3. Add ALLOW_WITH_OVERRIDE for finance team handling tokenized data
{
  "name": "Tokenized PAN — finance team override",
  "applies_to": "input",
  "conditions": {
    "entity_types": ["credit_card"],
    "user_groups": ["payment-processing"],
    "entity_confidence_min": 0.6
  },
  "action": {
    "type": "ALLOW_WITH_OVERRIDE",
    "override_message": "Possible payment card data detected. This interaction is logged for PCI-DSS compliance. If you are using tokenized data, you may proceed."
  }
}

---

GLBA / financial services

For financial services organizations subject to GLBA and SOX, enable both bundles and add routing and audit-passthrough rules for analyst workflows.

// 1. Enable both GLBA and SOX compliance bundles

// 2. Route financial analysis to lower-capability models
{
  "name": "Financial data — model downgrade",
  "applies_to": "input",
  "conditions": {
    "entity_types": ["financial_account_numbers", "account_balances"],
    "entity_confidence_min": 0.75
  },
  "action": {
    "type": "ROUTE_TO",
    "route_to_tier": "haiku"
  }
}

// 3. Audit-only rule for senior analysts
{
  "name": "Senior analyst — audit passthrough",
  "applies_to": "input",
  "conditions": {
    "user_groups": ["senior-analysts"],
    "entity_types": ["financial_account_numbers"]
  },
  "action": {
    "type": "ALLOW_WITH_OVERRIDE",
    "override_message": "Financial data access logged for GLBA/SOX compliance."
  }
}

---

Audit integration

Every policy decision is recorded in the audit log. The following fields are written for every evaluated request:

• matched_pack_id and matched_rule_id identify which policy pack and rule fired
• action_taken records the enforcement decision (ALLOW, BLOCK, REDACT, etc.)
• Override events — PROMPT confirmations and ALLOW_WITH_OVERRIDE acknowledgments — are logged with action type prompt_override or allow_with_override
• All audit records participate in the HMAC tamper-evident chain; records cannot be modified without breaking chain integrity
• Compliance bundle violations are tagged with compliance_bundle for filtered reporting and export
• Compliance posture reports are available via GET /api/v1/admin/compliance/summary

---

Admin API reference

Endpoint	Method	Description
/api/v1/admin/policy-packs/	GET/POST	List and create policy packs
/api/v1/admin/policy-packs/bundles/	GET	List system compliance bundles (read-only)
/api/v1/admin/policy-packs/{id}/rules/	GET/POST	List and add rules to a pack
/api/v1/admin/policy-packs/{id}/rules/reorder	POST	Reorder rules within a pack
/api/v1/admin/policy-chains/org	PUT	Update the org-level chain
/api/v1/admin/policy/simulate	POST	Simulate policy evaluation
/api/v1/admin/policy/effective/{user_id}	GET	View cascaded effective policy
/api/v1/admin/compliance/summary	GET	All-bundles compliance overview
/api/v1/admin/compliance/bundles/{id}/stats	GET	Per-bundle detection statistics

---

See also

• Policy Engine — Deep Dive
• Governance challenge actions — PROMPT and ALLOW_WITH_OVERRIDE
• Policy simulator
• Compliance frameworks
• Audit log management
• DLP pipeline configuration