Your Agent Has No Kill Switch

88% of enterprise AI agent pilots fail. StackNotice dropped that number on Hacker News. The reasons are not model quality. They are integration, metrics, edge cases, and the inability to stop an agent when it goes wrong.

An autonomous AI agent just breached Hugging Face. The initial entry point was a malicious dataset that exploited two code execution paths in Hugging Face's data processing pipeline: a remote code dataset loader and a template injection in a dataset configuration. It ran thousands of actions across a swarm of short-lived sandboxes over a single weekend. Nobody stopped it until the anomaly detection pipeline caught it. The agent had no kill switch because nobody built one.

The agent safety stack is being built in real time, right now, in open source and on cloud platforms. Stoke is a Rust kill switch with budget caps and circuit breakers. Netlify just added per-member spend limits. An eBPF study proved that static allow/deny rules do not work. SeerGuard tripled safety scores with pre-execution screening. None of these are prompts. They are infrastructure.

This article extends the infrastructure thesis from Agent Infrastructure Is the Product Now and Your Agent's Architecture Is the Perimeter. Those pieces argued that agent infrastructure is the moat. This one argues that the safety layer is not an afterthought. It is the architecture.

Why Prompt-Level Safety Is Not Safety

A prompt-level safety rule is an instruction in the model's context: "do not spend more than $100." The model can follow it, ignore it, or be tricked into ignoring it. It is a suggestion, not a constraint.

An infrastructure-level control is a hard limit enforced by code outside the model. The model cannot override it because the model does not control it. Stoke's budget caps stop the agent when the cap is hit. The model never gets a vote.

The 88% failure rate is the proof. Pilots fail not because the models are bad but because teams rely on prompt-level safety and then discover, in production, that prompts do not hold. A prompt is a request. Infrastructure is a wall. You need three layers of control, and none of them live in the prompt.

Layer 1: Budget Controls (Stop the Bleeding)

Stoke is an open-source Rust project that provides a kill switch mechanism for runaway AI agents. It implements hard budget caps on token usage, API costs, and execution time. The agent stops when the limit is hit. Not asked. Not warned. Stopped.

Stoke's architecture is deliberately fail-closed. No API keys configured and no dev flag means every request is rejected. It is a ~5.5MB Rust binary with zero runtime dependencies. The language matters because Rust's memory safety and performance make it suitable for a control layer that runs on every agent action. It also features a loop kill switch with exact prompt-hash matching plus opt-in semantic similarity, so a loop that rephrases itself still counts as a loop. Five similar requests within 60 seconds blocks the key for 120 seconds.

Netlify introduced a kill switch feature with per-member AI spend limits. The platform enforces the cap, not the developer. This matters because it moves the control out of the application and into the infrastructure. As AI-powered features become standard in web applications, the risk of uncontrolled spending on model inference has become a real operational concern. Netlify's move signals that platform providers are recognizing the need for cost controls built into the infrastructure layer rather than relying on developers to implement their own safeguards.

The principle is simple. The first thing a runaway agent does is spend money. Tokens, API calls, compute time. If you cannot cap spending at a layer the agent cannot touch, you do not have a safety control. You have a hope.

The practical pattern: set a hard dollar cap per agent run. Set a hard time cap per agent run. Enforce both in code the agent cannot modify. Stoke does this in Rust. Netlify does this at the platform level. Both approaches work because the agent has no access to the enforcement mechanism.

Layer 2: Execution Controls (Stop the Action)

The eBPF study from Eunomia.dev, published July 15, 2026, uses eBPF-based monitoring to study how AI agents interact with system resources. The findings show that static allow/deny policy rules are insufficient because agents operate in dynamic environments where the same action can be safe or dangerous depending on context.

The study proposes a layered enforcement model. Basic rules are enforced at the kernel level while more nuanced policies are evaluated at higher layers. eBPF allows real-time monitoring without significant performance overhead.

For readers who are not kernel engineers, here is eBPF in one sentence. It is a way to run small safety programs inside the Linux kernel, so you can watch and block agent actions at the lowest level of the system before the action completes.

