Every major AI platform now ships a scheduler. Anthropic added routines to Claude Code in April 2026, as a research preview: a prompt, repository access, and connectors bundled into an automation that runs on a schedule, on an API call, or on a GitHub event, on Anthropic's cloud, with no laptop open. ChatGPT runs scheduled tasks server-side, with connectors to systems like email. Gemini offers scheduled actions, capped at ten active per account. Microsoft's Copilot Studio builds autonomous agents around scheduled and event triggers. And beneath the platform features sits computing's oldest surviving scheduler: nothing stops anyone from putting a command-line agent into cron or Task Scheduler on their own machine. The pattern is the same everywhere: describe a job once, grant access once, and an agent performs the job on a clock, with nobody watching.
The security conversation around agents has not caught up with this. Most of it still assumes a person in the loop: someone typing the prompt, someone watching the output, someone available to notice that something is off.
A scheduled agent is an unattended agent, and unattended is not a smaller version of interactive use. It is a different security posture, with different failure modes, and, usefully, much of it can be assessed before any run happens. This post is a threat model and a rubric for doing that. Many of the examples are drawn from patterns that show up in real scheduled-agent fleets.
What changes when the human leaves the loop
An interactive agent session borrows the judgment of the person driving it. The user reads the output as it streams, notices when the agent starts doing something strange, declines the permission prompt that doesn't smell right, and closes the terminal when in doubt. None of that transfers to a routine. Five things change, and each one changes the threat model.
Approval becomes configuration. In an interactive session, consent is granted moment to moment. In a routine, every permission decision is made once, at authoring time, and then exercised on every future run. There is no one present to approve a tool call, so the routine either has the permission standing or it fails. This pushes authors toward broad grants: the routine that failed at 2am because it lacked a permission gets that permission added, and permissions accumulate toward whatever makes the runs stop failing. The run that eventually misbehaves inherits all of them.
The author's identity becomes the agent's identity. Unattended runs authenticate with standing credentials, and those credentials are usually the author's. Microsoft's documentation for Copilot Studio is explicit about this: triggered agents authenticate with the maker's credentials, and any user who interacts with such an agent exercises the maker's access by default, a pattern Microsoft's own documentation flags as a data-protection risk. Claude Code routines are configured with access to a repository and your connectors. The practical consequence: a routine is a persistent, autonomous holder of a person's access, running on infrastructure that person does not watch.
The adversary can schedule a meeting. The classic prompt-injection scenario requires luck or social engineering: the poisoned content has to reach the model while a victim happens to be working. A routine removes the luck. It reads fresh external content, the new issues, the overnight email, the changed web page, on a published cadence, from predictable places. An attacker who wants their content in front of your agent does not need you to click anything. They need to put it where the routine reads, before the routine runs. Nightly runs give them a delivery window every 24 hours, and each run is a fresh chance for the same payload. Routines triggered by API endpoints or repository webhooks go further: the attacker who can reach the endpoint or influence the event doesn't have to wait for the clock at all.
Nobody is watching the run. An interactive user is a detection mechanism, an imperfect one, but present. A routine's audience is its output, typically read minutes to days later, often skimmed, often trusted precisely because it has been correct every previous morning. If a run is compromised, exfiltration and side effects happen during the run; the human, at best, sees the polished artifact afterward. Detection latency stops being seconds and becomes however long it takes someone to notice that a report, a PR, or a ticket is not what it should be. For a routine whose output nobody reads closely, that can be never.
State compounds across runs. Routines are rarely stateless. Webhook-driven routines feed follow-up events into the same session. Agents can keep memory files, notes, and working directories between runs. This is what makes them useful, and it means a single successful injection does not have to win everything in one run. It can plant an instruction, a note, a "lesson learned" that the agent itself wrote down, and let the next twenty runs execute it. In an interactive session, closing the window usually ends the compromise. A routine's compromise can be persistent by design.
Where the run executes changes who can see it
Routines come in two shapes, and the difference is worth naming before any rubric is applied.
Cloud routines, the platform features above, run on the vendor's infrastructure. Their reach is whatever the bundled connectors grant, and that boundary is real: a cloud routine cannot read a laptop's filesystem or borrow an SSH key from a home directory. Their runs also happen inside the platform, which means they can be enumerated from the platform's own surfaces and are subject to whatever enforcement already governs the organization's agent traffic there.
Endpoint routines are older and quieter: a cron entry or a scheduled task that launches a command-line agent, headless, on a workstation or a server. There is no cap on how many can exist, and the schedule itself is invisible to the platform: the runs it launches look like any other agent session on the account, and nothing marks them as scheduled, while the registration lives in a crontab or task list that only tooling on the endpoint can read. The privilege answer is also categorically different. An unattended run cannot stop to answer a permission prompt, so these jobs are typically configured to pre-approve their own tool use, and the agent then operates with the OS user's ambient authority: the dotfiles, the cloud CLI credentials, the SSH keys, the kubeconfig, most of what the developer could touch by hand. A nightly fix-the-top-bug cron job runs with roughly the reach of its author, at an hour when its author is asleep.
The rubric that follows applies to both shapes. But two of its dimensions, privileges and lifecycle, return systematically different answers for endpoint routines, and the inventory problem splits in two: cloud routines can be listed from platform surfaces, while endpoint routines take collection that reaches the machine.
The posture model
The useful property of a routine is that its shape is declared before it ever acts. The prompt, the tool grants, the credentials, the input sources, the output destinations, and the schedule are all static configuration. Unlike an interactive session, whose risk depends on what a human does in the moment, a routine can be assessed at rest. Six dimensions cover most of what matters (Figure 1).
Figure 1 · The six posture dimensions: each is answerable from a routine's configuration, before any run.
1. Inputs: can an outsider influence what the agent reads? The single most important question. A routine that summarizes an internal database it alone reads is in a different class from one that reads inbound email, public issues, package changelogs, or the open web. Every externally influenceable input is a channel through which an attacker can address your agent directly, on schedule.
2. Privileges: what does the run hold? Which identity, which scopes, which secrets, and for how long. A per-routine token scoped to one repository and one Slack channel is a contained failure. The author's own identity, spanning everything the author can touch, is not. Watch for privilege accumulation: grants added over time to stop nighttime failures, never removed.
3. Side effects: what can the run change? Read-and-report routines fail differently from routines that write: open PRs, send messages, file tickets, modify records, call deployment hooks. Egress deserves its own look. An agent with both untrusted inputs and an open outbound channel (web requests, email, a chat webhook) has everything an exfiltration needs.
4. Oversight: is there a gate between output and effect? A draft PR a human merges, a draft email a human sends, a proposed change a human applies: these keep a review step between the agent and the world. Direct effects, merged code, sent mail, executed remediation, remove it. A review gate is a real control even when the reviewer authored the routine, because the gate operates at effect time, when the compromised run is visible, not at authoring time, when it wasn't.
5. Cadence and reachability: how often, and who can make it run? Frequency multiplies exposure: a routine that runs hourly gives the same payload dozens of chances a week. Predictability helps the attacker stage content ahead of the run. And a trigger reachable from outside, an HTTP endpoint, a webhook responding to repository events, converts "runs on a clock" into "runs when someone else decides," which makes the trigger itself part of your attack surface.
6. Lifecycle: who owns it, and when does it end? Routines are easy to create and easy to forget. Platform quotas hint at the scale: individual plans allow a handful of scheduled jobs, and Claude Code's team tiers allow up to 25 routine runs a day. The failure mode is organizational: routines whose authors changed teams, whose purpose lapsed, whose credentials still stand. An unowned agent with standing access is shadow IT that acts.
Score each dimension, and let the worst combination dominate rather than averaging: a routine with untrusted inputs, direct side effects, and no oversight gate is critical no matter how tidy its lifecycle is. The highest-risk shape to look for is the trifecta from dimensions 1, 3, and 4: outsider-influenceable input, write access to something that matters, and no human between the two (Figure 2).
Figure 2 · The highest-risk shape: untrusted input and consequential writes with no gate between them. Breaking any one leg breaks the shape.
Three worked examples, in ascending order of concern:
- A nightly routine that summarizes an internal dashboard into Slack. Inputs internal, effects limited to one message, read-only credentials. Low. The residual risk is trust in the output itself: people will act on what it says, so its transcript should be retained and its output worth an occasional spot check.
- A dependency-update routine that opens draft PRs. Inputs are semi-external (registries, changelogs, advisories can be influenced), and it writes, but the write is a draft gated behind human review and CI. Moderate, and the gate is what keeps it there. Auto-merge would move it two classes up in one configuration change.
- An API-triggered incident-response routine with broad connectors and direct remediation. Externally reachable trigger, privileged credentials, direct side effects, no gate, and it runs precisely when things are already on fire. Critical by construction. This is the routine to redesign rather than merely monitor.
The scheduler is an attack plane of its own
Everything so far treats the routine as the potential victim. The scheduler also deserves attention as a mechanism an attacker can use.
Scheduled tasks are one of the oldest persistence techniques in computing: attackers have been registering cron jobs and scheduled tasks to survive reboots and cleanups for decades. Agents inherit that playbook with a twist. An agent that can create or modify routines can be talked into scheduling one, which turns a one-shot prompt injection into standing access: the injected instruction does not have to exfiltrate anything today, it only has to install a quiet nightly job that does it from now on. The question to ask of every agent surface in your estate: which agents can write to the schedule, and what does it take to make them do it?
The routine's own configuration is a second target. Some routines fetch their working instructions at run time from a source someone can edit: a wiki page, a shared document, a file in a repository. That design makes the mutable source the real prompt, and whoever can edit it reprograms every future run without ever touching the schedule. A routine built this way should score its instruction source as an input, because it is one, and often the least protected one.
Triggers round out the plane. An API-triggered routine is an HTTP endpoint with a token; a webhook-triggered one follows repository events. Whoever can reach the endpoint, steal the token, or shape the event decides when the agent runs, and often what context is in front of it. And a routine's output is frequently another agent's input, a report, a ticket, a memory note, which makes a compromised routine a distribution channel into every session that reads its artifacts.
The same policies, with nobody to back them up
A scheduled run is not a special kind of traffic. When a routine fires, its prompt enters the model the way a user message does, and its tool calls and results flow through the same paths an interactive session uses. Every enforcement point that sits on the run's path, policy on tool calls, controls at the model boundary, rules on what data may leave, sees a routine's run the same way it sees an interactive one, and applies to it unchanged. That is worth stating plainly because its inverse is a finding: an organization that enforces policy on employees' agent sessions but exempts its schedulers has built itself a bypass and named it automation. The geometry from the previous section carries over, too: a cloud routine's run never crosses the endpoint or the corporate network, so only controls at the platform or the model boundary stand on its path, while an endpoint routine runs exactly where endpoint enforcement lives.
What unattended changes is not the enforcement but what stands behind it. In an interactive session, enforcement has a human backstop: someone notices the strange turn, declines the prompt, closes the window. A routine has no backstop, and that raises the bar in two ways. Runtime controls must be automated and blocking, because a control that ends with someone reviewing an alert in the morning is, for a run that finished at 2am, a post-mortem. And posture has to do the work attention used to do: bounding what the worst run can reach before anything fires at all. Pre-run posture and in-run enforcement are not rivals; they are the two controls left standing once nobody is watching.
The best time to shrink a rogue routine's options is before its unattended run. The only control present during the run is the one that was automated in advance.
If your organization runs routines today
Practical steps, roughly in order:
- Inventory with tooling, not surveys. You cannot assess what you cannot list, and routines live scattered across platform accounts and crontabs. A manually maintained list is stale the week it is written: enumerate cloud routines from your platforms' admin and audit surfaces where those exist, and from user surfaces where they don't; discover endpoint schedules with tooling that reaches the endpoints; and keep both refreshed continuously.
- Score the trifecta first. For each routine: untrusted inputs? direct side effects? human gate? Anything that hits the first two without the third is your priority list.
- Author consequential routines from scoped identities. Today's platforms largely bind a run to its author's access: Copilot Studio documents that triggered agents authenticate as their maker, and the consumer schedulers use the author's connected apps. Per-routine credentials mostly do not exist yet, so create routines that matter from purpose-built accounts whose connectors grant only what the job needs, and treat author-bound execution as a standing entry in the risk score.
- Prefer drafts over deeds. Draft PRs, draft emails, proposed changes. Keep a human between the agent and anything irreversible, and treat every removal of such a gate as a change that needs sign-off.
- Pin the inputs, then treat them as untrusted anyway. Named sources beat open browsing: a routine that reads three specific feeds is analyzable, while one that searches the web each night is exposed to whatever the search returns. But pinning narrows the surface without cleaning it, a named feed can be poisoned too, so the inspection that screens external content for injected instructions has to stand between every input and the model, pinned or not.
- Treat external triggers as attack surface. Endpoints and webhooks that start agent runs deserve the same care as any other exposed interface: token hygiene, caller validation, rate limits, and monitoring.
- Impose expiry from outside, because the platforms won't. No scheduler today offers a review date or an expiry on a routine, so carry them in your inventory instead: every routine gets an owner and a next-review date there, and when the owner leaves or the date lapses, the default is decommission, not adoption.
- Enforce and monitor routine traffic exactly as you do user traffic. A routine's run produces the same prompts and tool calls an interactive session would, so the policy enforcement on its path applies to it unchanged, and should be applied. The same goes for monitoring: run records already exist on these platforms; route them into the same review your interactive sessions get.
Declared before it acts
There is a genuinely optimistic way to read all of this. Interactive agent use is hard to govern because its risk is created live, by whatever a person and a model improvise together. A routine is the opposite: it is the rare piece of the agentic estate whose shape is declared before it acts. Its input sources, privileges, effects, oversight, cadence, and ownership are written down, static, and inspectable. The one thing the configuration cannot contain is the content those sources will deliver on a given night: a routine that reads unread email declares the mailbox, never the messages. That is why securing routines takes the two controls organizations already understand: review of the declared shape before the run, and the same automated enforcement during it that governs interactive use, standing where the run's actual content arrives.
Scheduled agents will keep multiplying, because they are useful, and most of them will be created by people optimizing for the job, not the posture. The organizations that handle this well will be the ones that could answer, on any given morning, a plain question: what is scheduled to run tonight, as whom, reading what, allowed to change what, and who checks it?
An unattended agent has no one watching it. What it can have is a boundary set before it starts, and policy enforced while it runs.
Sources: Anthropic's routines announcement, OpenAI's scheduled tasks documentation, Google's scheduled actions help, and Microsoft's Copilot Studio trigger documentation.
