Before you trust an AI assistant with scheduled tasks, ask where the job runs, which identity it uses, what it may touch, how failures are reported, and how you stop it. A schedule turns a one-off prompt into unattended automation, so the answers matter more than the demo.
Why a schedule changes the risk
A prompt you type is watched by you. A scheduled task is not. It runs at 3 a.m., reads whatever it can reach, and acts without anyone checking the first step. OWASP's guidance on excessive agency names the root causes as excessive functionality, excessive permissions and excessive autonomy. Scheduling adds a fourth ingredient: no human is present to notice when any of those go wrong.
That is not an argument against the feature. Many scheduled tasks are low risk, such as a weekly summary of closed tickets. It is an argument for asking the same questions every time, so the easy cases pass quickly and the risky ones get a closer look.
The ten questions
| # | Question | What a good answer sounds like |
|---|---|---|
| 1 | Where does the job run: your device or the vendor's cloud? | A clear answer, plus what happens when the device is off |
| 2 | Which identity does it act as? | A named user or a dedicated agent identity, never a shared admin |
| 3 | What can it read and write? | A list you can review and narrow per task |
| 4 | Can it call tools that send, delete or pay? | Those actions can require approval even on a schedule |
| 5 | Who can create, edit and pause schedules? | Role based, with an owner recorded per task |
| 6 | What happens on failure? | An alert to a named person, not a silent skip |
| 7 | What happens on a retry or a missed run? | Documented behavior, ideally safe to repeat |
| 8 | Is every run logged with inputs, tools and outputs? | Exportable logs with retention you can state |
| 9 | Can an admin disable the feature org wide? | Yes, and per team |
| 10 | How do you stop one task right now? | A pause control and a way to revoke its access |
How to use the table
Score each answer as confirmed, claimed or unknown. Confirmed means you saw it in the product or in written documentation. Claimed means a salesperson said it. Unknown means nobody could answer. Treat unknown on questions 2, 4 and 10 as a stop sign for anything beyond read-only tasks.
Ask for the answers in writing. If a vendor cannot put the identity and permission model on paper, you will not be able to put it in your own questionnaire answers either.
Start with read-only tasks
A sensible first set of scheduled tasks reads and summarizes. Examples: a Monday digest of open pull requests, a daily list of new advisories for your dependencies, a report of stale access grants. These produce text for a human to read. If the model gets something wrong, someone reads a wrong summary rather than something changing in production.
Move to tasks that write, send or change things only after you have logs from a few weeks of runs and an approval step you trust. This follows the OWASP advice to minimize extensions, minimize their functionality and permissions, and require user approval for high impact actions.
A worked example: the Monday digest
Suppose a team lead wants an assistant to post a digest of open pull requests every Monday at 8 a.m. Run it through the ten questions.
- It runs in the vendor's cloud, so it fires even if nobody is online.
- It acts as the team lead's account. That is acceptable for a read-only task, but it will break if the lead leaves.
- It reads the repository list and pull request titles. It cannot read code.
- It can post to a chat channel, which counts as a send action, but only to one channel.
- The lead owns it, and a deputy can pause it.
- A failure emails the lead.
- A missed run is skipped, and the next one fires a week later.
- Run history is visible for 30 days.
- An admin can disable the feature for the whole company.
- Pausing it takes one click.
Most answers are fine. Two deserve a note: the creator identity (move it to a team account later) and the 30 day history (check whether that meets your own log retention rule). The review took ten minutes, and the task shipped with two follow-ups on a calendar.
A harder example: the nightly cleanup
Now suppose someone wants a task that closes stale tickets every night. Questions 3 and 4 change the picture. The task can edit and close records, which are write actions, and a wrong judgment by the model is applied to many tickets before anyone looks. Here you would ask for a dry run mode that lists what it would close, an approval step before the first real run, a cap on how many tickets it may close per run, and a log of every ticket touched. If the product offers none of these, keep the task read-only and have it produce a list for a person to act on.
Step by step: adding the questions to your process
- Put the ten questions on a one page form that task creators fill in.
- Mark each answer confirmed, claimed or unknown.
- Let low risk tasks, meaning read-only and internal, proceed on a lightweight review.
- Send write or send tasks to a named reviewer.
- Revisit every task when its owner changes roles.
Keep the forms. A folder of short, dated forms is simple evidence that scheduled automation is under control.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a recurring check reports a change, and ask which of your own scheduled tasks would raise the same kind of alert.
Where Safeguard fits
If your assistant reaches security data through MCP, Safeguard's MCP Guardrail and agent identity features let you give each agent its own identity and policy. You can also run a free scan at gold.safeguard.sh/scan to see your dependency picture before you automate anything on top of it.
Quick check
Is a scheduled AI task riskier than a manual one?
Usually yes, because nobody watches the run. The same permissions that are fine under supervision deserve a tighter review when the task runs unattended.
Do all ten questions apply to every task?
No. A read-only digest needs fewer controls than a task that can send messages or change records. Use the table to decide how much review each task gets.
Is a scheduled task safe to leave running for months?
Not without a review date. Put a recurring review on the calendar, check that the owner still works there, and confirm the permissions still match the task.
Sources
Last reviewed: 19 October 2026.
