<!-- LI hook: Your AI agents have no off switch. That is a finding. -->

AI Kill-Switches and Budgets: Human Override at Every Blast Radius

A federal compliance team deployed an AI agent to draft System Security Plan narratives across forty information systems. On the third day, a model regression caused the agent to hallucinate control inheritance relationships that did not exist --- marking parent controls as inherited from a system boundary that had been decommissioned six months earlier. By the time a reviewer noticed, the agent had updated narratives in twenty-three systems, each with fabricated inheritance chains that would have failed any assessor's scrutiny. The team spent four days manually reverting changes they could not batch-undo because the platform had no mechanism to stop one agent without stopping everything.

This is the runaway agent problem, and it is not hypothetical. It is the operational reality of deploying autonomous AI in environments where every action may be reviewed by an assessor, cited in an authorization package, or examined during an incident.

Why Now: The Cost Compounds Faster Than You Think

The economic dimension makes the governance gap urgent. AI inference carries a per-token dollar cost. An agent caught in a retry loop, processing an unexpectedly large dataset, or triggered by a malformed batch can consume its entire monthly budget in hours. OMB M-25-21's requirements for AI use case inventories and minimum risk management practices add regulatory pressure: organizations must demonstrate not just that AI is monitored, but that it can be stopped at the appropriate scope.

Without hard limits, the only thing preventing runaway spend is someone watching a billing dashboard --- and billing dashboards update on their own schedule, not yours.

The Blast Radius Problem

AI agents are not static tools. They are autonomous actors that receive tasks, make decisions, and take actions. In a GRC platform, those actions have real consequences:

• An agent drafting SSP narratives is producing content that may end up in an authorization package reviewed by a federal assessor.
• An agent triaging vulnerability findings is making risk decisions that affect remediation priorities.
• An agent modifying workflow states is changing the compliance posture of an information system.

When one of these agents misbehaves --- whether due to a model regression, unexpected input, a prompt injection attempt, or a task it was never designed to handle --- the damage compounds with every action it takes. Each additional draft, each additional triage decision, each additional workflow modification extends the blast radius.

Traditional monitoring catches this eventually. Eventually is not fast enough.

Three Layers of Kill-Switches

Advisedly implements kill-switches at three distinct blast radii. Each layer is independent. Each can be engaged without affecting the others.

Per-Agent Kill-Switch

The most surgical option. A per-agent kill-switch disables a single, specific agent. When engaged, the agent immediately stops accepting new tasks. In-progress work is abandoned cleanly. Every other agent in the platform continues operating normally.

This is the layer used most often. A model update causes one agent to produce lower-quality output. A customer reports unexpected behavior from a specific capability. A routine quality check flags a degradation trend. Per-agent kill-switch, investigate, resolve, re-enable.

Per-Organization Kill-Switch

The next layer up. A per-organization kill-switch disables all AI agent activity for a specific tenant. Every agent serving that organization stops. Agents serving other organizations are unaffected.

This layer exists because some problems are not agent-specific. If an organization suspects data is being processed in unexpected ways, or if an investigation requires a clean environment free of AI activity, one action stops everything for that tenant. No exceptions, no edge cases, no forgotten agents.

In a multi-tenant platform, this boundary matters. An incident in one organization must never require action against another.

Platform-Wide Emergency Stop

The option nobody wants to use. A platform-wide kill-switch disables all AI agent activity across the entire deployment. Every agent, every organization, every capability involving AI inference --- stopped.

Reserved for critical incidents: a model provider outage causing unpredictable behavior, a security vulnerability in the AI pipeline, a regulatory event requiring immediate cessation of all AI processing.

The platform continues to function. Every non-AI capability --- manual compliance workflows, evidence management, asset inventory, vulnerability tracking, reporting --- operates normally. The kill-switch removes AI from the equation. It does not remove the platform.

Per-Agent Budgets: Prevention Over Reaction

