A kill switch that can only target one agent at a time is exactly the wrong shape when the incident isn't one agent.
We run three separate public-facing AI chat agents across our own properties — one on our main site, one on our CRM product's site, one on a sister product's site. Each one has its own identity, its own tenant boundary, its own audit trail. That's the right way to run them day to day.
But it raises an obvious operational question: if something goes wrong across all three at once — a shared upstream dependency misbehaves, a policy needs to change fleet-wide, a security review calls for an immediate, precautionary stop — do we really want to be issuing three separate kill commands, one at a time, hoping we didn't miss a fourth?
That question is why we built catalog-scoped kill switches: any group of agents you've already defined can now be stopped, together, with the same one signed action you'd use to stop a single agent.
The kill switch already worked. The grouping didn't exist yet.
RuntimeAI's kill switch has always supported three scopes: a single agent, an entire tenant, or global. All three are real, fast, and already live-fire proven. What was missing was the scope in between — a named, curated set of agents that isn't "everything on this tenant" and isn't "just this one."
We already had exactly the building block for this: the Governed Entity Catalog, which lets any tenant define custom groupings — "blueprints" — and link real agents into them. Until now, that catalog was purely descriptive. Grouping agents didn't change how they were governed; it just helped you see them together.
The fix wasn't a new enforcement engine. It was one connection.
A catalog-scope kill switch doesn't invent new plumbing. It fans one KILL or LIFT call out across every agent in the group, using the exact same per-agent enforcement path that already exists — same signal, same audit trail, same sub-second response. Grouping the agents was the only piece that was missing.
Proven live, on our own three website agents
We didn't ship this against a synthetic test fixture. We proved it against our own three real, running public-website bots — registered them under one governed group, then ran both directions of the demo live:
1 Precision — kill just one bot, by name. The other two, on the same tenant, keep answering real chat messages without interruption. Grouping agents for convenience never has to mean losing the ability to act on just one of them.
2 Group stop — one call, targeting the group instead of an individual agent. All three bots stop responding at once. One call to resume, and all three are answering again within seconds.
Every member of a group-kill still gets its own individual result — if one agent in a group of ten fails to stop for some reason, that failure is reported by name, not hidden behind a blanket "success." A group action is still an auditable set of individual actions, not a black box.
Why this matters beyond our own three bots
The value here isn't specific to website chat widgets. It's specific to the fact that any real deployment of AI agents ends up with natural groupings — a product line's agents, a region's agents, every agent built on a given model version, every agent touching a given data class. The moment you can name that group once, you can govern it as one blast-radius unit: same policy, same kill switch, same audit trail, without hand-maintaining a list of individual agent IDs every time something needs to change for all of them at once.
That's the shift: from "a kill switch per agent" to "a kill switch per group you define" — without giving up the precision to still act on just one agent when that's all the situation calls for.
See group-scoped containment on your own agent fleet
We'll walk through how your agents would be grouped, and show the same precision-and-group kill switch live against a real tenant.
Subscribe to RuntimeAI Security Weekly — one issue per week, the AI-agent incidents and defensive control gaps that matter.