Break-glass: deny-all by default, and a designed narrow override

Decision records, eight of ten. One architecture decision per piece, from a governed AI-agent platform I designed and built as a prototype for Dutch local government.

The situation

The approval service is the component that binds a human yes to a specific action. If it is unavailable, no consequential action can be approved, and the platform’s rule is that unapproved consequential actions do not happen. So far, so correct.

Now it is a Thursday afternoon, the approval service is down, and work is queuing. Benefit decisions that need a caseworker’s sign-off. Letters that need to go out before a legal deadline. The choice looks like: fail closed and let the queue grow, or stay available and let something through.

What actually happens in most organisations is a third thing. Someone finds a way around. A database flag, a config change, a direct call to the tool server. It is invented under pressure, it leaves no evidence, and it is never removed afterwards because it worked. The undesigned override becomes the real bypass, and the carefully built approval service becomes the path for ordinary days only.

Every organisation has a break-glass procedure. The only question is whether it was designed on a Tuesday with coffee or discovered on a Friday at five with a database flag.

The decision

Default deny-all, with a break-glass path designed in advance and deliberately narrow.

Deny-all means: when approval is unavailable, runs that need it suspend durably. They are persisted with their full state and resume when the service returns. Authority never widens because a component is down. A run that was waiting for a caseworker is still waiting for a caseworker.

The break-glass path has five properties, and all five are required.

It is activated by a named human. Never by a service, never by a model, never automatically. Someone puts their name on it.

It is time-boxed. There is no standing activation. It expires, and extending it is a new activation by a named human.

It is fully evidenced and louder than normal operation. Every action under break-glass is recorded with the activation, the activator and the reason, and the records are flagged so that they are impossible to miss in any later review.

It is limited to reads and compensable operations. Things that can be undone or corrected afterwards. Looking up a case, drafting a letter, staging a decision for later approval.

Irreversible consequential actions stay denied, with no exception. Sending the letter, finalising the decision, moving the money. Break-glass does not open those. Nothing does, until approval is back.

Every activation is reviewed afterwards. And repeated activation is treated as a design signal: if people keep breaking the glass, the normal path is wrong and the fix is in the normal path, not in making the glass thinner.

What I rejected, and why

Pure deny-all with no override. Honest, simple, and it does not survive the Thursday afternoon. The override gets invented mid-incident by whoever is closest to the database, and the platform has lost control of its own bypass. Designing the override is how you keep ownership of it.

Full-authority break-glass. Activate it and everything is allowed. That is a standing repeal of the non-bypassable rule, dressed up as an emergency measure. The first time it is used for convenience rather than emergency, which will be soon, the rule is gone.

Auto-approve after a deadline. If the approval service does not answer in an hour, treat the action as approved. A timeout looks exactly like a considered yes in the record, and nobody can later tell them apart. This is the option that sounds most reasonable and is most corrosive.

What it costs

A separate, versioned break-glass policy bundle. It is not a flag on the normal bundle; it is its own artefact with its own golden tests, so that the narrow set of what is allowed under break-glass is as reviewed and as testable as the normal policy. Durable suspension for runs, which means run state has to be fully serialisable and resumable, a requirement that shaped the run model more than I expected.

And a named role before production. Someone has to be the person who can activate it, with a backup, and that is an organisational decision the prototype cannot make for a municipality.

What it does not do

It does not keep the queue short. Deny-all means work waits, and break-glass only lets the preparatory part proceed. The citizen whose letter has a deadline still needs the approval service back, or a human doing the approval by hand through a path that is itself evidenced.

The break-glass bundle and the suspension mechanism were designed and the suspension was partly built. The review workflow for activations was described, not implemented. Whether the five properties hold under a real incident is untested.

If you take one thing

Ask your team what they would do if your approval system were down for a day. If the answer involves a flag, a script or a direct call that is not written down anywhere, that is your current break-glass, and it has none of the five properties.

A full-authority override is the Black Knight of incident response: both arms off, still insisting it is only a flesh wound and that the fight can continue.

References

The allusions and quotations in this piece, with their origin:

• Monty Python and the Holy Grail (1975): the Black Knight, “’tis but a scratch”, “it’s just a flesh wound”.