What happened
GitHub added comment triggers for Copilot cloud agent automations on August 3. An automation is a standing rule you set up once, and Copilot’s cloud agent (a version of Copilot that runs tasks in the background instead of waiting for you to type in a chat) carries it out whenever the trigger fires.
Until now, those triggers were things like opening a pull request (the page where a proposed code change sits before a team reviews and merges it) or applying a label. Now a comment on an issue or pull request can start one too. You pick the trigger text yourself when you set it up. GitHub’s own examples: comment on a pull request to generate or update documentation for the code change, comment on an issue to have the agent investigate an error log or stack trace, or comment on a pull request to spin up follow-up issues for cleanup work later.
To set one up, open your repository’s Agents tab, choose Automations, and define the comment text that should fire it. Automations are available on Copilot Pro, Pro+, Max, Business, and Enterprise. On Business and Enterprise, an administrator has to turn on the Copilot cloud agent policy before anyone on the team can use it.
Why it matters
An automation that fires on a comment runs without anyone directly starting a task, which is exactly why GitHub built in a default restriction: automations ignore comments from anyone who doesn’t have write access to the repository. Write access means someone can push code directly to the repository, a step above just opening a pull request from a fork (their own separate copy of your repo, which is how outside contributors usually propose changes). That default keeps a random commenter, on a public repo or one with outside contributors, from being able to set off an automation just by typing the right words in a comment.
GitHub also lets you turn that restriction off, so the automation responds to anyone’s comment, including people without write access. The changelog and docs don’t spell out a reason you’d want that beyond convenience, but the risk is concrete: prompt injection, where text an AI system reads gets it to take an action you didn’t intend. If any commenter can trigger an agent task, someone could try to phrase a comment to steer what the agent does once it starts, not just whether it starts.
Two protections carry over regardless of that setting. Anything the automation produces, a pull request it opens or code it pushes, is attributed to whoever created the automation, not to the commenter who triggered it. That person still can’t approve their own pull request, so normal review rules hold. And you choose which tools an automation can use when you set it up, so you can limit what it’s capable of doing even if it does fire on an unexpected comment.
Who should care
This matters if you already use Copilot cloud agent and manage a repository with contributors who don’t all have write access, which includes any public repo taking outside pull requests. The default protects you without any setup on your part. It matters more if you’re the one who might flip that “write access only” restriction off, since that’s the point where the risk moves from theoretical to real.
It matters less if your repo is private with a small, trusted team, all of whom already have write access. In that case, the restriction and the setting to loosen it don’t change your exposure either way.
What builders should do next
Before you set up a comment-triggered automation, open your repository’s Copilot cloud agent settings and confirm the write-access restriction is still on, especially if the repo takes contributions from anyone outside your immediate team. If you’ve already set up an automation, check that setting now rather than assuming the default held.
Then test it deliberately. Pick a bounded task, like documentation generation on a small pull request, and set up the trigger comment. Have someone with write access post the trigger, and separately, if you have a test account without write access, have that account try the same comment. Confirm the automation only fires for the first case, that the resulting pull request is attributed to the automation’s creator and not auto-approved, and that the tools it used match what you scoped it to. That gives you a real answer for your repo’s actual permission setup instead of assuming the default protects you.
End of article