Break-glass runbook: regain control of AI agents

Agent-controlled systems need an emergency procedure before they need another permission setting. When an agent can call an API, open an SSH session, modify a deployment, or send data to an external service, a human must be able to stop the work, remove authority, and reconstruct what happened under pressure.

A break-glass runbook does not make an unsafe design safe. It gives people a way to contain uncertainty before it becomes damage. The useful version fits on a page for the first fifteen minutes, identifies actual authority rather than job titles alone, and has been tested by people who were not involved in writing it.

Emergency authority must belong to named roles

A break-glass runbook works only when it says who may act without seeking further permission. "The platform team" and "security" are not answers at 02:00, especially when several people assume someone else owns the decision.

Assign four roles, then map each role to current people and alternates. The same person may hold two roles in a small team, but do not let one person hold every role.

• The incident lead declares emergency mode, sets the immediate objective, and records decisions.
• The access revoker disables the agent session, its action channel, or the credentials it can reach.
• The service owner decides whether a critical workload can safely pause and validates recovery.
• The recorder maintains a timestamped event log and protects the evidence package.

The access revoker needs technical authority before an incident. That means they can disable the relevant agent process, remove access at the action boundary, and request credential rotation where that is required. Giving them an emergency phone number but not the necessary console access creates a ceremonial role.

Use two revokers, a primary and an alternate, from different reporting lines where possible. A service owner can object to a lengthy outage, but they should not be able to veto initial containment when the incident lead believes an active agent may be unsafe. You can restore service after you understand the situation. You cannot undo an external API request or a destructive SSH command.

Put these details in the runbook for every role: name, alternate, work contact method, out-of-hours method if you operate one, and the systems they can actually control. Review the list after team changes. A stale contact list is not a minor administrative problem. It sends responders into improvisation at the moment they should execute.

Separate authority from consultation. Legal, compliance, customer support, and senior leadership may need notice, depending on the affected work. They should not form a queue in front of containment. The incident lead informs them after the first safe action, unless a specific legal obligation requires otherwise.

Stop, revoke, and preserve are different actions

Stopping an agent process, revoking its authority, and preserving evidence solve different problems. Teams routinely blur them, then believe an inactive process has lost access when it has not.

A stop prevents further work from that process. It may mean terminating a local process, disabling a scheduled task, pausing an agent runner, or removing a repository trigger. Stop first if the process is still active and its behavior is uncertain.

A revoke removes the authority that made the action possible. It may involve disabling an action session, withdrawing a service identity, locking an access vault, replacing an upstream token, or blocking a narrowly defined integration. An agent that is stopped today may restart tomorrow from a retry queue or another machine. Its authority must not remain available by accident.

Preservation captures what responders need before routine recovery overwrites it. Record the process identity, source revision or prompt context when relevant, operator account, start and stop times, destination services, and the last confirmed action. Preserve logs and configuration snapshots according to your retention rules. Do not paste secrets into an incident ticket while collecting evidence.

Use this decision card in the first minutes:

Incident ID:
Declared by / time:
Affected agent process or session:
Immediate risk: active calls / possible credential exposure / unknown

[ ] Stop current run
[ ] Revoke agent authorization
[ ] Lock or rotate affected credential path
[ ] Preserve process identity and action records
[ ] Notify service owner

Revoker / time:
Recorder / time:
Recovery is prohibited until incident lead approves it.

The last line prevents a familiar failure. A developer sees that production work has paused, restarts the agent to get the queue moving, and destroys the clean boundary responders just created. Recovery needs a separate decision because it changes the risk again.

Do not require responders to prove malicious behavior before they act. A strange destination, a failed approval flow, an agent that will not stop, or a discrepancy between expected and observed actions is enough to contain first. The review can later distinguish a defect, a mistaken configuration, and an attack.

Urgent work needs a narrow approval path

Urgent work sometimes cannot wait for the normal owner, but "urgent" is often used to skip the very controls that would expose a bad request. The runbook should allow a narrow exception without turning every incident into a blanket approval.

Define urgent work as a specific service outcome that will suffer material harm if it waits for the normal path. A pending deployment because someone wants to finish before lunch is not urgent. Restoring a failed production dependency may be urgent. The description must identify the exact action, target, expected result, and latest useful completion time.

Use this approval sequence:

1. The requester states the service impact, the exact proposed action, affected account or environment, and expiry time.
2. The incident lead confirms that containment remains in place and appoints a service owner or delegate to validate the scope.
3. The revoker grants only the authority required for that action, with an explicit expiry and a recorded approver.
4. The requester performs the work while the recorder captures the resulting action record and outcome.
5. The revoker removes the temporary authority immediately after the result is verified.

The approval record should be boring and complete. Do not accept "approved, please fix" in chat. Require a statement like this:

Emergency work authorization
Request ID: IR-2025-041
Requested action: restart payment-worker deployment in production
Scope: one named deployment, no repository writes, no account changes
Reason: queue is failing and manual recovery window expires at 14:30 UTC
Approver: service owner delegate
Granting revoker: access revoker
Expires: 14:30 UTC
Result and removal time:

The example does not give a responder permission to restart anything. It shows the level of specificity that prevents scope creep. "Restore production" hides dozens of possible actions. A named deployment and an expiry can be checked.

Do not use a standing emergency credential for this path if you can avoid it. Teams like standing emergency access because it feels fast. It also creates a permanent high-value target, and people eventually use it for ordinary work because it is convenient. Use authority that is granted for a bounded action, then removed.

If no authorized person can approve an urgent action, keep containment in place and escalate through the ownership chain. A delayed recovery hurts. An unauthorized recovery that expands an incident can hurt far more.

The first fifteen minutes should be mechanical

Under stress, people skip timestamps, debate terminology, and assume a colleague has performed an action. A runbook needs an ordered first-response sequence that works even when the cause is still unknown.

At minute zero, the person who observes the concern creates an incident record and states the observable fact. Write "agent process sent requests to an unrecognized endpoint" rather than "agent compromised." Facts survive later review better than early theories.

The incident lead then declares one of two states: investigation or emergency containment. Investigation means the team has no indication of active unsafe authority and can inspect without pausing work. Emergency containment means the team cannot safely establish the agent's current authority or actions. The second state authorizes the revoker to act.

During the next fifteen minutes, do the following in order:

1. Identify the active process or session and record its visible identity, host, owner, start time, and current task.
2. Stop further execution if it remains active or if a scheduler can relaunch it.
3. Revoke the authority available to that process, beginning with the most consequential external action path.
4. Notify the affected service owner that containment is active and state the operational consequence plainly.
5. Preserve action records and configuration context before changing unrelated settings.

Avoid broad cleanup in this period. Do not rebuild hosts, delete working directories, rotate every secret in the company, or change deployment settings because the situation feels alarming. Those actions may be justified later, but they bury the evidence and create unrelated outages.

The recorder should maintain a simple timeline in one shared place:

14:07  Observer reported unexpected outbound request from agent run A-184.
14:09  Incident lead declared emergency containment.
14:10  Revoker stopped run A-184 and disabled its action authorization.
14:12  Service owner confirmed order processing may pause.
14:14  Recorder saved action records and configuration digest.
14:18  Team began scope review. No recovery authority granted.

This is more useful than a long narrative written afterward. It shows what the team knew, who acted, and when authority changed. Keep opinions and hypotheses in a separate investigation note.

Approval fatigue is a design failure

People bypass warnings when the same prompt appears for harmless and consequential work alike. Repeated approval does not create care. It teaches people to click through the card so work can continue.

Your emergency runbook should state which actions require an explicit human decision and which can proceed inside normal authority. Make the boundary meaningful. An action that changes infrastructure, reaches a new external destination, alters an account, or uses a credential outside the expected service path deserves more scrutiny than a read operation that stays within a known scope.

Do not attempt to solve this with a giant written policy full of conditions. During an incident, a responder needs a few clear choices: deny, stop, revoke, grant one bounded emergency action, or restore ordinary operation. If the procedure requires interpretation of twenty exception clauses, it will fail differently for every responder.

The approval screen or record must identify the caller well enough for a human to distinguish an expected run from an unexpected one. Process name alone is weak evidence because names are easy to copy. Capture the process origin, code-signing identity where the operating system provides it, launch context, and session identifier. That lets an approver say "this is the expected developer tool launched from this path" rather than "the label looks familiar."

A common bad recommendation says every sensitive call should require a person to approve it. It sounds safe because it puts a human in every loop. It fails when a legitimate task makes many calls: the operator approves blindly, the agent cannot complete bounded maintenance, and the team eventually turns the setting off. Reserve single-use approval for authority that has a meaningful consequence, and use session-level approval only when the session identity is clear and its scope is acceptable.

Sallyport follows this practical split with a vault gate, default per-session authorization, and an optional per-key requirement for approval on every use. That does not replace a runbook, because a human still needs authority to halt the work and decide whether an urgent exception is justified.

Logs must answer who acted and who approved it

An incident record that says "the agent did it" is incomplete. Agents run through processes, identities, action channels, and human approval paths. Your evidence needs to show each link.

For every important call, preserve the agent session or process identity, the human or system that initiated it, the target service or host, the requested action, the authorization state, the result, and a trustworthy time. For emergency work, record the approver, revoker, requested scope, expiry, and removal time beside the call record.

Keep the approval record separate from the action result, then correlate them by an incident or request identifier. This distinction matters. An approval means someone authorized a bounded attempt. It does not prove the attempt succeeded, touched only the intended object, or stopped at expiry.

Ask these questions during review:

• Which process made the request, and how did it start?
• Which authority allowed the request at that moment?
• Who approved emergency work, and what exact scope did they approve?
• Did the result match that scope?
• Can an independent reviewer detect altered or missing records?

NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide, treats preparation, detection and analysis, containment, eradication and recovery, and post-incident activity as connected work. Its guidance on documenting and preserving incident data remains useful, but agent operations add a detail that older runbooks often miss: you need a record of delegated machine authority, not only a record of human logins.

Do not confuse ordinary application logs with an audit trail. Application logs may omit authorization context, permit broad administrative changes, or disappear when a machine is rebuilt. Preserve them, but document what each record can and cannot prove.

For systems that maintain a cryptographic audit chain, make verification part of the drill. Sallyport exposes offline verification through sp audit verify, which lets a reviewer check its encrypted, hash-chained audit log without needing the vault key. Run that command against a copied evidence set during rehearsal, not for the first time when an incident commander is waiting on an answer.

Recovery must earn back authority

Restoring service is not the same as closing the incident. A team should restore only the authority it can explain, and it should do so in small enough steps that a recurrence has a visible boundary.

Before recovery, the incident lead needs three answers: what caused the containment decision, what authority was exposed or used, and what control now prevents a repeat. You may not know the full root cause immediately. You still need enough confidence to state why the first restored action is safe.

Restore service in bounded stages. Begin with read-only validation where possible, then a single known action, then a short monitored run. Do not reinstate every agent, integration, and credential because one service has recovered. Preserve the incident boundary until the service owner and incident lead agree that the affected path is understood.

Use a recovery authorization that differs from the urgent-work approval. Emergency approval permits a necessary action despite the incident. Recovery approval confirms that normal authority may return after containment. Give it a separate record:

Recovery authorization
Incident ID:
Cause or remaining uncertainty:
Authority to restore:
Validation performed:
Monitoring owner and review time:
Approved by incident lead and service owner:

Expiry matters here too. If a temporary recovery grant remains available after a successful test, it becomes undocumented standing access. The revoker should confirm its removal as part of the recovery record.

Credential rotation needs judgment rather than ceremony. Rotate when the credential may have reached an untrusted process, destination, repository, log, or person, or when you cannot establish its use boundary. Do not claim rotation fixed the incident if an agent still has a route to obtain the replacement through the same unsafe path. Repair that path first.

The post-incident review should produce edits, not just observations. Replace "communication was unclear" with "the recorder will use the incident timeline template and the service owner page will list an alternate." Replace "access was difficult" with the exact missing permission, the owner who will grant it, and the next drill date.

Rehearsal exposes the parts nobody owns

A runbook that has not been exercised is a proposal. The first live use will expose stale contacts, missing authority, and disagreement about who can restart work. A rehearsal turns those unknowns into fixable defects while the stakes are low.

Run a tabletop exercise first, then a controlled technical drill. In the tabletop, give participants a short scenario with incomplete information, such as an agent making an unexpected SSH connection during a deployment. Ask them to execute the call tree, decide whether to contain, fill the approval record, and state what evidence they would preserve. Do not let the author of the runbook answer every question.

In the technical drill, use a nonproduction target or an explicitly isolated test path. Start a known agent process, authorize a harmless action, invoke containment, confirm that further actions fail, preserve the records, and perform a limited recovery. Time the actions, but do not turn the exercise into a speed contest. A fast response that misses revocation is worse than a slower response that establishes a clean boundary.

Score the drill with observable checks:

• Could the observer reach an incident lead and revoker using the documented methods?
• Did the revoker have the necessary authority without an administrator improvising access?
• Did the team distinguish stopping the process from removing its authority?
• Could a reviewer match emergency approval to the resulting action record?
• Did temporary access disappear at the stated expiry or removal time?

NIST SP 800-61 explicitly recommends testing incident response capabilities, and it gives a practical reason: exercises reveal gaps in procedures, training, and technical controls. Do not limit testing to the incident response team. Include the people who run the agent, own the affected service, and approve urgent work. Their assumptions are usually where the process breaks.

Update the runbook immediately after the drill while names, delays, and confusing instructions are fresh. Then schedule the next exercise and assign each correction to an owner. If nobody owns a correction, you have recorded a defect and chosen not to fix it.

Put the first-action card where failure cannot hide it

The full runbook may live in your controlled documentation system, but responders need a short card that remains available when ordinary tools are slow or affected. Keep it in a location the team can reach without the agent environment, and ensure the card points to current contacts rather than copying volatile details.

The card should tell the observer who to call, tell the incident lead when they may declare containment, tell the revoker what authority to remove first, and tell everyone that recovery requires a fresh decision. It should also name the evidence record and the place where the recorder writes the timeline.

Review the card whenever you change agent runners, action channels, ownership, or the systems that grant access. Do not wait for a yearly audit. The moment a team changes how an agent reaches the outside world, its emergency procedure may have become fiction.

A good drill ends with a slightly embarrassing list of missed assumptions. Keep that list. The team that finds its failures in rehearsal has done the work required to avoid finding them during an outage.