AI agent governance needs a dimmer switch, not a kill switch

At a glance

What this is: This is an analysis of why AI agent governance needs fine-grained runtime controls instead of an all-or-nothing shutdown model.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agents that are part of business operations, not optional tools, and binary controls can increase operational and compliance risk.

By the numbers:

• The IBM Cost of a Data Breach Report 2024 puts breaches in regulated industries materially above the cross-industry average, with healthcare leading every year for more than a decade.

👉 Read Cerbos's guide to runtime authorization for AI agent governance

Context

AI agent governance often assumes the safest response is to turn an agent off when it misbehaves, but that assumption breaks once the agent is embedded in patient care, claims, payments, or other continuous business flows. In those settings, the primary keyword here is AI agent governance, and the real problem is not simple shutdown, but runtime control over an identity that is already doing work a human once did.

The article argues that a binary kill switch creates a different incident because it stops the workflow, drops context, and can leave regulated operations without continuity or auditability. That makes this a governance problem for IAM and NHI teams as much as for security operations, because the control model has to preserve both containment and traceability.

Cerbos uses the dimmer switch metaphor to describe scoped, policy-based reduction of access while the agent continues to operate under tighter constraints. The underlying lesson is that agent governance has to be externalized, versioned, and auditable, or teams will keep choosing between unsafe continuity and disruptive shutdown.

Key questions

Q: What breaks when organisations use a kill switch for AI agent governance?

A: A kill switch can stop the agent, but it also stops the workflow, drops context, and can create a new operational or compliance incident. The control fails when the agent is load-bearing and the business cannot tolerate interruption. In those cases, governance needs staged containment that preserves continuity while access is narrowed.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: AI agents complicate identity controls because their risky behaviour often happens during execution, after provisioning-time approvals have already been granted. That means static entitlements, periodic reviews, and binary revocation are too blunt for many real workflows. Teams need runtime authorisation, policy versioning, and auditability at the point of action.

Q: How do security teams know whether AI agent governance is actually working?

A: A working programme can show what policy was in effect at the time of each decision, how access changed during an incident, and whether the workflow stayed within approved boundaries. If the only evidence is a screenshot or chat thread, governance is not yet operationalised. Auditability and traceability are the clearest signals.

Q: Who is accountable when an AI agent must be slowed down instead of shut off?

A: Accountability sits with the team that owns the policy, the workflow, and the incident response playbook, not with the agent itself. Regulators and auditors will expect a documented rationale for why access was reduced, who approved it, and what evidence supports the decision. Shared ownership without clear control authority usually becomes no ownership at all.

Technical breakdown

Why binary shutdown fails in load-bearing AI agent workflows

A kill switch assumes the safest action is to stop an agent instantly and accept the operational breakage that follows. That works for prototypes, but it fails when the agent is embedded in workflows that must remain continuous, such as claims, clinical operations, fraud triage, or incident handling. The issue is not whether the agent can be disabled. It is that disabling it can become the incident. In governance terms, a binary control treats the agent like a disposable tool rather than a runtime identity with active obligations and dependencies.

Practical implication: Practitioners need control paths that can reduce privilege without collapsing the business process the agent is supporting.

Runtime authorization for AI agents and MCP-connected tools

Runtime authorization means every action is evaluated against current policy at the moment of execution, rather than relying only on permissions assigned at provisioning time. For agents calling APIs, triggering workflows, or using MCP-connected tools, this creates a policy decision point that can narrow scope as conditions change. The architecture matters because drift often happens after initial approval, not at login. Externalized policy enforcement also creates the audit record needed to explain why access was narrowed, preserved, or revoked.

Practical implication: Teams should place policy enforcement in the request path so agent behaviour can be scoped in real time.

Dimmer switch authorization as a control pattern

A dimmer switch is a policy pattern that reduces agent capability in stages. Instead of all-or-nothing revocation, teams can move an agent from write to read-only, remove access to sensitive systems, add human approval for high-risk actions, or restrict the tool set it can use. This is especially relevant where the agent has access to systems of record and must keep operating long enough for humans to investigate. The pattern makes authorization adaptive rather than binary, which is the core distinction the article is pushing.

Practical implication: Security teams should define graded restriction states before an incident so they can fade access down under pressure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Binary AI shutdown is the wrong governance primitive for load-bearing agents. The kill switch model assumes an agent can be stopped without creating a second operational failure, but that assumption does not hold once agents are embedded in regulated workflows. In practice, shutdown can break continuity, remove context, and create an audit problem of its own. The implication is that agent governance must be designed around containment without process collapse, not around a single emergency off switch.

