Break-Glass (Emergency Bypass)

Break-Glass (Emergency Bypass)

Break-glass allows authorized users to bypass the normal approval workflow in emergencies. The operation executes immediately but is heavily audited.

Usage

dbward execute --emergency --reason "Production outage: fixing corrupted session data" \
  "DELETE FROM sessions WHERE user_id = 'broken_account'"

Both --emergency and --reason are required.

DDL bypass (schema repair)

To execute DDL statements that are blocked by sql_review rules in emergencies, add --allow-ddl:

dbward execute --emergency --allow-ddl --reason "Rebuild corrupted table" \
  "DROP TABLE broken_cache; CREATE TABLE broken_cache (id INT PRIMARY KEY, data TEXT)"

--allow-ddl bypasses sql_review rule blocks (e.g., drop_table = "block") for eligible DDL statements. These statements are no longer rejected by the classifier — they pass through as DestructiveDdl and are controlled by sql_review rules. --allow-ddl requires --emergency and the additional request.break_glass_ddl permission.

Bypassable (sql_review blocks): DROP TABLE/VIEW/INDEX/SEQUENCE, CREATE SEQUENCE, TRUNCATE, plus CREATE TABLE/VIEW/INDEX and ALTER TABLE in mixed repair batches.

Never bypassable: GRANT, REVOKE, CREATE ROLE/FUNCTION/DATABASE/SCHEMA, BEGIN/COMMIT, SET ROLE, LOAD DATA.

Requirements

Requirement	Detail
Permission	User must have request.break_glass_query (SELECT) or request.break_glass_dml (writes) — operator or admin role
Permission (DDL)	Additionally requires request.break_glass_ddl when using --allow-ddl
Reason	--reason is mandatory — explains why normal workflow was bypassed
Channel	CLI and API only — not available via MCP

What happens

1. SQL is classified and reviewed normally
2. If --allow-ddl: reviewer blocks on DDL sql_review rules are bypassed for eligible DestructiveDdl statements
3. Workflow lookup is skipped
4. Request status is set to BreakGlass (immediately dispatchable)
5. Agent picks up and executes the operation
6. All audit events are tagged with emergency context

Audit trail

Break-glass creates enhanced audit records:

• Event type: request.break_glass
• Includes: user, reason, SQL, result, timestamp
• Webhook notification fires with 🚨 indicator
• Prometheus metric: dbward_break_glass_total incremented

When --allow-ddl is used, an additional ddl_via_break_glass audit event is recorded with:

• Which safety layer was bypassed (sql_review block)
• Statement count
• Redacted SQL (literals replaced with ?)

Prometheus metrics for DDL bypass:

• dbward_break_glass_ddl_attempted_total — bypass was requested
• dbward_break_glass_ddl_allowed_total — bypass succeeded
• dbward_break_glass_ddl_denied_total — bypass was denied (non-bypassable statement)
• dbward_break_glass_audit_failure_total — audit write failed after bypass

Why MCP is blocked

AI assistants cannot use break-glass because:

• Emergency access requires explicit human intent
• AI-generated reasons could mask unauthorized access
• The audit trail must reflect a conscious human decision

If you need to execute emergency SQL while in an AI session, switch to a terminal and use the CLI directly.

Configuration

Break-glass permission is granted via roles. By default, only admin has it:

# DML-only emergency role (SELECT emergencies require request.break_glass_query instead)
[[auth.roles]]
name = "oncall"
permissions = ["request.break_glass_dml", "request.dml", "request.view"]

For SELECT and write emergencies combined:

[[auth.roles]]
name = "oncall-full"
permissions = ["request.break_glass_query", "request.break_glass_dml", "request.dml", "request.query", "request.view"]

To also allow DDL bypass in emergencies:

[[auth.roles]]
name = "oncall-senior"
permissions = ["request.break_glass_query", "request.break_glass_dml", "request.break_glass_ddl", "request.ddl", "request.dml", "request.query", "request.view"]

Limitations

• Privilege DDL (GRANT, REVOKE, CREATE ROLE/FUNCTION/DATABASE) is always blocked — even with --emergency --allow-ddl
• Transaction control (BEGIN, COMMIT, ROLLBACK) is always blocked
• Break-glass does not bypass SQL classification or review for DML safety rules (e.g., DELETE without WHERE)
• --allow-ddl bypasses sql_review blocking only for DestructiveDdl statements (DROP TABLE/VIEW/INDEX/SEQUENCE, TRUNCATE, CREATE SEQUENCE)
• Results are still stored and access-controlled normally
• MCP channel cannot use break-glass or --allow-ddl

See also

• Workflows — normal approval flow
• Authorization — permission system
• Security Checklist — restricting break-glass access