A one page policy for scheduled AI tasks should say what counts as a task, who owns each one, what access it may hold, which actions need a human, when it expires, what is logged and how exceptions work. Keep it short enough that people read it. This is a template, not legal advice.
Why a separate page
General AI policies talk about what to paste into a chat. Scheduled tasks raise different questions because they run without a person, hold standing access and keep going after attention moves on. If you already have an assistant policy, add this page as an appendix. See whether you need a separate policy.
Outline to adapt
1. Scope. This policy covers any saved prompt that runs without a person starting it: schedules, API triggers, event triggers, loops and local automations, in any assistant.
2. Ownership. Every task has a named owner and a sponsor, recorded in the register. Owners are responsible for its output and access.
3. Access.
- Tasks use the least access that lets them succeed.
- Connectors and repositories are listed individually, not inherited by default.
- Tasks do not use shared personal credentials.
4. Actions that need a human. Tasks may read and summarize freely. Tasks may not send external messages, change production, delete data or merge code without review. High impact steps go through a person or a protected workflow. Approval tiers by reversibility can supply the categories.
5. Untrusted input. Tasks that read outside content must not also hold write or send access to sensitive systems without a documented review.
6. Lifetime. Every task has a review date, at most 90 days out. Expired tasks are paused until reviewed.
7. Logging. Run history and transcripts for tasks that write are kept for the period set in the logging policy. Secrets are not placed in prompts or transcripts.
8. Change control. Edits to prompts, connectors or schedules are recorded. A model change counts as a change.
9. Incidents. Anyone can pause a task they suspect misbehaves. Report it to security. The kill switch steps are in the kill switch guide.
10. Exceptions. Requested in writing, approved by the sponsor and security, time boxed.
Make it enforceable
A policy nobody can check is a wish. For each line, name how you will know: the register for ownership, admin console settings for availability, access reviews for scope, and spot checks of run history. Where tools allow, enforce with settings instead of reminders.
Rolling it out
Start with a thirty day amnesty. Ask everyone to register the tasks they already run, with no penalty for tasks that predate the policy. Then apply the rules to new tasks and review old ones in order of risk: tasks that write or send first, read-only summaries last. Publish the register so teams can see what exists and avoid duplicates. Review the policy itself every six months, because the products change faster than most policy cycles, and several of the features discussed here are labeled preview by their vendors.
Keep it honest
Do not claim controls you have not tested. If you tell a customer that all scheduled tasks are reviewed quarterly, be ready to show the last review. Wording that promises less and delivers it beats the reverse.
Worked example: policy text applied to a real request
A developer asks to create a routine that reads issues from a public repository, labels them, and posts a summary to a team channel. Walk the request through the policy outline.
Scope: it is a scheduled task, so the policy applies. Ownership: the developer is the owner, and her manager is the sponsor. Both are written into the register. Access: the request lists the issue tracker connector and the chat connector and nothing else, so it passes the rule against inheriting defaults. The developer confirms that the tracker grant covers one project.
Actions needing a human: labeling is low impact and reversible, and the summary goes to an internal channel, so no approval is needed. A rule that the task may not send external messages is met. Untrusted input: the task reads public issues, which anyone can write. Policy line five says such a task must not hold write access to sensitive systems without a documented review. Labeling the public project's issues is not sensitive, so the reviewer notes that and approves. Lifetime: a review date is set for 90 days out. Logging: run history is kept for the standard period. Change control: edits go through the register. Incidents: the developer knows how to pause it.
The whole review takes ten minutes, and it leaves a record. That is the test of a good policy: a normal request clears it quickly, and a risky one stops at a specific line.
Rules as testable statements
| Policy line | How to test it |
|---|---|
| Every task has an owner and sponsor | Sample ten register rows, call each owner |
| Access is listed, not inherited | Open five tasks, compare connectors to the register |
| No external sends without review | Search run histories for sent messages |
| Review date within 90 days | Filter the register for overdue rows |
| Kill switch works | Pause a test task and confirm it stops |
Common objections and answers
"This slows people down." The first task takes ten minutes. Later ones are faster as people learn the pattern. Compare that with the time spent after one bad run.
"We cannot see everyone's tasks." True for some products. The policy still sets expectations, and discovery fills the gap over time.
"The vendor handles security." The vendor provides controls. Reading their docs shows you still choose scopes, connectors and approvals.
"Our tools change too fast for a policy." Write principles and keep product details in a short appendix reviewed twice a year.
What not to put in the policy
Do not put product specific settings in the main text. Do not name individual products unless you must. Do not promise audit outcomes. Do not include numbers you have not checked, such as retention periods your tools cannot deliver. And do not copy another company's policy without reading it against your own environment.
Try it yourself
Click through it at your own pace, or open it full screen.
See how one rule maps to several framework controls, then think about which line of your policy would carry the evidence.
Where Safeguard fits
Safeguard offers policies, gates and guardrails plus compliance and evidence automation, which can help enforce and document rules like these.
Quick check
Does this page replace my AI acceptable use policy?
No. It adds the controls specific to unattended work. Keep both, and cross reference them.
Who should approve exceptions?
The task sponsor and a security reviewer, with a defined end date.
Do I need legal review of this policy?
Have your legal or compliance team review it, particularly any parts touching personal data, employee monitoring or customer commitments. This article is not legal advice.
Last reviewed: 19 October 2026.
