Kill Switch Binding

kill-switch-binding

The TAO_SWARM_ENABLED=0 env flag is the existing kill-switch. This skill adds two new entry points so the user can halt the swarm from anywhere — and adds the 2-of-N gate the Hermes-Swarm Recommendation §5 requires.

Three entry points

1. Telegram /panic command

User types /panic from the configured operator chat. CoS poller catches it (extends the existing /ack polling logic), writes a kill_switch_triggered audit row, and sets TAO_SWARM_ENABLED=0 via:

• File-flag at .harness/swarm/kill_switch.flag (created/touched on /panic, deleted on /resume).
• Orchestrator's _check_kill_switch() extended to ALSO read the file-flag.

Why a file-flag and not a process env var: env vars don't propagate to a running process. File-flag is read every cycle. Cheap and reliable.

/panic does NOT require 2FA — Telegram trust is established by the operator chat_id allowlist already in place. Speed matters more than extra friction here; halting is reversible.

2. Dashboard kill button (2-of-N + 2FA)

Dashboard adds a red Halt Swarm button. Click → modal asking for: 1. The user's TOTP code (from authenticator app) 2. A second approver (any allowlisted user with their own TOTP)

Both required. On approval:

• POST /api/swarm/kill with both TOTPs → server validates → file-flag set + audit row.
• Telegram alert fires to the operator chat: "Swarm halted via dashboard by {user1}+{user2}."

The 2-of-N gate exists because the dashboard kill is durable across restarts (file-flag persists), while /panic is operator-only and revertible by a single operator. Symmetry of trust matches symmetry of permanence.

3. Programmatic / CI-side /resume (operator-only)

Telegram /resume from the operator → file-flag deleted, audit row, swarm resumes on next cycle.

/resume does require operator chat verification but no 2FA — same logic as /panic. Permanence is reverted by the same authority that set it.

What halts (and what doesn't)

Audit + alerting

Every halt + resume writes to audit-emit:

{
  "type": "kill_switch_triggered" | "kill_switch_resumed",
  "actor_role": "CoS" | "Dashboard",
  "fields": {
    "trigger_source": "telegram_panic" | "dashboard_2fa" | "telegram_resume",
    "approvers": ["user1", "user2"],   // dashboard only
    "reason": "..."                     // optional, from /panic message text after the command
  }
}

Telegram alert on every transition (regardless of source).

Loop guard

If /panic fires more than 5 times in 1 hour, escalate to Telegram with severity=critical and prevent further /resume until user manually deletes .harness/swarm/kill_switch.flag AND posts an explicit /resume-confirm <reason> from the operator chat. Prevents oscillation attacks.

Verification

1. Set TAO_SWARM_ENABLED=1. Confirm swarm runs. 2. Post /panic from operator Telegram chat. 3. Within 1 cycle (≤5 min): file-flag exists, swarm cycle log shows "Kill-switch fired", Telegram alert posted. 4. Post /resume → file-flag gone, cycle log shows resume, alert posted. 5. Post /panic 6 times in 1 hour → escalation alert + /resume blocked until manual flag deletion. 6. Dashboard side: click kill button without TOTP → 401. With one TOTP → 401. With both → 200, file-flag set, alert posted.

Out of scope

• Per-role kill-switch (halt only Margot, leave Scribe running) — Wave 4.
• Time-bounded halt (/panic 1h) — Wave 4.
• Cross-org kill (halt swarm in CARSI from Pi-CEO) — separate concern, requires distributed kill protocol.
• Hardware kill switch — out of scope for Pi-CEO.

References

• Hermes-Swarm Recommendation §5 — 15 mandatory safety controls, kill-switch row
• Existing kill-switch: swarm/orchestrator.py _check_kill_switch() + swarm/config.py SWARM_ENABLED
• Existing operator chat: swarm/config.py TELEGRAM_CHAT_ID
• Topology: /Users/phill-mac/Pi-CEO/Second-Brain-Agent-Topology-2026-05-01.md