Yes, but carefully. A break glass procedure lets a named human temporarily widen an agent's access, or override a block, during a real emergency. It must be rare, logged, time limited and reviewed afterward, or it turns into the easiest way around your own controls.
Two meanings, often confused
Break glass can mean two opposite things with agents.
The first is emergency access for the agent: it needs a permission it does not normally hold to fix an outage. The second is emergency stop: a person needs to cut the agent off immediately. The second is more important, and it should be easier than the first. A kill switch should need one action. Emergency widening should need more friction.
Rules for emergency access
| Rule | Reason |
|---|---|
| A human invokes it, never the agent | The agent cannot grant itself rights |
| Two named people for production | Prevents solo misuse under pressure |
| Short fixed window, such as an hour | Access ends without anyone remembering |
| Narrowest widening that solves the problem | Emergencies tempt people to grant everything |
| Every use creates a ticket | Gives review something to examine |
| Extra logging while active | Shows exactly what happened |
| Review within a few days | Closes the loop and finds abuse |
Design steps
- Decide what emergencies justify it. Write three or four examples, such as a production outage with revenue impact, and a clear list of what does not count.
- Define the break glass identity or role separately from the normal one. Never edit the agent's standing role during an emergency, because people forget to change it back.
- Require the invoker to state the reason and link an incident or ticket.
- Make the grant expire automatically, and alert the on call lead when it is used.
- Keep the credential or approval path out of the agent's reach. OWASP's guidance on excessive agency supports this: authorization belongs in downstream systems, not in the model's judgment.
- After use, review every action taken under the elevated rights, and record the outcome.
Common failure modes
The grant has no expiry, so it stays for months. The procedure is used for convenience, because it is faster than the normal request. The review never happens. One person holds all the keys. Alerts go to a mailbox nobody reads.
Track how often it is used. Frequent use means the normal path is too slow or too narrow. Fix that rather than normalizing the exception.
Test it before you need it
Run a drill in a non production environment. Time how long it takes to invoke, check that logs capture the actions, confirm that the access really expires, and verify that the agent cannot trigger the process itself. Run the stop path too: how many seconds from decision to the agent being unable to call tools?
Link to incident response
Break glass is a sibling of your incident plan. The runbook should say who may invoke it, where the audit record lives and who reviews it. Keep that review separate from the person who used the access.
Safeguard offers policies, gates and guardrails and agent identity capabilities that you can use to scope emergency roles. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should the agent be able to request break glass itself?
It can raise a request for a human to consider, but only a person should grant it.
Is the kill switch part of break glass?
Related, but separate. Stopping an agent should be quicker and simpler than widening its access.
Sources
Last reviewed: 19 October 2026.
