ALLOW_WITH_OVERRIDE governance

ALLOW_WITH_OVERRIDE is a policy action that gives users a structured path to override a policy match. When a rule fires with this action, the request does not proceed automatically. Instead, the gateway returns an override prompt to the user. The user must acknowledge the detection and provide a reason before the request is forwarded to the AI provider. The acknowledgement, the reason, and the original detection are all written to the audit log.

This is distinct from BLOCK (which denies without recourse) and PROMPT (which holds for admin review). ALLOW_WITH_OVERRIDE delegates the override decision to the requesting user, while ensuring a full audit record exists for compliance review.

How ALLOW_WITH_OVERRIDE works

A request arrives at the gateway and passes through the DLP pipeline (Tier 1 regex → Tier 2 NER → Tier 3 DeBERTa).
The Policy Engine evaluates the rule chain. A rule fires with action = ALLOW_WITH_OVERRIDE.
The gateway returns HTTP 200 with override_required: true and a short-lived override_token (JWT, 5-minute expiry).
The client presents the override prompt to the user, who must provide a written reason.
The user re-sends the original request with the override_token header and the reason field.
The gateway validates the token (signature, expiry, binding to the original request). On success, it:
- Logs the override audit record (user, org, rule, detected entity type, reason, timestamp).
- Forwards the original request to the AI provider.
- Returns the provider response to the client.
If the token has expired or is invalid, the gateway returns HTTP 403.

The override token is single-use. Re-sending the same token a second time is rejected.

User experience

When a rule fires with ALLOW_WITH_OVERRIDE, the client receives a structured JSON response instead of a normal completion:

{
  "override_required": true,
  "override_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "detection": {
    "rule_id": "finance-pii-review",
    "entity_type": "credit_card",
    "confidence": 0.94
  },
  "expires_in": 300,
  "message": "This request matched a policy rule. Provide a reason to proceed."
}

The client is expected to surface this to the user with a reason input field. The Arbitex web client renders an inline override prompt in the conversation view.

To proceed, the client re-sends the original request with two additional fields:

POST /api/chat/completions
Authorization: Bearer <user_token>
X-Override-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "model": "gpt-4o",
  "messages": [...],
  "override_reason": "This is synthetic test data for QA validation, not real cardholder data."
}

If the override succeeds, the response is a normal chat completion.

Configuring ALLOW_WITH_OVERRIDE rules

Add ALLOW_WITH_OVERRIDE as the action in any policy rule using the PolicyBuilder UI or the policy rule API.

UI: Admin > Policy Engine > Policy Rules > create or edit a rule > set Action to Allow with Override.

API:

{
  "name": "finance-pii-override-required",
  "conditions": {
    "user_groups": ["finance"],
    "entity_types": ["credit_card", "bank_account"],
    "entity_confidence_min": 0.80
  },
  "action": {
    "type": "ALLOW_WITH_OVERRIDE"
  }
}

Rule placement in chains

ALLOW_WITH_OVERRIDE is a terminal action — it stops chain evaluation for the current request and issues the override prompt. Place it after more-restrictive rules (BLOCK, CANCEL) in the evaluation chain so that hard blocks fire first.

Example chain order for a finance group:

Priority	Rule	Action
1	Credentials in prompt	`BLOCK`
2	Social security numbers	`BLOCK`
3	Credit card numbers — finance group	`ALLOW_WITH_OVERRIDE`
4	All other traffic	`ALLOW`

Choosing ALLOW_WITH_OVERRIDE vs BLOCK vs PROMPT

Scenario	Recommended action
Match should always be rejected — no exceptions	`BLOCK`
Match requires a human admin to review before proceeding	`PROMPT`
Match is a warning; the user may legitimately proceed with a justified reason	`ALLOW_WITH_OVERRIDE`
Match should be logged but not blocked	`LOG_ONLY`

Use ALLOW_WITH_OVERRIDE when the detection is likely but not certain to represent a violation — for example, content that could be real PII or could be synthetic test data. The override mechanism creates accountability without hard blocking legitimate work.

Override token expiry

The override token expires 5 minutes after it is issued. If the user does not re-send the request within that window, the token is rejected and the user must initiate the original request again (which will trigger a fresh override prompt).

The 5-minute window is fixed and not configurable at the rule level.

Audit trail

Every override is written to the audit log before the request proceeds to the AI provider. The audit record contains:

Field	Description
`action`	`"allow_with_override"`
`user_id`	ID of the user who acknowledged the override
`org_id`	Organization ID
`rule_id`	ID of the rule that triggered the override
`detected_entity_type`	Entity type detected at the time the rule fired
`override_reason`	Verbatim reason text supplied by the user
`timestamp`	UTC timestamp of the override
`request_id`	Correlation ID linking the override to the original request log entry

Querying override audit entries

Filter the audit log for action = "allow_with_override" to see all override events:

GET /api/admin/audit-logs?action=allow_with_override&limit=100

The response includes each override with the full field set above. Use the user_id, rule_id, and timestamp fields to identify patterns — for example, users who frequently override a specific rule.

Admin UI: Admin > Audit Log > filter by Action = Allow with Override. The results table shows who overrode what and when, with the reason text visible on row expand.

Override analytics

The admin dashboard shows override frequency metrics under Admin > Analytics > Override Activity:

Override count per rule (daily / weekly view)
Override count per user
Trend line: overrides over time

High override rates on a specific rule may indicate the rule threshold is too aggressive for the group it targets, or that a group needs training on data handling practices. Review override patterns periodically as part of your governance cadence.

Alert on override frequency: you can configure an alert rule to fire when overrides for a given rule exceed a threshold within a rolling window. See Admin operations for alert configuration.

Compliance implications

SOX

Override audit entries provide an evidence trail for internal controls over financial data. For SOX environments, the audit log export (see Audit log verification) can be included in control testing documentation to demonstrate that policy exceptions are tracked and attributable.

GLBA

GLBA requires logging of authorized access to customer financial information. ALLOW_WITH_OVERRIDE records who accessed or attempted to use information matching financial data patterns, and why. The reason field provides the business justification the auditor would otherwise have to obtain separately.

General compliance posture

Unlike BLOCK (which prevents access) or silent ALLOW (which leaves no record), ALLOW_WITH_OVERRIDE occupies a middle tier: access is permitted but recorded with justification. This is appropriate for scenarios where blanket blocking would impede legitimate business operations but a full audit trail is required for oversight.

Override records are included in compliance exports. See Compliance frameworks for framework-specific requirements.

Monitoring override frequency alerts

Configure an alert rule to notify on high override volume:

{
  "name": "high-override-rate",
  "condition": {
    "metric": "override_count",
    "rule_id": "finance-pii-override-required",
    "threshold": 20,
    "window_minutes": 60
  },
  "action": {
    "type": "webhook",
    "webhook_id": "wh_01abc123"
  }
}

See Admin operations — alerts for the full alert configuration reference.