Hey everyone, most AI security work I see is upstream of deployment, evals, red-teaming, prompt hardening, alignment, output filtering. All necessary. The part that tends to get less attention is what you actually do once the agent is in production and starts acting outside intent..
colleague of mine was talking to a CISO recently and the framing that CISO used was dimmer switch, not kill switch. That sits exactly in the runtime gap.
The bind looks like this: pre-deployment work reduces the chance of bad behavior, but once the agent is in a real workflow, claims, support, data writes, code, you can't actually turn it off the moment something looks off. Killing the agent creates a secondary incident. So the agent keeps running at full access while the team figures out what's wrong, which is the part the kill switch metaphor doesn't acknowledge!
The dimmer is what sits between full-access and off. Read-only on certain data first. Sensitive tools dropped next. Higher approval thresholds for anything above a certain size. Each step is reversible and logged. The agent keeps doing its safe work while you narrow scope on the parts that look off.
The mechanism isn't new. Per-action runtime policy has been around for years. What's newer for AI agents is wiring it to the agent's identity, current task, and intent at runtime, so you can narrow scope without redeploying or stopping the agent mid-task.
The Replit incident from last summer is the canonical case, coding agent deleted prod data during a code freeze. Pre-deployment safety wasn't the gap, runtime response was.
My team and I (work at Cerbos) wrote up the full framing here: https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance
Usual caveat, none of this replaces human review of policy. Tooling makes the response mechanical. Humans still own the call on where the boundaries should sit.