Most scheduled AI tasks act as whoever created them. Anthropic's routines page says commits and pull requests carry your GitHub user, and connector actions use your linked accounts. A task is therefore a copy of your authority that keeps running when you are not at your desk.
What the documentation states
The Claude Code routines page says routines belong to an individual claude.ai account, are not shared with teammates, and count against that account's usage. Anything a routine does through your connected GitHub identity or connectors appears as you. That covers commits, pull requests, Slack messages and Linear tickets.
GitHub's scheduled workflows follow a similar idea. The Actions documentation says the actor can change in specific cases: if a user with write access changes the cron schedule of a deactivated workflow, that user becomes the actor, and notifications go to the user who last modified the cron syntax. For organizations using Enterprise Managed Users, the actor's account must be active or scheduled runs will not trigger.
Why this causes trouble
- Audit trails show a human name for an action no human took that day.
- A leaver's account carries live automations until someone disables them.
- Reviewers see a pull request from a trusted colleague and approve it faster than they would a bot account.
- Reading the logs, you cannot tell a person's click from a prompt's decision without extra metadata.
OWASP's excessive agency guidance recommends running actions under the individual user's identity with minimal scopes, instead of a broad shared service account. That advice is sound, and it has a cost: attribution blurs. You get least privilege per person but need another way to mark that an agent acted.
Four ways to handle it
| Approach | Gain | Cost |
|---|---|---|
| Run as the creator | Simple, scoped to one person | Blurs human and agent actions, breaks at offboarding |
| Shared service account | Survives staff changes | Broad access, weak attribution |
| Dedicated identity per automation | Clear owner, revocable alone | Needs setup and a registry |
| Delegated token tied to a sponsor | Both human and agent are named | Needs token exchange support |
For anything touching production or customer data, the third and fourth rows are worth the effort. Read what agent identity means and how to offboard an agent identity for the longer treatment.
Minimum records to keep
- The task name, owner and sponsor.
- The account or identity it runs as.
- The connectors, repositories and scopes it holds.
- How to tell its actions apart in downstream logs, such as a branch prefix, a label or a dedicated bot name.
- The date of the last access review.
Claude's routines push to branches prefixed with claude by default, which is a useful marker if you preserve it. Do not rename branches in a way that hides the origin.
Worked example: a mystery pull request
A repository gets a pull request titled "Update docs for renamed API" from a senior engineer at 02:14 on a Sunday. Two reviewers approve it on Monday because they trust the author and the diff is small. Later it emerges that the engineer set up a nightly docs task months ago and never reads its output. The change was accurate but also touched a configuration file the task should not have modified. Because the commit carried the engineer's name, the review treated it as a considered human change.
None of this required a malicious actor. It shows what happens when automation borrows a human identity. The documentation says commits and pull requests from routines carry your GitHub user. The reviewers had no signal that a model wrote the change except the branch prefix, which nobody checked.
Small changes that restore attribution
- Keep the branch prefix. Routines push to branches starting with claude unless the prompt says otherwise. Do not override this without a replacement marker.
- Add a label or a commit trailer by convention. A short line in the pull request description naming the task and its owner helps reviewers.
- Require extra review for automation branches. Branch rules can treat pull requests from the agent prefix differently, for example by requiring two approvals.
- Log the task name in downstream systems. Where a connector lets you set a display name or a message prefix, use it.
- Record the mapping. Your register should say which person's identity each task uses, so an incident responder can answer "was this a human?" in one lookup.
A decision guide
| Situation | Suggested identity |
|---|---|
| Personal productivity task touching only your own data | Your own account, with narrow scopes |
| Team task that writes to shared systems | A dedicated account or app with its own scopes and a named sponsor |
| Task that must survive staff changes | A dedicated identity, never a personal one |
| Task that acts on behalf of a person for a limited job | Delegated access that names both the person and the agent, if the platform supports it |
Where the platform only supports running as the creator, compensate with process: sponsors, registers and review.
Questions auditors and customers ask
Expect questions such as: do agents have their own identities, who approves their access, and can you tell human actions from agent actions in logs? An honest answer for most teams today is partial. Say what is true, such as "scheduled tasks run under the creator's account, are registered, and use a branch prefix for attribution", rather than claiming separate identities you have not implemented. The questionnaire guide on agent identities shows how to phrase that.
Cleaning up after the fact
If you find tasks running under personal identities, do not delete them in a panic. List them, decide which are worth keeping, and migrate those to a dedicated identity with fresh scopes. Remove the old grants only after the replacement works, so you do not break a process that people quietly depend on.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how an assistant's actions are scoped and recorded as you step through.
Where Safeguard fits
Safeguard includes agent identity as a GA capability, so an agent can hold its own revocable identity rather than borrowing a person's.
Quick check
If I leave the company, do my scheduled AI tasks stop?
Not automatically. Routines belong to your account, so ask an admin to disable or reassign them as part of offboarding. Confirm how your product handles a disabled account first.
Can a teammate see my routines?
The routines page says routines are not shared with teammates. That also means a team cannot easily review them, so keep your own registry.
Does GitHub treat scheduled workflow runs as coming from a person?
The Actions documentation describes an actor for scheduled runs, which can be the user who last changed the cron schedule or default branch. Check who that is for each workflow, since notifications go to the same person.
Sources
- Automate work with routines (Claude Code docs)
- Events that trigger workflows (GitHub Docs)
- OWASP LLM06 Excessive Agency
Last reviewed: 19 October 2026.