Kill-switches are reactive. Budgets are preventive. They stop the problem before someone needs to reach for the kill-switch.

Every registered agent operates under explicit budget constraints:

Dollar-denominated budgets define the maximum spend an agent can incur per invocation and per time period. Because different models have different pricing, dollar-based caps prevent cost surprises when an agent is routed to a more expensive model. An agent designed to draft a two-paragraph summary cannot silently consume the spend equivalent of an entire novel.

Pre-flight cost estimation runs before any AI call executes. A conservative upper-bound cost estimate is computed. If the estimate exceeds the remaining budget, the call is denied before any inference spend occurs. The budget is not consumed and then refunded --- it is never consumed in the first place.

Transactional reservation closes the concurrency race condition. When multiple invocations arrive simultaneously, each reserves its maximum possible cost against the daily cap before executing. Five simultaneous requests cannot each see 80% remaining and all proceed. The reservation model ensures budgets are never overcommitted.

Enforcement mode depends on deployment. On metered deployments (SaaS, cloud-hosted), budgets are enforced hard limits. On unmetered on-prem and hybrid deployments where inference does not carry a per-token dollar cost, budgets default to advisory mode: tracked and surfaced for oversight rather than blocking execution.

When any budget is exhausted on a metered deployment, the behavior is explicit: the agent stops, reports which limit was reached, and provides context to determine whether the limit was appropriate or the workload was unexpectedly large. No silent failures. No degraded operation. A clean stop with a clear explanation.

The Governance Registry

Kill-switches and budgets are attributes of a broader governance registry that every agent must be registered in before it can execute.

The registry captures each agent's identity, purpose, allowed actions, budget limits, lifecycle status, and kill-switch state. Registering an agent is what brings it under per-agent budgets, lifecycle enforcement, and its own kill-switch.

This is the foundational constraint. Per-agent kill-switches are meaningful because a registered agent passes through the registry check on every invocation. Per-agent budgets are enforceable because limits are stored in the registry. Audit trails are anchored to a registered agent identity.

The registry also enforces lifecycle states: active, paused, disabled, or discovered (awaiting formal registration). Only active agents can execute. Changing an agent's lifecycle state is an audited action. An agent does not drift between states --- someone with appropriate authority makes that decision, and the decision is recorded.

Fail-Closed Design

The governance system itself can fail. The database can become temporarily unreachable. A network partition can isolate the service from its governance store.

Advisedly's AI governance layer fails closed. If the governance registry is unreachable, agents do not continue executing in an ungoverned state. They stop. Every AI call that cannot verify its governance constraints returns an error rather than proceeding without checks.

This is a deliberate tradeoff. Failing closed means a governance infrastructure outage becomes an AI availability outage. The alternative --- failing open, allowing agents to execute without governance checks --- is unacceptable in a security platform. An ungoverned AI agent in a compliance environment is a worse outcome than a temporarily unavailable one.

Recovery Is Manual

When a kill-switch is engaged at any layer, agents do not automatically restart when the underlying issue resolves. There is no timeout after which agents resume. There is no automatic recovery based on health checks.

A human must explicitly re-enable the agent, the organization's AI capability, or the platform-wide AI layer. Re-enablement is an audited action. The person who re-enables is recorded. The time is recorded. If the same agent is kill-switched and re-enabled repeatedly, that pattern is visible in the audit trail.

The principle: if something went wrong badly enough to warrant a kill-switch, the assumption that the problem was transient is dangerous. A human reviews the incident and makes the re-enablement decision.

Hard-Won Opinion: "Monitoring" Without a Kill-Switch Is Theater

Here is the uncomfortable truth most AI governance vendors avoid: a dashboard that shows you what AI did after it did it, without the ability to stop it at the right scope in real time, is governance theater. It satisfies nobody --- not the assessor who needs to see enforcement evidence, not the CISO who needs incident containment, not the operator who needs to limit blast radius at 2 AM.

