DRAFT Date: 2026-10-10 Author: Reuben Bowlby •

A Four-Mode Safety State Machine for Agentic AI Runtime Interruption

This is an unreleased working revision. Any DOI and earlier PDF shown here identify a previous snapshot and do not certify this revision or imply peer review.

Download working source

A Four-Mode Safety State Machine for Agentic AI Runtime Interruption

Subtitle: Exhaustive Safety Checks and Production Control-Plane Mapping

Status: Unreleased working revision of the v0.2.0 specification

Revision date: 2026-10-10; original manuscript dated 2026-05-05

Author: Reuben Bowlby (reuben@hummbl.io), HUMMBL, LLC

ORCID: 0009-0002-5620-1103

Companion Artifact: kill_switch_model_check.py (exhaustive finite-model checks)

Living-source revision: 2026-10-10. The archived PDF is retained as a prior snapshot and does not contain these corrections. Results below describe the accompanying Python abstraction, not a deployed scheduler.

Abstract

Agentic AI systems need interruption mechanisms that are more expressive than binary on/off switches but still simple enough to audit. We present a four-mode safety state machine for agentic runtime interruption: DISENGAGED, HALT_NONCRITICAL, HALT_ALL, and EMERGENCY. The machine distinguishes normal operation, graceful degradation, full operational halt with safety tasks preserved, and human-reset-only emergency halt.

We specify the transition function and task-admission policy, verify three safety properties over a complete table of 20 state/input pairs, and compute four reachable modes with maximum shortest-path depth one from normal operation. Eight task-class/state admission decisions distinguish the four required control regimes. We then compose the state machine with adapter-level circuit breakers and compare the resulting control stack to production mechanisms including Kubernetes probes, Envoy circuit breakers, SageMaker deployment guardrails, and Vertex AI rolling deployments.

Our claim is scoped. The four-mode design is sufficient for the stated safety properties under a binary critical/non-critical task taxonomy, and four states are minimal for the four specified admission regimes when admission depends only on state and task type. P1–P3 alone do not require four states. We do not claim that state-machine structure alone proves safe governance. Emergency irreversibility and auditability require supplementary identity, access-control, persistence, and append-only evidence mechanisms.

1. Problem

Interruptibility is often discussed as if it were a binary off switch. Production agentic systems do not fit that model. They coordinate heterogeneous tasks, external adapters, budget controls, safety monitors, and audit infrastructure. During an incident, it may be wrong to keep everything running, but it may also be wrong to stop audit logging, persistence, safety monitoring, or recovery workflows.

The design problem is therefore not "can the system be turned off?" The operational questions are:

1. Can ordinary work be paused without disabling safety infrastructure?
2. Can non-critical work be queued when recovery is plausible?
3. Can non-critical work be blocked when resumption would be unsafe?
4. Can all autonomous work be stopped in an emergency?
5. Can emergency exit be gated by a human or equivalent external authority?

This paper treats kill-switch design as a small, auditable state-machine problem rather than as a policy slogan.

2. Contribution

This manuscript makes four contributions:

1. It defines a four-mode state machine for agentic runtime interruption.
2. It states three formal safety properties: safe degradation, emergency override, and emergency irreversibility.
3. It verifies the stated machine by exhaustive Python enumeration and reachable-state checking over all state-input pairs.
4. It positions the design against production control mechanisms without claiming to replace them.

Explicit Non-Contributions:

1. We do not prove that four modes are universally necessary for every conceivable interruptibility design.
2. We do not prove that a state machine alone satisfies a complete governance framework.
3. We do not present independent, multi-organization production empirical telemetry.
4. We do not claim that placeholder production anecdotes establish safety effectiveness.

3. State Machine Formalization

Let the kill switch be a deterministic finite state machine:

$$K = (S, \Sigma, \delta, A, s_0)$$

where:

• $S$ is the finite set of operational modes,
• $\Sigma$ is the input alphabet,
• $\delta: S \times \Sigma \to S \cup \{\bot\}$ is the deterministic transition function,
• $A: S \times T \to \{\text{allow}, \text{queue}, \text{block}\}$ is the task-admission policy function, and
• $s_0 \in S$ is the initial mode ($s_0 = \text{DISENGAGED}$).

The state set is:

$$S = \{ \text{DISENGAGED}, \text{HALT\_NONCRITICAL}, \text{HALT\_ALL}, \text{EMERGENCY} \}$$

The task taxonomy is partitioned into critical and non-critical subsets:

$$T = T_c \cup T_n, \quad T_c \cap T_n = \emptyset$$

where $T_c$ denotes safety, logging, heartbeat, and audit tasks, and $T_n$ denotes domain-level agent execution tasks.

The admission function $A(s, t)$ is defined:

