Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Emergency bypass allows authorized operators to temporarily override RECALL suppression rules when a critical situation requires immediate access to suppressed context. Every bypass is fully audited — the audit log records the bypass event with the reason code EMERGENCY_BYPASS, the operator who activated it, and the timestamp. Emergency bypass is a safety valve, not a workflow. It exists for scenarios where strict suppression rules would prevent an agent from accessing information needed to resolve an urgent incident.

​
When to Use Emergency Bypass

Emergency bypass is intended for situations where:
  • A production incident requires an agent to access restricted documents for diagnosis
  • A security investigation needs an agent to review suppressed context for threat analysis
  • A compliance review requires temporary access to data normally denied by trust tier rules
  • A system failure has caused RECALL to deny context that should be allowed (misconfigured rules)
Emergency bypass should never be used as a routine workflow. If you find yourself using bypass frequently, your trust tier assignments or suppression rules need adjustment. Frequent bypass usage is a signal that your policy configuration does not match your operational reality.

​
How It Works

1

Operator activates bypass

An authorized operator activates emergency bypass for a specific agent or vendor scope. The activation includes a mandatory reason string that is recorded in the audit log.
2

RECALL rules are overridden

During the bypass window, the suppression engine returns allow for all evaluation requests within scope, regardless of trust tier, surface, or rule configuration. The original decision that would have been made is still computed and logged for audit purposes.
3

Every decision is marked

All decisions made during the bypass period carry the reason code EMERGENCY_BYPASS. The audit log entry includes the bypass reason, the operator who activated it, and the original decision that would have been applied.
4

Bypass expires or is deactivated

The bypass has a configurable time window (default: 1 hour). When the window expires or the operator manually deactivates it, normal suppression rules resume. There is no grace period — the transition is immediate.

​
Reason Codes

When emergency bypass is active, the audit log uses the EMERGENCY_BYPASS reason code. The metadata field on the audit log entry contains additional context:
Metadata FieldDescription
bypass_reasonThe operator-provided reason for activating bypass
bypass_activated_byEmail or identifier of the operator who activated bypass
bypass_activated_atISO 8601 timestamp of bypass activation
original_decisionThe decision that would have been made without bypass
original_reason_codeThe reason code that would have been used without bypass

​
Audit Trail

Emergency bypass creates a clear audit trail that distinguishes bypass decisions from normal policy decisions: 
{
  "id": "audit-entry-uuid",
  "agent_id": "research-bot",
  "operation": "retrieve",
  "resource_type": "document",
  "decision": "allow",
  "reason_code": "EMERGENCY_BYPASS",
  "reason": "Emergency bypass active — original decision: deny (TIER_MISMATCH)",
  "rule_id": null,
  "receipt_id": "receipt-uuid",
  "metadata": {
    "bypass_reason": "Production incident #1234 — need access to restricted infrastructure docs",
    "bypass_activated_by": "ops-lead@company.com",
    "bypass_activated_at": "2026-04-13T10:00:00Z",
    "original_decision": "deny",
    "original_reason_code": "TIER_MISMATCH"
  },
  "created_at": "2026-04-13T10:05:00Z"
}
The receipt_id field is still populated — bypass decisions receive cryptographic receipts just like normal decisions. This means every bypass decision has tamper-evident proof.

​
Querying Bypass Events

Use the audit log API to query bypass events: 
curl -X GET 'https://api.visiq.ai/recall/audit-log?reason_code=EMERGENCY_BYPASS&start_date=2026-04-13T00:00:00Z' \
  -H "Authorization: Bearer <session_token>"
Filter by reason_code=EMERGENCY_BYPASS to see all bypass decisions in a time range. This is useful for:
  • Post-incident reviews to understand what data was accessed during bypass
  • Compliance reporting to demonstrate that bypass usage is documented and justified
  • Trend analysis to identify patterns that suggest rule configuration improvements

​
Best Practices

Require a reason

Always require a meaningful reason string when activating bypass. Generic reasons like “testing” or “needed” provide no audit value. The reason should reference an incident number, ticket, or specific operational justification.

Minimize scope

Activate bypass for the narrowest scope possible. If only one agent needs access, bypass only that agent. If only one document classification needs to be unblocked, consider adjusting the rule instead of using bypass.

Set short windows

Use the shortest bypass window that covers the operational need. The default 1-hour window is a maximum, not a target. Deactivate bypass manually as soon as the immediate need is resolved.

Review after incidents

After every bypass event, review the audit log to understand what data was accessed. Use this review to determine whether the suppression rules need adjustment to prevent future bypass needs.