A scheduled agent can push a 2 a.m. configuration change without human approval when its runtime identity has write access and the scheduled workflow treats execution as pre-approved. The central risk lies in the permission model: a timer can activate authority that nobody reviews at the moment of use.
The approval gap starts before the task runs
A scheduled task usually looks harmless in isolation. It has a trigger, instructions, access to tools and a destination for its output. If those tools include production write access, however, the schedule becomes an unattended deployment mechanism.
The agent framework may be behaving exactly as configured. At 2 a.m., the scheduler starts the task. The agent reads the requested state, decides that a configuration differs from that state and uses an available deployment tool to correct it. No prompt appears because no approval checkpoint was defined for that action.
This exposes a common mistake in agent design: teams review what an agent is asked to do, but spend less time reviewing what it is technically allowed to do. Instructions express intent. Credentials determine impact.
A task described as “check configuration drift every night” sounds observational. Give it a token with write permission and a tool that can update production, and “check” can quietly become “check and change.” Natural-language boundaries offer little protection when the underlying capability remains available.
Default permissions become policy
Agent frameworks bring several permission layers together: the process account, connected tools, cloud roles, repository access, deployment credentials and any approval rules enforced by the framework. The effective permission is the broadest action available across that chain.
That matters because default settings tend to survive. A developer grants write access during setup to avoid blocking a test. The same credential reaches a scheduled environment. The task moves from an interactive session, where a person watches each step, into an unattended job. Nobody explicitly decides that overnight production changes are acceptable, but the system now permits them.
This is status-quo bias expressed in infrastructure. Once the workflow runs successfully, removing access feels like introducing risk. The absence of an incident gets interpreted as evidence that the permissions are appropriate.
Green execution logs can deepen that false confidence. A completed run proves that the framework executed its workflow. It does not prove that the change was authorized, reviewed or safe. The same distinction appears in Green Checks, Dead Application: operational signals answer only the questions they were designed to answer.
The practical test is simple. Ignore the task description and inspect the identity it uses. What could that identity change if the model misunderstood an instruction, selected the wrong target or encountered compromised context? That answer describes the real boundary.
Human approval must be enforced outside the prompt
“Ask before changing production” is useful guidance, but it is a weak control when written only in an agent prompt. Prompts influence decisions. They do not reliably remove capabilities.
A stronger design makes approval a technical requirement. The scheduled agent can inspect configuration, calculate a proposed diff and open a change request. A separate identity, activated after an authorized person approves the request, performs the deployment. The agent that recommends the change never holds the credential required to apply it.
High-impact actions also need narrow scopes. A configuration agent should receive access to the specific resources and operations required for its job, with production writes excluded by default. Temporary credentials can further limit the period in which authority exists. Environment boundaries should prevent a staging task from reaching production through a reused token or shared connection.
Approval records need enough detail to support an informed decision. “Approve config update” says little. The reviewer should see the target environment, exact diff, reason for the proposed change, expected effect and rollback path.
These controls add friction by design. The goal is to place that friction at the point where an automated observation becomes an external change. Routine reads can remain automatic. Production writes deserve a different path.
Audit the action path before the next scheduled run
Start with every task that can run while the team is offline. For each one, trace the complete action path from trigger to credential to tool to production resource. Check the framework’s configured approval behavior, then verify it with a harmless test in a non-production environment.
Review inherited permissions as carefully as direct grants. An agent may appear limited while its service account, plugin or deployment integration carries broader authority. Pay particular attention to generic automation identities shared across several jobs, since their permissions often accumulate over time.
Then separate observation, recommendation, approval and execution. Each stage should produce evidence the next stage can inspect. Failed approval checks should stop the workflow and alert an owner, rather than fall back to autonomous execution.
Behavioral monitoring can help identify unusual activity across agents, human identities and infrastructure. Darktrace has introduced a platform aimed at that problem. Detection remains a backstop, though. It may flag an unexpected overnight write after the agent attempts it. Least privilege and enforced approval can prevent the write from occurring.
The most useful review happens before tonight’s scheduler fires: open the credential attached to the job, list its production write permissions and remove every one the task does not need.
Comments
No comments yet.