---
title: "It's a dimmer switch, not a kill switch. How CISOs are rethinking AI agent governance"
description: "AI agent drift needs more than a kill switch. CISOs and IAM leaders in regulated industries are moving to a dimmer switch model, fine-grained runtime authorization that narrows agent access without breaking the workflow, with a complete audit trail of every decision and policy change."
author: "Alex Olivier"
date: "2026-05-14T12:40:48.626Z"
canonical: "https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/It_s_a_dimmer_switch_not_a_kill_switch_How_CIS_Os_are_rethinking_AI_agent_governance_127c820ec6.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance"
---

# It's a dimmer switch, not a kill switch. How CISOs are rethinking AI agent governance

I spent the last few weeks on the road, including IIW, and kept noticing the same thing about how enterprises are rolling out AI. Most governance plans have a kill switch in them somewhere. A button. A flag. A circuit breaker. Something you can flip the moment an agent does the wrong thing.

It feels safe. It is also the wrong way to think about it.

Jonathan Chan, former senior technology and security executive at Episource, put it to me more cleanly than I had heard before.

> "It isn't a kill switch. It's a dimmer switch. You want to be able to fade the agent's access down while you get behind the wall and rewire things to how they should be. The lights never go fully dark."

Worth sharing because most of the AI governance language CISOs and IAM leaders are dealing with right now is still binary. On or off. Allow or revoke. Deploy or kill. That works in a lab. It does not work in a hospital, a bank, a payments network, or any environment where the agent is doing something a human used to do, and stopping it instantly creates a different incident than the one you were trying to prevent.

## Why "kill switch" is the default for AI agent governance, and why it falls apart

The kill switch metaphor came from a reasonable place. The first wave of AI agents in production looked like things you might want to flip off in a hurry. A prototype tool. A copilot. A research assistant. If something went wrong, you pulled it offline and not much else broke.

That is not where most enterprises are now. Agents are calling APIs, triggering workflows, moving money, opening tickets, querying patient data, generating claims, escalating incidents, and writing to systems of record. Replit's coding agent [deleted a production database](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/) despite explicit instructions not to and an active code freeze. The agent did not crash. It did not malfunction in any traditional sense. It drifted from the plan it was authorized to execute, and the only governance lever available was after the fact.

When a CISO inherits agents like that, "kill it" stops being a useful primitive. Killing the agent means stopping the workflow it is in the middle of. It means dropping context. It means waking someone at 3am to manually finish what the agent was doing. In a regulated environment, it can also mean a compliance event of its own, because you have just disrupted a process that auditors expect to be continuous and logged.

**The kill switch is a panic button for a problem that does not look like a panic anymore.**

## What AI agent drift actually means

The word Jonathan used for the problem is a useful one. Drift.

An agent drifts when it diverges from the plan it was authorized to execute. It is not necessarily compromised. It is not necessarily malicious. It may be following its instructions perfectly and still be doing the wrong thing, because the world it is operating in has changed, the data it is reading has shifted, or the prompt it received pulled it sideways. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) covers a lot of these failure modes under different names, and what they have in common is that the agent is operating at the limit of, or just outside, the boundary it was meant to stay inside.

![OWASP Top 10 for LLM Applications. What AI agent drift actually means..png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/OWASP_Top_10_for_LLM_Applications_What_AI_agent_drift_actually_means_c45470a82b.png)

Drift is the thing CISOs and IAM leaders are quietly worried about, because it is hard to see and harder to reason about. Identity-led controls catch the agent at the door. They do not catch the agent that already has the door key and starts opening rooms it was never expected to enter. That is a runtime authorization problem, and most enterprises do not have a unified view of it.

## Why regulated industries cannot rely on a binary AI agent kill switch

Healthcare is the clearest example, which is why Jonathan's framing landed first there. If an agent helping a clinical operations team starts behaving oddly, "kill it" means a queue of patient referrals stops moving. If the agent supporting claims adjudication starts drifting, "kill it" means a backlog forms inside an SLA window that has regulatory teeth.

