# Unattended agents: bound schedules, retries, cumulative usage and stale approvals Canonical: https://www.web3sec.news/blog/unattended-agent-schedules-and-budgets Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Unattended automation Published: 2026-11-08 Updated: 2026-11-08 Make repeated agent work stop predictably when permissions, timing, costs or external side effects no longer match the approved task. ## The short answer Give every unattended agent task an owner, narrow permissions, an expiration and enforced limits on execution, retries and cumulative usage. Recheck authorization when a delayed run starts and before consequential actions. Prevent duplicate side effects across concurrent runs, monitor missed schedules and keep an independent control that stops both queued and active work. ### Diagram: Content is evidence. Approval is authority. Keep source material separate from the authority to act. ![Sources enter a working context and produce a proposal. A separate approval gate checks scope before a tool action. Untrusted content cannot authorize execution.](https://www.web3sec.news/diagrams/trust-boundary.svg) [Full-size SVG](https://www.web3sec.news/diagrams/trust-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/trust-boundary.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Write an authorization that survives repetition The task owner should record the intended outcome, data sources, allowed destinations, execution identity, recurrence and end date. Separate actions that may run unattended from those requiring review. A daily digest and an automated account change have different consequences even if both begin with reading the same data. Define who takes responsibility when the usual owner is unavailable or leaves the organization. Store that task configuration outside retrieved content and version it with meaningful changes. Revalidate source access and recipient ownership at execution time. A queued job may start after a user revoked access or after the business context changed. Do not let a previous approval silently cover a modified destination, larger scope or a different irreversible action simply because the scheduler retained the original task name. ## Bound retries, concurrency and cumulative exposure Set execution timeouts, maximum attempts, maximum acceptable event age and a response for exhausted work. AWS EventBridge Scheduler documents retry count, event age and dead-letter handling as explicit delivery controls. Use the equivalent supported controls in the system you deploy, and distinguish delivery retries from retries inside the agent loop. Otherwise two independent retry layers can multiply the work the owner intended to permit. Use concurrency limits and durable idempotency for external side effects. GitHub’s workflow concurrency documentation is one example of controlling overlapping runs, with platform-specific queue behavior. Separately enforce cumulative budgets across executions for model usage, external APIs, storage and messages. Count pending and in-flight reservations where necessary, and keep the agent unable to increase its own limits or relabel a failed task to evade them. ## Treat timing and approvals as state to verify A schedule is not proof that work ran on time. GitHub documents that scheduled workflows can be delayed and some queued jobs dropped under load. Monitor the last successful result and expected freshness, not only trigger configuration. Define whether a late job should run, skip or request review. A stale result published confidently can be more misleading than a visible missed-run notification. For approval-dependent work, bind approval to the specific action and expire it when its supporting data is no longer current. A human being offline is not an approval signal. Keep pending work visible without executing its dependent action, and use a defined escalation path for time-sensitive decisions. Record the run identifier, task version and authorization used so duplicate or delayed activity can be reconstructed. ## Exercise stop, duplicate delivery and ownership loss Use synthetic accounts and harmless side effects to test two overlapping triggers, a failed call retried after success, a delayed event and an expired approval. Confirm that aggregate limits and idempotency prevent excess execution. Stop the automation while a worker is active and verify the documented behavior for queued tasks, downstream jobs and already accepted external requests. Do not assume that canceling the visible run retracts a completed request. Review failed-job or dead-letter storage because it may contain sensitive input and can replay old authority. Reconcile task ownership and credentials during offboarding, and archive obsolete schedules deliberately. Restore a stopped task only after accounting for outstanding work and resetting the intended limits. The operating record should show when the automation last produced a verified result and how the owner can prevent its next side effect. ## Controls to take away - Repeated authorization needs explicit limits and ownership. - Concurrency control and idempotency address different failure modes. - A configured schedule is not evidence of a timely completed task. ## Work through the boundary Local planning worksheets; they do not inspect or change accounts or environments. - [Build a permission review plan](https://www.web3sec.news/tools/agent-permissions): Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Record task owner, scope, destinations, recurrence and expiration. - [ ] Set retry, event-age, timeout and cumulative-usage limits. - [ ] Prevent duplicate side effects across overlapping runs. - [ ] Expire approvals and verify authorization when delayed work starts. - [ ] Test stopping active, queued and downstream work. ## Common questions ### Does scheduling a task authorize every later action? No. The schedule should define a bounded task and permitted effects. Delayed runs, new destinations or changed transaction details may require renewed authorization, especially after access, ownership or source data changes. ### Is a per-run token budget enough? It limits one source of usage within one execution. Add aggregate limits across retries and concurrent runs, plus separate controls on external API calls, generated artifacts and consequential side effects. ### What must the stop control disable? New triggers, pending jobs, active workers and delegated downstream work may require separate controls. Verify that the task’s credentials and scheduled continuations cannot keep operating after the owner disables the automation. ## Sources & further reading - [AWS: scheduler retry policy and maximum event age](https://docs.aws.amazon.com/scheduler/latest/APIReference/API_RetryPolicy.html) - [GitHub: workflow and job concurrency](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) - [GitHub: scheduled event timing and limitations](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)