TalkWhen the assistant opens a pull request
The interesting change in developer tooling this year is not that the suggestions got better. It is that the software stopped suggesting.
An assistant that proposes a line of code and an agent that opens a pull request are different products with the same price list, and only the second one raises a question about who is accountable for the result.
We read GitHub's and Anthropic's own documentation on October 20, 2026 to find out how each vendor answers it. Both answer the same way, in plain sentences, and the mechanisms behind the sentences are not equally strong.
The vendors describe the change without softening it
GitHub's risks page opens with a sentence that would have been a headline two years ago.
"Copilot cloud agent is an autonomous agent that has access to your code and can push changes to your repository," it reads. "This entails certain risks."
The documentation for Autopilot mode is equally direct about where the responsibility lands: "You remain responsible for the work the agent performs. Review the changes and test results before you commit, push, or merge them."
Anthropic's Claude Code security page has a section titled User responsibility, and it is one sentence long: "You're responsible for reviewing proposed code and commands for safety before approval."
That is the whole settlement. The tool acts, you answer for it, and nothing in either product changes that allocation.
GitHub's design makes the agent a deliberately weak actor
The useful part of GitHub's page is the list of things the agent cannot do, because each entry implies the risk it was written against.
"Only users with write access to the repository can trigger Copilot cloud agent to work. Comments from users without write access are never presented to the agent."
"Copilot cloud agent only has the ability to push to a single branch." In most cases that is a new branch named with a copilot prefix, and the agent "is also subject to any branch protections and required checks for the working repository".
"Copilot cloud agent can only perform simple push operations. It cannot directly run git push or other Git commands."
And the sentence that decides the question in the title: "Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human.
Copilot cloud agent cannot mark its pull requests as Ready for review and cannot approve or merge a pull request."
There is a second gate around continuous integration. "By default, workflows are not triggered until Copilot cloud agent's code is reviewed and a user with write access to the repository clicks the Approve and run workflows button."
Read as a set, these are the controls of an organisation that expects its agent to be used as an untrusted contributor. That is the right posture, and it is more conservative than the marketing around agents suggests.
Attribution has two answers in the same product
Who the commit belongs to turns out to depend on how the work was started.
For ordinary sessions, GitHub states that the agent's "commits are authored by Copilot, with the developer who assigned the issue or requested the change to the pull request marked as the co-author". The commits are signed and appear as Verified.
When the agent opens a pull request "under its own app identity", the page says "one more approval is required before it can be merged, as long as the repository already requires at least one approval".
For scheduled work the identity shifts to a person: "Pull requests opened and code pushed by an automation are attributed to the user who created the automation. As when that user creates a pull request themselves, they can't approve it."
That is a thoughtful rule with an uncomfortable implication. Whoever set up the automation owns every change it makes afterwards, including the ones produced weeks later from an issue they never read.
One page admits that the approval panel is not a boundary
The most quotable sentence in any of this documentation is a note on GitHub's page about confidence and approvals for automated issue triage.
"Approvals are a workflow convenience, not a security control. They don't enforce a server-side boundary, so an agent with permission to change issues can apply changes directly instead of proposing them, including through the REST and GraphQL APIs."
The advice that follows is the correct advice: "Use repository and agent permissions, not approvals, to control what an automation is allowed to do."
The same page sets out four automation levels: Full control, where "Every change is held for review"; Cautious, the default, where "Only high-confidence changes are applied automatically"; Balanced; and Full automation, where "Every change is applied automatically".
And it scopes itself narrowly. The confidence system "applies only to the changes an automation makes to issues" and "does not apply to other actions an automation can take, such as opening pull requests or pushing code".
So the part of the product that rates its own confidence before acting is the part that edits labels. The part that writes code does not offer a confidence score.
On a laptop the boundary is a prompt, and a prompt can be waived
Local agents have the opposite problem. They run with your credentials, which are stronger than any app identity.
Claude Code's security page describes two starting modes. In Auto mode, "A separate classifier model reviews actions instead of you and blocks the ones it judges unsafe." In Manual mode the agent "starts with read-only permissions" and asks before editing or running commands.
The page is candid about how thin the working-directory guard is: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can."
Accept Edits mode auto-approves file edits plus "a fixed set of filesystem Bash commands like mkdir, touch, rm, mv, cp, and sed" inside the working directory. Three of those six delete or relocate files.
There is also a note that matters for anyone wiring an agent into a script: a session started with the non-interactive flag "shows neither prompt", meaning neither the workspace trust dialog nor the project server approval.
For hosted sessions the page describes a GitHub proxy that "rejects branch deletions and pushes of anything other than a branch", and then concedes the limit of that approach: "A rule that access can bypass doesn't block a session's push."
An agent inherits the authority of the credential you hand it. Every page above is a different way of saying that.
What accountability actually requires
If the answer to who is responsible is you, the practical question is what that costs in process:
- Give the agent its own identity. GitHub requires an extra approval when a pull request arrives under the app identity, which only helps if the repository already requires one.
- Set permissions, not preferences. The approvals note says the panel is a convenience; the enforceable controls are repository and agent permissions.
- Decide who owns an automation. Scheduled work is attributed to whoever created the automation, and that person cannot approve it.
- Keep workflow approval on. The default holds continuous integration until a human with write access clicks through, which is the gate that stops one agent from triggering another.
- Treat a local agent as a user account. Auto-approved edits include rm and mv, and an approved shell command reaches anything your login can reach.
Note that none of these are model questions. They are access-control questions that existed before any of this software did.
Why the old sentence still applies
Nothing here argues against delegation. An agent that opens a draft pull request against a protected branch, with signed commits and a session log linked from the commit message, is a better-behaved contributor than many humans.
What it is not is a party to the review. GitHub's own stopping advice makes the asymmetry concrete: "Stopping the current work does not undo changes the agent has already made."
The agent can act and cannot answer. That is why both vendors put the responsibility sentence in their own documentation rather than leaving it to a blog post.
What follows in practice
Read the permissions page before the feature page. The capability list tells you what the tool will try; the permissions list tells you what your repository will accept.
Per-tool detail, with the dates we read it, sits in our subject pages for GitHub Copilot, Claude, Cursor and Kiro, and the field is ranked in our guide to the best AI coding assistants for small teams.
The two editors are set against each other in Cursor versus GitHub Copilot. The licensing question behind an agent that works unattended is argued in what a seat means when the worker is software, and the process question in the tool is not the workflow.
Who can see the code the agent reads is a separate matter, covered in who reads what you type.
An agent that opens a pull request has not transferred the decision. It has only moved the work to the review queue, where a person still has to be willing to sign.
Sources, read October 20, 2026: docs.github.com risks and mitigations for Copilot cloud agent, rationale and approvals for issues, and Autopilot mode; code.claude.com Claude Code security documentation.
Sources
- Risks and mitigations for GitHub Copilot cloud agent (single branch, no direct git push, human review before merge, app identity approval, workflow approval) - checked October 20, 2026
- About rationale, confidence, and approvals for issues (approvals are a workflow convenience, not a security control; four automation levels) - checked October 20, 2026
- Allowing GitHub Copilot to work autonomously (Autopilot mode: you remain responsible; stopping does not undo) - checked October 20, 2026
- Claude Code security (permission modes, user responsibility, working directory boundary, Accept Edits command list, GitHub proxy push rules) - checked October 20, 2026