Treat a leaver's scheduled AI tasks like their access: find them, decide to keep or retire each, transfer what is needed, and revoke the rest. Anthropic says routines belong to the individual account and act as that person, so they will not hand themselves over.
Why this is easy to miss
Offboarding lists usually cover email, source control, SSO and laptops. Scheduled AI tasks sit in a gap. The routines page says they belong to your individual claude.ai account, are not shared with teammates, and use your linked GitHub, Slack and other connector identities. If the account is disabled, behavior depends on the product, so do not guess. Test it, or ask the vendor.
GitHub scheduled workflows have a related quirk: the Actions documentation says the actor's account must be active for runs to trigger under Enterprise Managed Users, and notifications go to whoever last changed the cron syntax. A suspended user can silently stop a schedule.
Seven steps
- Ask before they go. Have the leaver list every scheduled task, routine, loop and automation, plus tokens they created for API triggers.
- Verify. Compare their list with product views and workflow files, using the inventory method.
- Decide per task. Keep, transfer, or retire. Document the reason.
- Recreate, do not share a login. For tasks worth keeping, a new owner should create them under their own account or a dedicated identity, with fresh scoping. Do not reuse the leaver's credentials.
- Rotate secrets. Regenerate API trigger tokens and any keys stored in environment variables or network secrets. The routines page says a token is shown once and can be regenerated or deleted.
- Revoke connector grants. Remove the leaver's OAuth grants to chat, ticketing and code hosting so nothing authorized by them remains usable.
- Confirm silence. After a full cycle, check that no run occurred and nothing was posted under their name.
Questions to settle in policy
- Who may create scheduled tasks that touch production or customer data?
- Must each have a named sponsor other than the creator?
- How long after departure may a task keep running before it is paused?
A sponsor rule helps: if every task has two names, offboarding one person never orphans it. See the sponsor role.
What good looks like
A clean offboarding for scheduled tasks leaves four artifacts: the leaver's list, the verified inventory, a decision per task with a named new owner where the task continues, and a dated confirmation that revoked tokens and grants no longer work. Keep them with the rest of the offboarding record. If an auditor later asks what happened to a person's automation, you can answer in a minute.
Timing matters too. Do the inventory in the notice period, not on the last day, because leavers are most helpful before they leave and least reachable after.
Contractors and temporary staff
Apply the same list to contractors and short term workers, often with a faster clock. Agents created during a project outlive it more often than people expect.
Worked example: a departing platform engineer
An engineer gives two weeks notice. The security lead sends a short form on day one: list every scheduled task, routine, loop or workflow you created, in any assistant, plus every token you generated for API triggers. The engineer lists five items. The lead then checks the products and repositories herself and finds seven.
The five known items break down as follows. A nightly pull request summary is useful and the team wants it to continue, so a teammate will recreate it under a dedicated identity. A docs drift routine opens pull requests that nobody reads, so it is retired. A morning briefing is personal and is deleted at the end of the last day. Two workflow schedules in repositories are kept, and their ownership moves to the platform team in the repository's code owners file.
The two extra items the engineer forgot are an API triggered routine wired to a monitoring tool and a one off task that should have fired weeks ago. The API token for the routine is regenerated at once, which breaks the integration until a new owner sets it up on purpose. That break is acceptable. It is better than a live token tied to a departed colleague.
The checklist as a table
| Item | Action | Evidence to keep |
|---|---|---|
| Scheduled and loop tasks | Keep, transfer or delete, each with a reason | The decision sheet |
| Routine API tokens | Regenerate or delete | Date and who did it |
| Connector grants | Revoke the leaver's grants at each service | Screenshots or admin logs |
| Repository workflow schedules | Update code owners, check the actor | Pull request link |
| Environment variables and network secrets | Rotate anything the leaver could read | Rotation ticket |
| Saved approvals on desktop tasks | Delete the task and archive its sessions | Confirmation |
Why the identity link matters
The routines documentation says anything a routine does appears as you. That means a departing person's routine is a live path to your systems under their name. If your policy suspends accounts at departure, check what the vendor says happens to routines then. If the answer is not documented, test it with a throwaway account before relying on it.
Edge cases
- Shared tasks that belonged to the team lead. Promoting someone does not change the identity the task uses. Recreate.
- Contractors on short engagements. Run the same list at the end of each engagement, not only at contract end.
- Tasks created by another agent. If an assistant can schedule tasks, include tasks created on a leaver's behalf.
- Backups of the leaver's laptop. Desktop tasks live in a folder on that machine. Wiping the machine removes the task files, but the vendor-side routines are unaffected, so handle both.
Make it routine
Add a line to the standard offboarding form: "Scheduled AI tasks and automations: listed, verified, resolved." Without a row on the form, the step will be forgotten.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the demo and watch how an assistant's access is scoped, which is what you are trying to remove or move at offboarding.
Where Safeguard fits
Safeguard's agent identity capability gives an agent its own identity with a lifecycle separate from any person, which makes the transfer step simpler.
Quick check
Will disabling a user stop their scheduled tasks?
It may, but confirm per product. Do not rely on it. Remove tasks and revoke tokens explicitly.
Should I reuse a leaver's token for a replacement task?
No. Issue fresh credentials with fresh scopes.
What is the single most important step?
Regenerating or deleting the API tokens and revoking connector grants. Those are the pieces that still work after the person has gone.
Sources
Last reviewed: 19 October 2026.