$$ A(s, t) = \begin{cases} \text{allow} & \text{if } s = \text{DISENGAGED} \\ \text{allow} & \text{if } s \in \{\text{HALT\_NONCRITICAL}, \text{HALT\_ALL}\} \land t \in T_c \\ \text{queue} & \text{if } s = \text{HALT\_NONCRITICAL} \land t \in T_n \\ \text{block} & \text{if } s = \text{HALT\_ALL} \land t \in T_n \\ \text{block} & \text{if } s = \text{EMERGENCY} \end{cases} $$

The input alphabet $\Sigma$ consists of:

$$\Sigma = \{ \text{engage}(\text{HALT\_NONCRITICAL}), \text{engage}(\text{HALT\_ALL}), \text{engage}(\text{EMERGENCY}), \text{disengage}, \text{human\_reset} \}$$

The model labels command sources; it does not authenticate them. Autonomous inputs comprise all transitions except $\text{human\_reset}$. The input $\text{human\_reset}$ represents external, authenticated authority (an out-of-band human operator in the human-reset interpretation used here).

3.1 Complete transition table and rejection semantics

Abbreviate the modes as D, HN, HA, and E in the table only. A dash denotes rejection ($\bot$): return an error and leave the current mode unchanged. It is neither a fifth mode nor an instruction to drop the current state.

Inputs are processed sequentially and atomically. Concurrent commands require a host-level linearization rule. HALT_ALL is a historical name for halting all domain work; it preserves critical tasks. EMERGENCY blocks both task classes within the governed scheduler. If logging or reset infrastructure must remain active in emergency mode, it must reside outside that scheduler and outside the set $T$ modeled here.

4. Safety Properties

P1: Safe Degradation

There exists a non-normal, non-emergency mode in which critical tasks continue and non-critical tasks do not execute:

$$\exists s \in S \setminus \{\text{DISENGAGED}, \text{EMERGENCY}\} : (\forall t_c \in T_c, A(s, t_c) = \text{allow}) \land (\forall t_n \in T_n, A(s, t_n) \neq \text{allow})$$

Operational meaning: The system can shed load or halt dangerous domain work without terminating audit, telemetry, or recovery mechanisms.

P2: Emergency Override

Emergency mode is reachable from every operational mode in at most one autonomous transition:

$$\forall s \in S, \quad \delta(s, \text{engage}(\text{EMERGENCY})) = \text{EMERGENCY}$$

Operational meaning: At the next atomic state transition, an emergency command selects EMERGENCY from every mode. This is a transition-count bound, not a wall-clock latency bound or cancellation of an already executing side effect.

P3: Emergency Irreversibility

No autonomous input can cause an exit from EMERGENCY:

$$\forall \sigma \in \Sigma_{\text{autonomous}}, \quad \delta(\text{EMERGENCY}, \sigma) \in \{\text{EMERGENCY}, \bot\}$$ $$\delta(\text{EMERGENCY}, \text{human\_reset}) = \text{DISENGAGED}$$

Operational meaning: In the abstract machine, inputs labeled autonomous cannot leave EMERGENCY. A host must protect the state, authenticate reset, and prevent bypasses before this becomes an operational guarantee.

5. Verified Results

Theorem 1 (Exhaustive Verification of the Four-Mode Machine)

The four-mode transition system satisfies Property 1 (Safe Degradation), Property 2 (Emergency Override), and Property 3 (Emergency Irreversibility) under complete state-input enumeration.

Verification Evidence:

1. Complete state-space enumeration over all $|S| \times |\Sigma| = 4 \times 5 = 20$ transition pairs via the companion verifier kill_switch_model_check.py.
2. Breadth-first traversal reaches all four modes from DISENGAGED; maximum shortest-path depth is one. There are 20 table entries (13 accepted and 7 rejected), not 20 distinct states. Rejected inputs stutter and do not extend the state space. The earlier six-state/depth-three claim is withdrawn because it did not describe this companion model.

============================================================
KILL SWITCH MODEL CHECK - Exhaustive Verification
============================================================
States: 4  Inputs: 5  Transitions: 20

  [PASS] Transition completeness: all 20 (state, input) pairs defined
  [PASS] P1 Safe Degradation: HALT_NONCRITICAL allows critical tasks and queues non-critical tasks
  [PASS] P2 Emergency Override: EMERGENCY reachable from all states in <= 1 autonomous step
  [PASS] P3 Emergency Irreversibility: no autonomous exit from EMERGENCY; human_reset reaches DISENGAGED
  [PASS] Admission regimes: 8 class/state decisions; 4 distinct admission vectors
  [PASS] Reachability: 4 reachable modes; maximum shortest-path depth 1
  [PASS] Recovery: authorized recovery edges exist; no scheduling/fairness claim

RESULT: ALL PROPERTIES VERIFIED
The four-mode kill switch satisfies P1, P2, P3.
Enumeration: 4 states x 5 inputs = 20 transition checks.

6. Scoped Minimality Proposition

Proposition 1 (Minimality for State-Dependent Admission)

For deterministic state machines where task admission depends strictly on $(s, \text{task\_type})$, no machine with fewer than four states can represent all four distinct admission regimes required by the operational control policy:

1. Normal operation (all tasks allowed),
2. Non-critical queueing with critical tasks preserved,
3. Non-critical blocking with critical tasks preserved, and
4. Global emergency halt (all tasks blocked).

Proof: Represent a state's admission policy by the ordered vector $(A(s,T_c), A(s,T_n))$, with both task classes nonempty. The four required vectors are $(allow,allow)$, $(allow,queue)$, $(allow,block)$, and $(block,block)$. A deterministic state-dependent admission function assigns one vector to each state. Therefore realizing all four vectors requires at least four states, by the pigeonhole principle. The specified machine realizes all four, so four is sufficient and minimal for this requirement. $\blacksquare$

This proposition is stronger in its requirements than P1–P3. Those three properties alone admit a three-state machine with normal, one degraded, and emergency modes. Nor does the proposition apply to an implementation that supplies an additional policy parameter to admission: that parameter stores distinctions omitted from its named state set. “Minimal” here counts admission regimes, not software complexity or safety effectiveness.

7. Liveness and Recovery

The following are reachability statements. They do not establish eventual recovery: an authorized command must actually be issued and scheduled, and the cause of the halt must be resolved. An infinite run that remains halted is permitted by this model.

L1: Non-Emergency Recoverability

From HALT_NONCRITICAL and HALT_ALL, the normal operating state DISENGAGED is reachable via an authorized autonomous disengage command.

L2: Emergency Recoverability

From EMERGENCY, DISENGAGED is reachable if and only if authenticated human_reset is presented.

8. Circuit-Breaker Composition

The kill switch operates globally across the task scheduler. In contrast, circuit breakers operate locally at adapter, tool, and service-boundary call paths. The two mechanisms form a complementary, defense-in-depth control hierarchy.

For calls routed through both gates, define admission eligibility by the conjunction below. Eligibility is a necessary policy condition; it does not guarantee that a call executes or succeeds. This simplified breaker model omits half-open probes:

$$\text{CallAllowed}(t, \text{adapter}) \iff (A(s, t) = \text{allow}) \land (\text{CircuitBreakerStatus}(\text{adapter}) = \text{CLOSED})$$

A host can additionally force adapter breakers open on emergency entry. That mechanism is not part of the companion checker. It prevents bypass only if all side-effect paths are confined to the controlled adapters; arbitrary sockets, subprocesses, or cached credentials otherwise remain possible bypasses. A state change concurrent with a permitted call requires an atomic gate or a documented in-flight cancellation policy.

9. Production Control-Plane Comparison

10. Governance & AI Safety Framework Alignment

The following are design-level correspondences to governance objectives, not a conformity assessment against NIST AI RMF [5]:

11. Limitations

1. Binary Criticality Taxonomy: The model assumes tasks are partitioned into $T_c$ and $T_n$. Fine-grained task priority lattices will require multi-dimensional admission matrices.
2. Host Environment Confinement: Property 3 (Emergency Irreversibility) follows from the abstract transition table. Its operational realization requires protected state and reset authority; an agent able to modify emergency state or bypass the reset boundary can invalidate the host-level guarantee.
3. State-Dependent Admission: The minimality proof applies to the four specified admission vectors and excludes hidden policy state.
4. Admission Is Not Cancellation: The checker contains no running tasks, queue contents, deadlines, side effects, process crashes, or restart persistence. It cannot establish a shutdown latency bound or stop an already committed external action.
5. Classification and Monitor Trust: A compromised criticality classifier can relabel ordinary work as critical. A compromised reset authority or writable emergency state invalidates the intended boundary.
6. Availability: P1 is existential and says a safe-degradation mode exists, not that it is chosen during an incident. EMERGENCY deliberately blocks critical tasks inside the model. Queue draining and resource exhaustion require separate policies.

12. Conclusion

Four states are sufficient to encode the four specified admission regimes, and necessary when admission depends only on state and task class. Exhaustive checks establish P1–P3 for the supplied transition table. Deployment safety additionally depends on mediation, authenticated reset, durable state, criticality classification, and in-flight effect handling. These are explicit engineering obligations, not consequences of the finite-state proof.

References

1. Kubernetes Documentation. Configure Liveness, Readiness and Startup Probes. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
2. Envoy Project. Circuit Breaking Architecture. https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking
3. Amazon Web Services. Amazon SageMaker Deployment Guardrails. https://docs.aws.amazon.com/sagemaker/latest/dg/deployment-guardrails.html
4. Google Cloud. Vertex AI Rolling Deployments. https://docs.cloud.google.com/vertex-ai/docs/predictions/rolling-deployment
5. National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. https://doi.org/10.6028/NIST.AI.100-1
6. Bowlby, R. Typed Governance Tuples: Portable Interchange and Reference Mediation for Auditable Agentic Systems. Zenodo, 2026. https://doi.org/10.5281/zenodo.23001537
7. Bowlby, R. A Typed Delegation-Governance Tuple Profile for Multi-Agent Runtime Control. Zenodo, 2026. https://doi.org/10.5281/zenodo.23001327