Scheduled data agents need three kill switches—not one “disable” button

Unattended data agents are becoming production jobs, but their shutdown controls are scattered across different products and control planes. Recent documentation from Databricks, Google Cloud and Microsoft shows why an operator should not ask only, “How do I disable the agent?” The practical question is whether the team can stop execution, credentials and consumption independently.

1. Stop the execution path

Databricks says Genie One scheduled tasks may execute generated code by default. Because nobody is present to approve each run, the product checks generated code against the task instructions and declines execution when it cannot confirm a match. Code runs in an isolated serverless sandbox and uses the scheduling user’s existing permissions. (Databricks code-execution documentation)

That makes pausing the schedule the first kill switch—but not the only one. A schedule pause stops future invocations; it does not, by itself, narrow the identity’s standing access or explain what happens to a run already in progress.

2. Revoke the execution identity and destination

Google Cloud’s Data Agent Kit separates immediate notebook execution from scheduled orchestration. Operators must explicitly enable the Notebook MCP execute_cell tool, while Scheduler can target a project and region different from the extension’s Common settings and then select a Managed Service for Apache Airflow environment. (Google configuration guide)

The operational implication is that disabling a local execution toggle does not necessarily disable a workflow already handed to a separate scheduler. A runbook should identify the scheduler project, region, Airflow environment and principal, then document the permission or credential that can be revoked without waiting for every workstation setting to change. Google’s security guidance also recommends constrained environments and warns that coding agents can mistake data for instructions. (Google prompt-injection guidance)

3. Stop consumption before shared capacity stops everything

Microsoft documents a different failure boundary for Fabric Data Agent. Agent token use appears as an AI Query background operation, while generated SQL is billed separately to its target engine. Microsoft also says background smoothing spreads consumption over time; when capacity is exhausted, all operations shut down. (Fabric Data Agent consumption; Fabric operations)

Smoothing is therefore not a kill switch. Teams need an admission rule or alert that can stop new agent work before a shared capacity reaches exhaustion, and they must monitor both the AI meter and the generated-query meter.

The rollout test

Before enabling any recurring data-agent task, rehearse three actions separately: pause the schedule, revoke the runtime principal, and block new consumption without taking unrelated workloads down. Record what happens to an in-flight run after each action. The vendors provide useful pieces—sandboxing, IAM checks, scheduler configuration and capacity metrics—but operators still have to assemble them into one emergency procedure.