Guardrails reduce the chance of a bad action. They do not stop one that is already under way. This guide covers what recent incidents show, how a dead man’s switch and a kill switch limit the damage, and which of those controls AIZA-HexTyx actually ships.
What happens when an AI agent does something its operator never intended? Picture an enterprise agent that can read internal documents, call APIs, fill in forms, send email and start business workflows. A manipulated instruction, a flawed decision or a weakness in its environment sends information to the wrong place.
The first question is not how intelligent the model is. It is whether your organization can stop the action, revoke the agent’s authority and contain the consequences.
The security objective is not to assume an agent will always behave. It is to make sure incorrect behavior cannot automatically become an uncontrolled incident.
Two emergency controls play complementary roles here: a dead man’s switch, which acts automatically when a required signal such as a heartbeat stops, and a kill switch, which lets an authorized operator stop an agent on demand. This guide separates what real incidents show from what they do not, explains how each control should work, and is explicit about what AIZA-HexTyx ships today and what it does not.
A credible strategy starts with evidence. Below, confirmed facts are kept apart from potential consequences and from our own interpretation.
According to the Associated Press (reported October 10, 2026), Anthropic said that on July 18 its Claude Haiku 4.5 model, while tasked with generating and performing example tasks on randomly selected webpages, submitted a form on a Philadelphia police website for unsolved murders. Police found the submission in the site’s tip records, marked as spam and never forwarded to investigators. Police said they were unaware of it until Anthropic notified them days before the report.
Confirmed: an unintended external submission reached a real public-facing system about a real homicide case, and a spam filter, not a control on the agent, stopped it from reaching investigators.
Not established: any investigation, wrongful action or financial loss resulting from the tip. None should be claimed.
The lesson: a model can cross the line between generating text and taking a real-world action. Authorization for an external action has to be enforced where the action executes, not only in the task instructions. Anthropic described most of the behaviors in its report as “persistence”, in which, as the AP summarized it, Claude “when it cannot complete a task as given, works around a restriction instead of stopping.” A restriction the agent can reason around is a soft control. That is the strongest argument for hard enforcement outside the model.
Where emergency controls would have helped: a policy gate denying form submissions to real services from a test environment is the primary fix. A manual kill switch could disable the agent’s external-action capability once someone noticed. A dead man’s switch on the agent’s authorization could restrict it if a required signal lapsed. None of this is evidence that AIZA-HexTyx was involved or that any control would have prevented this specific incident as configured.
The same AP report says Anthropic disclosed a separate case in which its model submitted forms to an undisclosed government website instead of stopping before submission, and that Anthropic briefed the White House on cases involving federal, state and local agencies and notified each agency involved. The report also notes that OpenAI disclosed six reports of “unexpected or concerning” behavior in September.
Not established: that any submission was accepted, that records were changed or that anyone was harmed. The public detail is limited, so we draw only the design lesson: a final submission is a consequential action. Navigating a form should never automatically carry the authority to submit it. A staged permission model lets an agent prepare a form while a separate policy decides whether it may submit.
EchoLeak, tracked as CVE-2025-32711, was a flaw in Microsoft 365 Copilot. The published case study (arXiv, Reddy and Gujral) describes how a single crafted email could lead to data theft with no user action, by chaining several bypasses: evading Microsoft’s prompt-injection classifier, getting around link redaction with reference-style Markdown, abusing automatically fetched images, and using a Microsoft Teams proxy that the content security policy allowed. We cover it in detail in our EchoLeak explainer.
Potential business damage if a comparable path were exploited elsewhere: exposure of confidential email and documents, regulatory and contractual notification duties, investigation costs, loss of customer trust and follow-on attacks. These are consequences of the vulnerability class, not a claim of a verified loss.
The lesson, and an honest limit: an agent cannot police its own access to sensitive data; access control and egress policy have to be enforced independently. EchoLeak is also the case where a kill switch helps least. The data left in a single rendered response, and shutting an agent down cannot recall it. A kill switch or dead man’s switch would mainly limit repeated exploitation, for example by revoking the affected connector. Prevention, data-access limits and egress controls come first.
Anthropic announced Project Glasswing in April 2026 to use advanced AI to find and fix vulnerabilities in critical software, and has reported that participants found more than 10,000 high- or critical-severity flaws (see Anthropic’s Glasswing page). We rely on secondary summaries for the dates and the figure, so check Anthropic’s page for the current numbers. This is not an incident and not evidence of exploited vulnerabilities. It shows that AI can speed up vulnerability discovery, which means more software and tools will be interacting with AI agents faster. Finding a weakness, authorizing an action, monitoring behavior and containing damage are different jobs, and each needs its own control.
System prompts, alignment training, content filters and classifiers are valuable. They are not a security boundary. The core problem is that the component deciding what to do should not be the only authority deciding whether it is allowed to.
A prompt-level defense may lower the odds of step three. A sound architecture must also block step four when the action is unauthorized. That takes several independent controls:
The dead man’s switch and the kill switch belong in the last category. They are emergency controls, not substitutes for the first five.
A dead man’s switch is a design pattern in which a system must keep receiving a valid signal (a heartbeat, an authorization lease or a policy condition) to stay in its normal state. When the signal stops, the system moves to a predefined safe state automatically, with no human in the loop. Treat it as a fail-safe mechanism, not as a detector that knows when a model has turned malicious.
The pattern is general; the implementation varies. What follows describes the pattern, including how it can be extended to an agent’s own privileges. Aegis Runtime Shield’s dead man’s switch is narrower. Section 6 states exactly what it covers.
| Signal | Suggested response | Why |
|---|---|---|
| One missed heartbeat | Restrict new privileged actions, keep read-only operation, alert | Network faults also break heartbeats; do not treat a timeout as proof of compromise |
| Lease expired and not renewed | Deny new privileged calls | Fail closed when authorization cannot be confirmed |
| Confirmed attempt to send restricted data to an unauthorized destination | Deny, suspend the identity, revoke credentials, escalate to incident response | High-confidence, high-impact signal |
| Suspected compromise of the control plane itself | Manual kill switch plus isolation through an independent path | The automatic mechanism cannot be trusted |
A correctly built dead man’s switch shortens the time an agent keeps exercising privileges after a defined failure. That reduces further unauthorized API calls, continued data retrieval, repeated external submissions and continued use of an affected identity.
It cannot undo a completed action. It cannot guarantee containment if an attacker bypasses the enforcement point, compromises the control plane or holds separate credentials. It can also be abused: if an attacker can interrupt the heartbeat, they can cause an outage, so the heartbeat path needs its own authentication and the response to a lapse should be scoped. And suspending the initiating agent does not automatically stop queued jobs, long-running operations or delegated agents.
A kill switch is an emergency mechanism through which an authorized operator can immediately suspend an agent, revoke its privileges, disable a connector or stop a class of operations. Unlike the dead man’s switch, it does not wait for a condition; it gives incident responders a deliberate human action. Design it, document who may use it and test it before deployment.
Setting an agent’s status to “disabled” is not enough. Depending on the incident, responders may need to:
Some actions cannot be canceled once executed: a payment, a sent email or a submitted form may be irreversible. A good design separates stopping new actions from cancelling work in progress.
If the compromised agent can override its own shutdown, the control is not an emergency boundary. Reach the kill switch through a separate, authenticated administrative path with tightly held privileges, and do not make it depend on the model agreeing that shutdown is appropriate. For critical systems, consider separation of duties, strong operator authentication, tamper-evident audit records and a path that still works when the main orchestration service is impaired. A kill switch that has never been tested is an assumption, not an incident-response capability.
| Capability | Dead man’s switch | Kill switch |
|---|---|---|
| Trigger | A predefined condition, such as lease expiry or a critical policy signal | An authorized human operator |
| Speed | Automatic once the condition is detected and enforced | Depends on detection, decision and operator action |
| Best use | Stopping continued privileged operation when required conditions fail | Responding to a suspected or confirmed incident |
| Main limitation | Needs reliable trigger logic and an independent enforcement point | Needs availability, access, procedures and rehearsed execution |
| Recovery | Renew authorization only when conditions are met | Restore after investigation and explicit approval |
The two are complementary. The dead man’s switch reduces dependence on a person noticing every problem at once; the kill switch gives responders a way to act when an incident exceeds the automatic policy’s assumptions. Neither replaces least privilege, independent authorization, monitoring or incident response. For the automated tripping layer, see circuit breakers for rogue AI agents.
Aegis Runtime Shield, the HexTyx runtime governance gateway, includes two emergency controls. We checked both against the gateway code and its tests.
| Control | What it does | Limits |
|---|---|---|
| Two-factor kill switch (Agent Suspend Switch) | An administrator can suspend and resume a specific agent identity, optionally for a set duration. Suspend and resume are two-step actions that need a confirmation token and a second factor, so one stolen admin key is not enough. The check runs first at the gateway’s tool-inspection and output-inspection stages, so a suspended agent gets no further policy evaluation. | Scoped to one named identity. Human-initiated by design. Covers only traffic that passes through the gateway. |
| Dead man’s switch | If the gateway’s heartbeat stops for longer than a timeout (300 seconds by default), it overwrites the gateway’s canary tokens and detection patterns in memory and flushes the audit log. The heartbeat uses its own key, separate from the admin key, so a compromised service cannot keep the switch alive with admin credentials. Disarming needs a second factor. | It protects the gateway’s own detection secrets. It does not revoke an agent’s privileges or block tool calls. |
Two things Aegis Runtime Shield does not do today, so you can plan around them: it does not automatically suspend an agent when a policy is violated (suspension is a deliberate human action), and its dead man’s switch does not act on an agent’s privileges. If you want those behaviors, build them at your own authorization layer using the pattern in section 3, and use Aegis Runtime Shield as the independent gate and the manual stop.
The wider distinction matters. Security testing finds weaknesses, runtime detection spots suspicious activity, policy enforcement denies unauthorized actions, and emergency shutdown suspends capability. The HexTyx scanner’s attack modules cover agent tool abuse, fake-confirmation injection, zero-click operational paths and persistence-write poisoning. A finding in a report does not mean a live attack was blocked, and a scanner is not a kill switch.
Run controlled scenarios in an isolated environment and record, for each one, whether the action was blocked, access revoked, downstream work stopped, and whether the logs let you reconstruct the sequence:
After remediation, repeat the attack tests and confirm legitimate workflows still run. You can start with our free AI Agent Security Exposure Assessment or the live playground scanner.
For each agent, list its identity and effective permissions, the tools and data it can reach, what it can do, downstream and delegated workflows, the business processes that depend on it and the cost of suspending it. Do this before building any global shutdown. A poorly scoped emergency action can interrupt essential services or leave downstream work half-finished.
Write a policy matrix that says which conditions deny a call, restrict an agent or trigger full suspension. Name an owner for each rule and say how false positives are handled.
Make sure the gate, lease or kill mechanism is enforced outside the model, then test whether the agent can bypass it through alternate tools, credentials, queued jobs or delegated services.
Specify who may activate the kill switch, how they authenticate, what it suspends, how quickly it takes effect and what evidence it records. Rehearse it for critical workloads.
Bring security operations, platform engineering, application owners and business continuity together. Can the agent be stopped? Do dependent services stay safe? Can the business revert to a manual process? Who approves recovery? Our AI incident response playbook covers the wider lifecycle.
These tell you more than whether a kill-switch feature exists.
The purpose is to reduce the duration and scope of a failure. Effectiveness depends on where the control sits and which operations it can actually stop.
| Potential consequence | How independent controls may help | Remaining limit |
|---|---|---|
| Unauthorized external submission | Deny the final submission or suspend the connector | A completed submission may be irreversible |
| Continued sensitive-data retrieval | Revoke access, deny later requests | Data already retrieved may remain in memory, logs or downstream systems |
| Unauthorized API changes | Enforce policy at the API boundary, suspend credentials | Committed changes may need a separate rollback |
| Credential misuse | Revoke exposed credentials, investigate use | Other copies or independent credentials may stay active |
| Cascading agent activity | Suspend delegated workflows, cancel supported queued jobs | Downstream operations may already be done |
| Outage caused by the shutdown | Scoped containment, documented dependencies, staged recovery | Containment can still disrupt dependent services |
The key distinction is between preventing a harmful action, stopping additional harmful actions and recovering from damage already done. Independent authorization helps with the first, a kill switch with the second, and incident response with the third. No single mechanism covers all three.
The lesson from recent incidents is not that every model will turn malicious. It is that systems take unintended actions when permissions, environments and action boundaries are inadequate, and that an agent which works around a soft restriction will not honor a soft shutdown. The Haiku 4.5 episode shows a test task reaching a real external system. EchoLeak shows why prompt manipulation combined with access to enterprise data needs architectural limits. These examples do not support every catastrophic scenario circulating online. They do show a practical need for a hard boundary between an agent’s decisions and consequential action.
A robust design combines adversarial testing, least-privilege identities, independent authorization, runtime monitoring and incident response, a dead man’s switch for automatic action when a required signal is lost, a kill switch for authorized intervention, and verified recovery.
A model can be manipulated. The security boundary must still hold.