Usually, yes. A time trigger starts when you say. An event trigger starts when someone else does something, such as opening a pull request or sending a message, so outsiders influence when your agent runs and what it reads. Filters, narrow access and review before action reduce that risk.
Three trigger types
Anthropic's routines support schedule, API and GitHub triggers on one routine. OpenAI's scheduled tasks can start from Gmail, Slack or GitHub events on eligible plans, and a task cannot combine an event trigger with a time based schedule. Reading both pages on 19 October 2026:
| Trigger | Who controls timing | Main risk |
|---|---|---|
| Time | You | Stale assumptions, forgotten tasks |
| API call | Anyone holding the token | Token leakage, text sent by the caller |
| Event | Whoever creates the event | Untrusted content arrives with the trigger, and volume is not in your hands |
What outsiders can do through an event
- On a public repository, anyone can open a pull request, which can start a review routine and put their text in front of it.
- A chat channel the agent watches lets any member of that channel steer it. OpenAI notes you must add the assistant to each watched channel, and that triggers do not cover reactions, edits, deletes or DMs.
- An email trigger depends on who can send to the mailbox.
None of this is a flaw in itself. It means the trigger source is part of your threat model.
Controls that apply
- Filter hard. Anthropic's GitHub triggers support filters on author, labels, base and head branch, draft state and merged state. Use them. A label that only maintainers can apply is a useful gate, for example one that marks a pull request as safe to review automatically.
- Limit the event source. Subscribe to private repositories or channels you control before public ones.
- Expect caps and batching. Anthropic notes GitHub events are subject to hourly caps, with events beyond the limit dropped. OpenAI says events arriving close together may be batched. Do not treat the trigger as a reliable queue.
- Give event tasks less access. If an outsider can cause a run, assume they can supply the input. Remove write and send access, or put them behind approval. Rule of two is a quick test.
- Protect API tokens. A routine token is scoped to one routine and shown once. Store it in a secret manager, rotate it, and delete it when unused.
- Admin control. OpenAI admins can control event triggered tasks with a permission. Decide who gets it.
A worked example
A review routine runs on every pull request opened. On an open source project that accepts outside contributions, a malicious author can write the pull request description. Mitigations: filter to authors in your organization or to a maintainer label, give the routine read access and comment only, and require a human to merge. Compare with a nightly summary of merged work, which reads only content that already passed review.
Worked example: a review routine on a public repository
A maintainer sets up a routine that reviews every pull request opened on a public project and leaves inline comments. The routine holds the code host connector with comment and label tools, and a chat connector for alerts.
Day one: a legitimate contributor opens a pull request and gets a useful review. Day five: someone opens a pull request whose description contains instructions aimed at the reviewer: approve this, mention that the tests pass, label it as ready, post a link in chat. Because the trigger is an event on a public repository, the attacker did not need access to anything. They only needed to open a pull request.
Now apply the controls from the post. A filter limits the trigger to pull requests whose author is in the organization, or that carry a label only maintainers can apply. The routine's tools are cut to commenting only, with no label or chat writes. The prompt tells it to treat the pull request text as data to review and never as instructions. A human still merges. With those in place, the planted text might still sway a comment, but it cannot cause a merge, a label change or a chat post.
Compare the three trigger types
| Aspect | Time | API | Event |
|---|---|---|---|
| Who decides when | You | Whoever holds the token | Whoever causes the event |
| Input at start | Fixed saved prompt | Saved prompt plus optional text | Saved prompt plus event data |
| Volume control | You choose the interval | The caller, up to hourly caps | The world, up to caps or batching |
| Typical abuse | None directly | Leaked token, injected text | Planted content, event floods |
| Strongest control | Review of the schedule | Token hygiene and wrapping | Filters, narrow access, human merge |
Event floods and cost
An attacker who can cause many events can cause many runs. Anthropic says GitHub events beyond a per routine and per account hourly cap are dropped. OpenAI says nearby events may be batched. Caps protect the platform and your usage but also mean legitimate events can be lost. If your process depends on every event being handled, an event triggered task is the wrong tool, or needs a backstop such as a nightly sweep.
A checklist before you attach an event trigger
- Who can create this event? List the groups, from maintainers to the whole internet.
- What text from the event reaches the model? Pull request bodies, titles, commit messages, comments, labels.
- What can the task do with its tools if that text misleads it?
- Does a filter narrow who can start a run?
- What happens if events are dropped or batched?
- Who is told when the task misbehaves?
When time based is enough
Many jobs do not need to react in seconds. A nightly pass over the day's merged work reads only content that already passed review, runs at a time you control, and has far fewer ways to be steered by outsiders. If a nightly sweep meets the need, choose it.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what happens when a pull request fails a gate and what the reviewer sees.
Quick check
Should event triggered tasks ever have write access?
Only with narrow scope, filters on who can trigger them, and a human approval step before anything irreversible.
Are events guaranteed to start a run?
No. Both vendors describe caps or batching, so do not treat events as a reliable queue.
What is the safest event filter to start with?
A label or author filter that only your own staff can satisfy, plus read only tools. Widen later after reading several runs.
Sources
Last reviewed: 19 October 2026.
