Break-Glass Access

Sometimes somebody genuinely needs a record they are not cleared for. Break-glass provides that, on terms.

Where to find it

Architect Panel → Security:

• Break-Glass Access — every break-glass event, with its reason and expiry
• Classification Levels — levels that require break-glass to open

Architect Panel → Activity:

• Record Read Log — what was actually read during the access

The problem it solves

Access control that cannot be overridden fails in emergencies, and an organisation that has been unable to reach information when it mattered will loosen its controls permanently afterwards.

Break-glass is the alternative: keep the controls tight, and provide a deliberate, recorded, time-limited way through. That is a better outcome than a control that gets relaxed because it broke once.

What is recorded

• The record — datastore and row.
• The person, by three-part identity.
• The reason.
• Opened at and expires at.
• The IP address.

Bounded to one record

An event grants access to a specific record, not to a level or a datastore. Somebody who needs three records opens three events with three reasons.

That is deliberate friction. Access broad enough to be convenient is access broad enough to be misused, and the per-record scope is what keeps the reasons specific enough to review.

Bounded in time

Access expires. An emergency is a moment, not a state, and access that persists after the emergency is simply elevated access nobody decided to grant.

Set the window short — long enough to do the thing, not long enough to be forgotten about.

The reason is required, and it is the point

Everything else here is mechanism. The reason is what makes break-glass reviewable, and it is written before access is granted, while the person still has to justify themselves to themselves.

That ordering matters. A justification demanded afterwards is a rationalisation; one demanded first is a decision.

When to require it

Set the highest classification levels to require break-glass, and consider it on datastores where access is legitimate but exceptional — another team's cases, records about staff, anything where the right answer is usually no.

It is not a permission model

If break-glass is being used routinely, the underlying access is wrong. Frequent use for the same reason means somebody's ordinary work needs a permission they have not been given, and the fix is to grant it properly rather than to normalise the emergency route.

Worked example

An out-of-hours duty officer needs a case held by another team to respond to an incident. They open break-glass with the reason and the incident reference, read what they need, and the access lapses. The following week the record is reviewed as routine, the reason matches a real incident, and nothing further is required — the whole exchange took a minute and left a complete account.

Recommendations

• Keep the window short.
• Require it on the top classification levels.
• Never use it as a substitute for a permission somebody needs routinely.
• Make people write a specific reason, not "urgent".