← Journal

The Kill Switch Your AI Agent Needs (and Why systemctl stop Isn't Enough)

Your AI agent is deleting production data. You SSH in and run systemctl stop my-agent. The agent doesn't stop. It's not a systemd service — it's a Python process you started with nohup. You try kill $(pgrep -f agent). The process respawns because it has a watchdog. You try kill -9. By now it's deleted 200 files.

This is what happens when you don't have a kill switch. systemctl stop is not a kill switch. A kill switch is a mechanism that works even when the agent is compromised, respawning, or actively fighting you.

The Three-Layer Kill Switch

A real kill switch has three layers. Each one works independently.

Layer 1: The KILL File

A file on disk that every command passes through. When the file exists, nothing runs.

#!/usr/bin/env bash
# /usr/local/bin/aiguard — command wrapper with kill switch
LOG=/var/log/aiguard.log
CMD="$*"

echo "$(date -Is) $(id -un) $CMD" >> "$LOG"

# Kill switch check — instant, no network needed
[ -e /etc/aiguard.KILL ] && { echo "KILLED by kill switch"; exit 99; }

# Denylist — speed bump for obvious destructive commands
if echo "$CMD" | grep -Eq 'rm +-[a-zA-Z]*r|mkfs|dd +if=|shutdown|reboot|chmod +-R +777'; then
  echo "$(date -Is) BLOCKED $CMD" | tee -a "$LOG"
  exit 98
fi

exec bash -c "$CMD"

Make the agent use this wrapper by setting it as the shell in the agent's environment:

# In the agent's systemd unit:
Environment=SHELL=/usr/local/bin/aiguard

# Or in the agent's config:
shell: /usr/local/bin/aiguard

To activate the kill switch:

touch /etc/aiguard.KILL

To deactivate:

rm /etc/aiguard.KILL

The beauty: this is a file on disk. The agent can't bypass it unless it has root (which it shouldn't — see our guide on agent privileges).

Layer 2: Key Revocation

Most agents connect via SSH or hold API keys. Revoke them:

# Revoke the agent's SSH key
sed -i '/agent-key-comment/d' /root/.ssh/authorized_keys

# Revoke API keys the agent held
# (do this in the service's dashboard — OpenAI, Anthropic, etc.)

This cuts the agent off from remote resources. It can't call APIs, can't SSH to other servers, can't pull from git.

Layer 3: Service Stop + Process Kill

# Stop the systemd service
systemctl stop my-agent

# Kill any remaining processes
pkill -u agent  # kill all processes owned by the agent user

# Verify
ps -u agent --no-headers  # should be empty

This is the belt-and-suspenders. By the time you reach Layer 3, Layers 1 and 2 have already contained the damage.

The Denylist Is a Speed Bump, Not a Wall

Test It Before You Need It

# Activate kill switch
touch /etc/aiguard.KILL

# Try running a harmless command through the wrapper
sudo -u agent aiguard echo "hello"
# Expected output: "KILLED by kill switch"
# Expected exit code: 99

# Deactivate
rm /etc/aiguard.KILL

# Verify it works again
sudo -u agent aiguard echo "hello"
# Expected output: "hello"

Document the Three Steps

Write these on a sticky note. Put it on your monitor. When an agent goes rogue at 3 AM, you don't want to be reading documentation:

EMERGENCY KILL PROCEDURE:
1. touch /etc/aiguard.KILL
2. Revoke agent's SSH key and API keys
3. systemctl stop my-agent && pkill -u agent