The industry's default posture is "observe and alert." This works for traditional infrastructure monitoring where the automation is deterministic. AI agents are probabilistic. A model regression does not throw an error code --- it produces output that looks correct but is wrong. By the time the monitoring dashboard surfaces the trend, the blast radius has already expanded across dozens of records. The only defense is a mechanism that stops the agent immediately, at exactly the right scope, without collateral damage.

Compliance Alignment

NIST AI RMF subcategory MANAGE-2.4 requires mechanisms, with assigned and understood responsibilities, "to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use." Kill-switches are the literal implementation of that requirement.

GOVERN-3.2 calls for defined roles, responsibilities, and procedures for human oversight of AI systems. Dollar-denominated budgets provide the quantitative dimension. The governance registry provides the structural dimension.

Because every kill-switch engagement and every budget denial produces a cryptographic enforcement receipt, the proof is not the platform's word. It is a signed, hash-chained, tamper-evident record that the governance control was not only configured but enforced at the exact moment it mattered.

Key Takeaways

• Three independent kill-switch layers (per-agent, per-org, platform-wide) contain blast radius at exactly the right scope
• Dollar-denominated budgets with pre-flight estimation prevent runaway spend before it starts
• Fail-closed design: if governance is unreachable, AI stops rather than operating ungoverned
• Recovery is always manual and always audited --- no automatic restart assumptions
• Every kill-switch engagement and budget denial mints a cryptographic enforcement receipt as tamper-evident proof
• AI recommends, humans approve. The kill-switch ensures humans stay in control.

FAQ

How quickly does a kill-switch take effect?

Immediately. The kill-switch flips the agent's lifecycle state in the governance registry. Because every AI invocation passes through a registry check before execution, the next attempted invocation after the flip is denied. In-progress work that has already passed the gate completes or is abandoned, depending on the agent's design --- but no new work begins.

What happens to in-progress work when a kill-switch is engaged?

The agent stops accepting new tasks immediately. For in-progress work, the behavior depends on the agent's design and the nature of the concern. Idempotent operations (read-only analysis, draft generation) are typically abandoned cleanly. Operations that have already committed partial state are flagged for human review. The kill-switch does not attempt to "undo" completed work --- that is a separate remediation decision.

Can budget limits be adjusted without restarting the agent?

Yes. Budget adjustments take effect on the next invocation. There is no restart, no redeployment, no configuration file change. The registry stores the limits, and the pre-flight check reads current limits on every call. An administrator can tighten or loosen budgets in real time as workload patterns become clearer.

How do budgets work on air-gapped deployments where inference is free?

On unmetered deployments (on-prem with local inference), budgets default to advisory mode. They are tracked and surfaced in dashboards and audit records, but they do not block execution. The governance value is visibility: you still know which agents are consuming disproportionate resources, and you still have the kill-switch if an agent misbehaves. Advisory mode can be switched to enforcement mode at any time if the organization wants hard limits regardless of cost.

What evidence do enforcement receipts provide to an auditor?

Every kill-switch engagement, every budget denial, and every governance gate evaluation produces a signed enforcement receipt. The receipt captures the exact constraint state at the moment of decision --- remaining budget, agent identity, action type, and whether the action was allowed or denied. An auditor can export the complete receipt chain and verify it offline using only the public key, with zero trust in the platform required.

How Advisedly Helps

Advisedly ships kill-switches at three blast radii, dollar-denominated per-agent budgets with pre-flight cost estimation, a governance registry that every agent must pass through, and fail-closed behavior that chooses unavailability over ungoverned operation --- all producing cryptographic enforcement receipts as tamper-evident proof. The 11-provider BYOAI architecture means these controls apply regardless of which model provider handles inference, and the vendor-neutral facade ensures no single provider failure compromises the governance layer. To see AI governance with real kill-switches --- not just policies --- reach out to begin@advisedly.ai.