> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.6-scheduled-and-background-tasks.md). # 3.6 Scheduled and background tasks Unattended agent runs execute without a human watching, so they need stricter controls than interactive sessions. *Last reviewed: August 18, 2026* {% hint style="info" %} Unattended agents need tighter boundaries than interactive sessions. The user is not watching when the run drifts. {% endhint %} ## Scheduled and background tasks: what security teams need to know Scheduled and background tasks turn an AI workflow into automation. That can be useful for reporting, maintenance, triage, and repetitive analysis. It also removes the user's real-time judgment from the loop. The safe pattern is to start with read-only reporting, define stop conditions, test runs before scheduling, and require a stronger review before any background task writes to an external system. ## Common scheduled and background tasks security failures * A scheduled task inherits a broad user session or old credentials. * The task runs after the owner changes roles. * A report task gains write actions without a new review. * Failures are silent because no one owns monitoring. * The task runs against production data without a retention decision. ## Scheduled and background tasks security controls checklist * Assign every scheduled task an owner and review date. * Keep initial scheduled tasks read-only unless a write action is reviewed separately. * Define stop conditions, retry limits, and alert paths. * Log each run, data source, tool call, output location, and failure. * Review tasks after vendor releases, credential changes, and incidents. ## Anthropic ### Overview Anthropic has two documented scheduling surfaces. Claude Managed Agents support scheduled deployments for recurring agent work, with vault-based authentication so unattended runs do not carry static secrets; note that Managed Agents is in beta and sessions persist state server-side without current eligibility for zero data retention or HIPAA BAA coverage, which is a gate for regulated data. Cloud sandbox network access stays disabled unless the environment enables it, the right default for a run nobody is watching. Claude Cowork scheduled tasks are the end-user equivalent. They run with the same connectors, skills, and plugins as regular Cowork work and execute remotely by default, even when the user's computer is asleep. A task tied to a local folder or app runs locally and needs the desktop environment. Scheduled tasks can be created and reviewed across supported Cowork surfaces; the Cowork organization toggle remains the broad kill switch for Team and Enterprise. Claude Tag routines add scheduled jobs, channel watches, and repository-event follow-ups inside Slack. They inherit the channel's connections and permissions, and any channel member may be able to create standing work unless governance narrows that path. Record the routine owner and trigger, cap spend, and use the Claude Tag Audit view plus the channel thread and target-system logs to review what ran. ### Anthropic documentation * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) * [Audit and review Claude Tag](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview ChatGPT Work can run once, on a schedule or trigger, or as a monitor. Web scheduled tasks can use uploaded files, connected tools, skills, and plugins, but cannot work directly in a folder on the user's computer. Desktop scheduled tasks can use local projects and run in the project directory or an isolated worktree, and the computer and app must stay running when local files are required. The old split between ChatGPT Tasks and Codex Automations has converged into a Scheduled surface across Chat and Work, with desktop project and worktree execution for local tasks. Review each task's execution location, connected tools, local folder, credentials, and approval profile. CLI and IDE clients can prepare the workflow but do not provide the Scheduled management interface. ### OpenAI documentation * [Scheduled Tasks in ChatGPT](https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt) * [Scheduled tasks](https://learn.chatgpt.com/docs/automations) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about scheduled and background tasks ### What are scheduled AI tasks? They are agent runs that start on a timer or trigger rather than with a person driving each step: one-off reminders, recurring reports, monitoring jobs, or unattended code maintenance. Current examples include ChatGPT Scheduled tasks from Chat or Work, Claude Cowork scheduled tasks, and Managed Agents scheduled deployments. The common property is that no one is watching when the run drifts. ### What should scheduled tasks be allowed to do? Start read-only: reporting, analysis, triage, and monitoring. Add write actions only after a separate review that names the systems written to and the failure handling. The inherited-permission question matters more than the schedule, because a task typically runs with its creator's connectors and sandbox settings, so review those, not just the cron line. ### What are stop conditions? Concrete bounds that end a run before it does damage: a maximum number of files changed, a spend or token ceiling, an error-rate threshold, a data-volume cap, or a denylist hit. For example, a nightly dependency-update automation should stop and alert, rather than retry, if it would modify more than twenty files or touch anything outside its repository. Without stop conditions, a misfiring task repeats its mistake on schedule. ### Who owns a background agent? Assign both a business owner accountable for the task existing and a technical owner accountable for its permissions, credentials, and failures, and record both in a task register. Ownership must survive role changes; a scheduled task that outlives its creator's tenure is a classic orphaned-automation finding. Review the register at the cadence set in 6.7. ### What should be monitored? Run status and failures, data sources touched, tool calls, output destinations, approval fallbacks, and volume anomalies against the task's baseline. Platform inboxes such as the Codex Triage inbox help, but only if someone owns triaging them. Silent failure is the characteristic scheduled-task incident: nothing alerts, and the gap is found weeks later. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy.md) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility.md) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.6-scheduled-and-background-tasks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.