AI agent governance now depends on runtime authorisation, not provisioning-time trust. Agents drift after approval because the situation they are operating in changes, the data they see changes, or the plan no longer matches reality. That is a control problem rooted in execution-time decisioning, which is why static entitlement models are too slow. Practitioners should treat the request path as the governing surface for every meaningful agent action.

Externalised policy is the named control pattern this category needs. When the policy lives outside the agent, teams can version it, scope it, and prove what was in effect at the time of a decision. That is materially different from trusting the agent to self-limit. The practitioner takeaway is simple: if the policy is not external and auditable, it is not real governance.

Agent drift is a runtime failure mode, not a compromise narrative. The article usefully separates a system acting outside its authorised plan from a system being hacked. That distinction matters because the response, evidence, and accountability chain are different. The implication for IAM and NHI programmes is to build controls that can explain deviation, not just detect intrusion.

AI agent governance is converging with NHI governance and regulated identity controls. Once agents can call APIs, write to records, and trigger business processes, they behave like non-human identities with higher operational stakes. That makes lifecycle, policy versioning, and auditability shared concerns across IAM, PAM, and NHI teams. Practitioners should plan for one control model that can govern both service identities and agentic identities.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap makes runtime policy control a governance priority, and the same category pressure is visible in Top 10 NHI Issues for teams building agent and workload identity controls.

What this signals

Dimmer switch governance will become the default language for teams that run AI agents in production. The market is moving away from binary revocation because operational systems cannot always tolerate abrupt shutdown. For practitioners, that means incident response, access policy, and audit evidence need to be designed around graded containment, not emergency offboarding alone.

Runtime authorization will increasingly sit beside NHI lifecycle management. As agents become load-bearing, the question is not only who provisioned access, but how access can be narrowed safely while work continues. Teams that already use externalized policy and audit-ready controls will have a clearer path than those relying on review cycles built for slower identities.

Externalized policy is the practical bridge between AI governance and identity governance. If you need a broader NHI lifecycle lens, Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs helps map where provisioning, rotation, and offboarding end, and runtime control begins.

For practitioners

• Define graded restriction states for AI agents Pre-build policy states that move an agent from full access to read-only, then to tightly scoped tool use, and finally to no write capability. Document which business workflows can survive each state so responders know how far they can fade access before continuity breaks. This should be tested against systems of record, not just sandbox environments.
• Put policy enforcement in the request path Use externalised authorization so each agent action is checked against current policy at execution time. That lets teams narrow scope mid-session and preserves a versioned record of what policy was in force when the action happened. The control should cover API calls, workflow triggers, and sensitive data access.
• Separate drift handling from compromise handling Write incident procedures that distinguish an agent drifting outside its authorised plan from an agent being actively compromised. The response options, evidence collection, and escalation path should differ, because a drift event may call for scoped containment while the workflow remains live.
• Audit where shutdown would create a second incident Map every AI agent to the workflow dependencies it supports and identify where a hard stop would trigger backlog, SLA breach, or compliance exposure. Use that map to decide which systems need staged containment instead of immediate revocation.

Key takeaways

• AI agent governance fails when teams treat shutdown as the primary control, because load-bearing workflows can break before the security problem is resolved.
• The article shows that runtime authorisation and externalised policy matter more than provisioning-time approval once agents can call APIs, write records, and trigger workflows.
• Practitioners should design graded containment states now, so they can reduce agent privilege without creating a second incident during response.

Key terms

• AI Agent Drift: AI agent drift is when an agent diverges from the authorised plan it was supposed to follow. The agent may not be compromised or malicious, but its actions no longer match the intended workflow, which creates governance, compliance, and operational risk in production environments.
• Runtime Authorization: Runtime authorization is the practice of evaluating an action at the moment it is executed, using current policy and context. For AI agents and other non-human identities, this is what allows access to be narrowed, preserved, or revoked without relying only on provisioning-time approvals.
• Externalized Policy: Externalized policy is authorization logic that lives outside the agent or application being governed. It gives teams a central place to version rules, apply them consistently, and prove what decision logic was in effect when an action occurred, which is essential for audits and incident review.
• Dimmer Switch Model: The dimmer switch model is a graded containment approach for AI agents and other non-human identities. Instead of an all-or-nothing shutdown, access is reduced in stages so the organisation can keep critical workflows moving while narrowing risk and documenting each control change.

Deepen your knowledge

AI agent governance and runtime authorisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for load-bearing agents, it is worth exploring.

This post draws on content published by Cerbos: AI agent governance needs a dimmer switch, not a kill switch. Read the original.