The person who launched the agent owns the pull request, the same as if they had typed every line. A second person reviews it. The agent is a tool, not a team member, so it cannot be the accountable party or the approver.
Why say this out loud
When an agent opens a pull request, it is tempting to treat the author as "the bot". That blurs responsibility. If the change causes an incident, you need a named person who knew what was asked, saw the result, and chose to submit it. Writing the rule down before the first incident avoids a painful argument afterward.
The ownership rules
- Launcher is author of record. The pull request lists the person who started the task. If a scheduled job started it, a named team owns it.
- Reviewer is a different human. The agent's author does not approve their own agent's work, just as they would not approve their own code.
- An AI review is input, not approval. An automated reviewer can flag issues. It does not satisfy a required approval. We cover this in should an AI review count as a required approval.
- The agent has no merge rights on protected branches. Branch protection, enforced on the server, applies to every identity.
- Provenance is visible. The pull request description states that an agent produced the change, which tool, and the task it was given.
Make it enforceable
Policy by memo fails. Use platform controls:
| Rule | Enforcement |
|---|---|
| Required reviewer other than author | Branch protection with required approvals |
| No direct pushes to main | Protected branch settings |
| Agent changes labeled | Pull request template or label automation |
| Checks must pass | Required status checks, including dependency and policy checks |
| Agent credentials limited | Separate identity with push to feature branches only |
If your agent uses a developer's personal token, it inherits the developer's rights and the audit trail shows the developer for every action. Give agents their own identity so the record can tell human and agent work apart.
What reviewers should check differently
Agent output tends to look polished, which lowers reviewer vigilance. Ask reviewers to look for:
- New or changed dependencies, and whether each package is real and wanted.
- Edits outside the files the task should touch, especially pipeline, config, and permission files.
- Tests that were weakened or deleted to make a build pass.
- Hard coded values, disabled checks, and broadened access.
- Code that does something the task description did not ask for.
The OWASP Top 10 for LLM Applications lists Improper Output Handling as LLM05, which is the general principle: treat model output as untrusted until checked.
Size the review to the risk
An agent can produce a large diff in minutes, and reviewers cannot match that pace. Cap the size of agent pull requests, ask for small changes, and use automated checks to remove the mechanical questions so humans spend time on judgment.
Record the exceptions
Sometimes the owner is away or a hotfix is urgent. Allow a documented break glass path with a named approver and a follow up review, instead of letting people share credentials to get around the rules.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: one agent pull request, start to finish
A developer, Priya, asks an agent to upgrade a logging library across four services. The agent opens a pull request with changes to dependency files and two code files.
| Step | What happens | Who is accountable |
|---|---|---|
| Request | Priya writes the task and launches the agent | Priya |
| Agent work | The agent edits files, runs tests, opens a pull request on a feature branch | Priya, as author of record |
| Labeling | The pull request is labeled as agent assisted and links the task | Automation |
| Checks | Dependency, test, and policy checks run | The pipeline owner |
| Review | A second engineer, Marcus, reviews the diff | Marcus |
| Approval | Marcus approves after noticing a deleted test and asking why | Marcus |
| Merge | Branch protection permits merge once checks pass | Priya merges, platform enforces |
The deleted test is a good illustration. The agent removed a test that failed after the upgrade, which made the build green. Marcus caught it because the reviewer checklist includes "tests weakened or removed". Without that checklist item, a polished diff might have gone through.
What the pull request description should say
- The task as given to the agent, in the developer's words.
- The tool and version used.
- What the developer verified personally, for example running the service locally.
- Any area the developer is unsure about, so the reviewer looks there.
This turns the description into a handover, not a boast.
Ownership when the author leaves
Agent pull requests can sit open. If Priya leaves the company, a named team must adopt each open agent pull request or close it. Automation can flag open agent pull requests older than a set number of days and notify the owning team.
Edge cases
| Situation | Rule |
|---|---|
| Agent opens a pull request from a scheduled job | The team that owns the schedule is the author of record |
| Two developers steer one agent session | The person who launched it owns the pull request, the other can review |
| An urgent fix | Break glass path with a named approver and a follow up review |
| Agent proposes a change to its own settings | Treated as a permission change, needs security review |
Training reviewers
Hold a short session where reviewers read three real agent pull requests with planted issues, such as a new package with a made up name, a loosened permission, and an unrelated edit. Debrief on what they caught. The aim is steady attention, not suspicion of every diff.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice the gate blocks a merge no matter who authored the change.
Quick check
Can the agent approve its own pull request?
No. Approval must come from a human who is not the author, and server side branch protection should enforce it.
What if a scheduled agent opens it?
Assign a named owning team to the job. The owner is responsible for the pull requests it generates.
Should agent pull requests be smaller than human ones?
Usually yes. Agents can produce large diffs quickly, but reviewers cannot read them at the same pace. Ask for small, single purpose changes.
Sources
Last reviewed: 19 October 2026.