The same is true in financial services, where agents are increasingly inside payment flows, fraud triage, and customer servicing. It is true in critical infrastructure, where uptime is part of the regulatory contract. It is true in any operation where the agent is now load-bearing.

In all of those environments, the question a CISO has to answer is not "can we shut it down". It is "can we shut it down without creating the next incident, and can we prove afterwards that we acted within policy". The kill switch cannot answer either question. The [IBM Cost of a Data Breach Report 2024](https://www.ibm.com/reports/data-breach) puts breaches in regulated industries materially above the cross-industry average, with healthcare leading every year for more than a decade. When the governance plan is a single switch, the blast radius of a bad day is the entire operation it touches, and the audit afterwards has very little to work with.

## The dimmer switch model for AI agent authorization

A dimmer switch is fine-grained, runtime, and scopable. It assumes you will need to make a thousand small adjustments long before you ever need to make one big one.

In practice, it looks like this. The agent is operating under a policy that defines what it is allowed to do, with whom, on which resources, under what conditions. When something starts to look wrong, you do not flip the agent off. You narrow the policy. You take it off the most sensitive systems first. You put it into read-only mode against patient data. You require a human approval on any action above a certain value. You scope its tool access down to a known-safe subset. The agent keeps running. The work keeps moving. The control plane keeps a complete record of every change you made and when, which is exactly what an auditor will ask for when they want to see how you responded.

If it turns out the agent was fine, you fade the access back up. If it turns out the agent was drifting in a way you cannot live with, you keep dimming until the access is effectively zero. By the time you reach the off position, you are doing it deliberately, with a documented trail, and the rest of the operation has had time to adjust.

This is what [externalized, policy-based authorization](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) gives teams. The policy lives outside the agent, so the agent does not get to decide whether the rules apply to it. Changes propagate in seconds across every agent running in the environment. Every decision the agent makes, and every change you make to the policy itself, lands in an [audit trail](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) that holds up to SOC 2, ISO 27001, HIPAA, and PCI DSS scrutiny.

![how cerbos authorization works.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/how_cerbos_authorization_works_af5a179d34.png)

## What CISOs and IAM leaders gain from runtime AI authorization

The pieces are not exotic. Teams already have most of the language for this from the [externalized authorization](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits) world.

A policy decision point sits in the request path of every agent action. The agent asks "can I do this, on this resource, for this user, right now". The decision point evaluates the request against the current policy and returns an answer. The policy is centrally managed, version controlled, and pushed out to every decision point in seconds when it changes. Identity, context, and resource attributes flow into the decision through enrichment, so the policy can reason about the human behind the agent, the data the agent is touching, and the system the agent is acting on.

Translated into the things a CISO actually gets, that means:

* A single, unified view of what every agent is allowed to do, across every system it touches  
* Instant revocability, scoped from full access down to nothing in seconds  
* A demonstrable, time-stamped audit trail of every authorization decision and every policy change  
* A way to apply the same governance to [non-human identities](https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities) that you already apply to human users  
* The same architecture covering [authorization for MCP servers](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) and any other agent runtime that turns up in the environment

Most security teams have the policy intent. They do not have the place to enforce it consistently, or the record to prove they did. The dimmer switch model is what gives them both.

![dimmer switch - authorization for ai agents.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/dimmer_switch_authorization_for_ai_agents_96d858cf60.png)

## Shared vocabulary for AI agent governance conversations

The reason I wanted to write this up is that Jonathan's framing is genuinely portable. CISOs and IAM leaders do not need a new product category to use it. They need shared vocabulary to take into their own engineering, risk, and compliance conversations.

A few phrases worth borrowing.

"We do not have a kill switch problem. We have a dimmer switch problem." Useful when an executive committee is asking why the agent governance plan is more complicated than they expected.

"The agent is drifting." Useful when an incident is in progress and the team needs to separate "compromised" from "behaving outside the authorized plan", because the response is different.

"Fade it down, then figure it out." Useful when the instinct in the room is to pull the agent offline and the operational cost of doing so is higher than the security benefit.

"Show me the policy that was in effect at the time." The version of the question every internal investigation, regulator, and auditor is going to ask after the fact. If the answer is a screenshot or a Slack thread, the dimmer switch is not really there yet.

None of this replaces the security tooling already in place. Identity controls, secrets management, runtime monitoring, and incident response are all still required. The dimmer switch sits alongside them and gives CISOs and IAM teams something they did not previously have, which is a way to respond to drift without creating a second incident, and a way to prove afterwards that they responded within policy.

## Putting the dimmer switch model into practice

The kill switch was the right metaphor for a moment that is already passing. The dimmer switch is closer to how regulated enterprises actually need to govern agents that are now part of how the work gets done. Credit to Jonathan Chan for the framing. We thought it was sharp enough that more CISOs and IAM leaders should have it in their vocabulary.

If any of this maps to what you are working through, the [AI security page](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) on our site walks through how runtime authorization, policy enforcement, and audit logging fit together for AI agents in production.

[Try Cerbos](https://hub.cerbos.cloud/) to see how policy changes propagate across agents in seconds, or [book a call](https://www.cerbos.dev/workshop) if you want to talk through the architecture with the team.

Go deeper

* [Fine-grained authorization for non-human identities](https://www.cerbos.dev/forms/14nPMu_1TT4yNaq6OezwbSQc2voq) (webinar)  
* [Zero trust for AI: Securing MCP servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) (ebook)

## FAQ

### What is AI agent drift?

AI agent drift is when an autonomous agent diverges from the plan it was authorized to execute. The agent is not necessarily compromised or malicious. It may be following its instructions perfectly while still doing the wrong thing, because the data it is reading has shifted, the prompt pulled it sideways, or the environment around it has changed. Drift is a runtime authorization problem, which is why identity controls alone do not catch it.

### Why is a kill switch not enough for AI agent governance?

A kill switch is not enough for AI agent governance because most enterprise AI agents are now load-bearing. Killing the agent stops the workflow it is in the middle of, drops context, and in regulated industries can create a compliance event of its own. A binary on/off response works in a lab. It does not work in healthcare, financial services, or critical infrastructure where uptime is part of the regulatory contract.

### What is the dimmer switch model for AI agent authorization?

The dimmer switch model for AI agent authorization is a fine-grained, runtime alternative to a binary kill switch. Instead of pulling the agent offline, you narrow the [policy](https://www.cerbos.dev/blog/policy-based-access-control-enterprise-security) the agent is operating under. You can take it off sensitive systems, force human approval above a threshold, or scope its tool access down to a known-safe subset. The agent keeps running while the security team investigates, and every change is logged.

### How does runtime authorization work for AI agents?

Runtime authorization for AI agents works by placing a policy decision point in the request path of every agent action. The agent asks whether it can perform an action on a specific resource, and the decision point evaluates that request against a centrally managed policy. The policy lives outside the agent through [externalized authorization](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits), which means changes propagate in seconds across every agent in the environment.

### How do CISOs govern non-human identities like AI agents?

CISOs govern [non-human identities](https://www.cerbos.dev/blog/nhi-security-how-to-manage-non-human-identities-and-ai-agents) by applying the same fine-grained authorization controls they already apply to human users. That means policy-based rules defining what each agent can do, on which resources, under what conditions, with a unified view across every system the agent touches. It also means instant revocability, scoped from full access down to nothing, and a complete audit trail of every authorization decision.

### How do you audit AI agent decisions for compliance?

You audit AI agent decisions for compliance by capturing every authorization request, decision, and policy change in a time-stamped [audit log](https://www.cerbos.dev/blog/why-audit-logs-are-important). The log should show what the agent asked to do, the policy that was in effect at that moment, and the result. This is what auditors will ask for under SOC 2, ISO 27001, HIPAA, and PCI DSS when they want to see how the security team responded to drift.