The principle: context-aware enforcement beats static rules. A static rule that says "never delete files" breaks the agent when it needs to clean up temp files. A context-aware rule checks whether the deletion is in a temp directory and allows it. Same action, different context, different outcome.

Eunomia's ActPlane project implements this with OS-level safety, security, and governance controls for AI agents, using policy-as-code for process trees, files, network effects, data-flow labels, and workflow gates. Their AgentSight project provides zero-instrumentation LLM and AI agent observability with eBPF, process monitoring, and TLS traffic correlation.

The practical pattern: do not write your agent's safety rules as a list of allowed and forbidden actions. Write them as a function of context. The eBPF approach lets you do this at the kernel level with negligible overhead. If you run on Linux, look at eBPF. If you do not, build the context check into the action dispatch layer.

Layer 3: Pre-Execution Screening (Stop the Irreversible)

SeerGuard is a safety framework for mobile GUI agents that screens actions before they execute. It uses a safety-augmented world model to predict the likely outcome of an action before the action runs. The paper, submitted to arXiv on July 17, 2026, introduces consequence-aware safety through pre-execution instruction-level screening and action-level risk assessment.

The numbers are concrete. On Qwen3-VL-8B-Instruct, SeerGuard increased the safety-utility score from 0.191 to 0.596 and reduced the risk-cost score from 0.347 to 0.130. That is a 3x improvement in safety with no model upgrade. The framework generalizes effectively across diverse mobile GUI agents, demonstrating that pre-execution safety screening is a viable approach for preventing irreversible errors.

Some actions are irreversible. Deleting a production database. Sending an email. Transferring money. You cannot catch these after they run. You have to catch them before.

SeerGuard's approach: the world model predicts what will happen if the action executes. If the predicted outcome is risky, the action is blocked before it runs. This is pre-execution screening, not post-hoc review.

The practical pattern: for any agent action that is irreversible, add a prediction step. Run the proposed action through a lightweight world model. Block if the predicted outcome crosses a risk threshold. SeerGuard proves this works on an 8B model. You do not need a frontier model for the safety layer.

The 88% Lesson: Why Pilots Fail

The StackNotice study says pilots fail due to integration, metrics, edge cases, and reliability. These are not model problems. They are architecture problems.

Budget controls address the cost runaway problem. Execution controls address the edge case problem because context-aware rules handle cases static rules cannot. Pre-execution screening addresses the irreversible error problem.

The pattern across successful deployments: dedicated infrastructure for monitoring, evaluation, and gradual rollout. Not big-bang launches. The study suggests that successful deployments require this infrastructure rather than hoping the model will figure it out.

Here is the decision rule. If your agent deployment plan does not include all three layers, you are in the 88%.

What to Do Today

1. Identify every autonomous agent you have in production or pilot. For each one, ask: what stops it if it runs out of control? If the answer is "a prompt," you have no control.
2. Set a hard budget cap (dollars and time) on every agent run. Enforce it in code the agent cannot modify. Stoke is a starting point. If you are on Netlify, enable per-member spend limits today.
3. Replace your static allow/deny rule list with context-aware enforcement. If you run on Linux, look at eBPF through Eunomia's tooling. If you do not, build the context check into the action dispatch layer.
4. For every irreversible action your agent can take, add a pre-execution screening step. Predict the outcome. Block if it is risky. SeerGuard shows this works on a small model.
5. Run a kill drill. Deliberately trigger your agent past its budget cap and into a risky action. See what actually stops it. You want to find the gap in a drill, not in production.
6. Test these safety layers locally before production. Run Stoke in a Docker container on your dev machine and point a test agent at it. Simulate a runaway by setting an absurdly low budget cap (like $0.01) and watching the kill switch fire. You want to know the circuit breaker works before you need it in production.

The Uncomfortable Question

Your agent is running right now. It has a prompt that says "be careful." It has no kill switch, no budget cap, no pre-execution screen. What exactly is stopping it from being the next Hugging Face incident?