How to Stop an AI Agent From Approving Its Own Pull Request

Self-approval is a separation-of-duties failure

Code review works because the person who writes a change is not the person who approves it. When an AI coding agent holds credentials that can open, approve and merge pull requests, that assumption can fail without anyone noticing. Nothing about the failure is specific to AI. It is the same separation-of-duties problem that shared administrator accounts have always created, now arising faster and through more paths.

OWASP's DevSecOps Maturity Model names this risk directly. It warns that agents using broadly scoped personal or service credentials can be tricked into destructive or unauthorized actions, and it gives approving their own pull requests as an example. The cause is a credential and scope problem, so the fix starts with identity and access design before any review tooling is considered.

For regulated organizations the consequence is evidentiary. An auditor will ask who approved an AI-authored change, whether that party was independent of the author, and what the agent was permitted to do when it acted. If the author and approver resolve to the same identity or a shared token, those questions have no clean answer.

Self-approval paths and the layer that closes each one

Start by inventorying every credential and tool path each agent can reach. Each path below maps to a primary control, though most need more than one layer.

• Shared service account used for both authoring and review: Close with identity separation: one identity per agent, none shared with reviewers or humans.
• Over-scoped token or app permission held by the agent: Close with least-privilege scoping: remove approve and merge scopes from the authoring identity.
• Delegated token passed to a sub-agent or downstream service: Close with scope attenuation: delegated authority never exceeds the parent's, and the agent's own scope excludes approval.
• Approval or merge tool exposed through an MCP server or API: Close with runtime policy at the tool boundary: block or escalate the call before it executes.
• Auto-merge or direct push around review: Close with host-enforced branch protection and a review-holding gate in front of the version control host.
• Agent edits its own hooks, permissions or approval configuration: Close by enforcing controls on the git host and outside the agent process, where the agent cannot rewrite them.

Layers 1 and 2: identity and credentials

Give each authoring agent a dedicated identity in source code management. It should be distinct from every reviewer identity and from human accounts, so that agent actions are distinguishable from human actions in the audit log. Never let an agent borrow a developer's personal token to push or open a pull request, because that collapses author and human into one record.

Then constrain what that identity can hold. Grant the minimum scopes needed to branch, push and open a pull request, and exclude approve and merge. Make tokens short-lived. NIST IR 8587 says access and identity tokens should be valid for no more than one hour, which is a reasonable ceiling to design against. Where the platform supports it, keep credentials out of the agent process by injecting them at a proxy or gateway, so a compromised or misdirected agent cannot read and reuse them.

Apply the same rule to delegation. NIST's agent identity tenets describe scopes that attenuate as authority passes to sub-agents or downstream services, so no downstream entity claims more than its parent. An agent-initiated action under a different scope does not hand authority back up the chain. In practice, a sub-agent should never be the route by which an approval scope reaches the authoring agent.

• Create one dedicated identity per agent, separate from reviewers and humans.
• Remove approve and merge scopes from the authoring identity.
• Issue short-lived tokens, with one hour as a ceiling reference.
• Inject credentials outside the agent process where supported.
• Keep reviewer credentials out of reach of the agent and its tools.

Layer 3: repository rules and the version control boundary

Repository-native controls remain the foundation, and they are enforced on the host, outside anything the agent can modify. OWASP's mapping material makes this point: an agent that can rewrite its own permission configuration or hook scripts defeats the controls it can change, while controls on the git host sit beyond its reach.

Configure protected branches so that merging requires review from someone other than the author, with code owner review for sensitive paths and dismissal of stale approvals when new commits arrive. Where your platform offers restrictions on self-approval or on bypass permissions, enable them and limit bypass to named human roles. Treat auto-merge as a merge capability that needs the same scrutiny as any other. Exact setting names differ by platform, so verify behavior in your own environment with a test using the agent identity.

You can add an approval gate at the version control boundary as well. OWASP describes routing agent pushes through a proxy that holds them for review, with the direct route to the host closed through credential and network design. Running agents in sandboxed, disposable environments supports the same goal, since the agent has no standing path around the gate.

Layer 4: runtime policy on tool calls, and its limits

Repository settings govern what the host will accept. They do not govern what an agent attempts. Agents increasingly reach approval actions through API calls and tool servers, and OWASP's guidance notes that agent-level input and output checks have limited coverage. It advises placing validation next to the tool that creates the side effect, enforcing permissions and parameters at the tool boundary, and requiring action-specific approval for high-risk operations before they run.

For this problem, that means classifying approve and merge as high-impact actions. Declare that classification on the action itself rather than leaving the agent to infer it, as OWASP Cornucopia advises for agent actions that change permissions or state. Then write policy that allows a short list of autonomous actions, blocks approve and merge when the caller is the authoring agent identity, and escalates any other approve or merge request to a human. NIST's tenets support this pattern, describing risk thresholds that trigger human review and routing to the correct authority.

Trussed enforces policy in the execution path across agents, tools, MCP servers and coding assistants. It can allow, redact, block or escalate individual tool calls for human approval, so an approve or merge call from the authoring agent is stopped at runtime, not reviewed after the fact. Code provenance, covering the origin, licence and security context of code, adds context to the decision.

The boundaries matter. Runtime policy acts on calls that pass through the path it sits in. It does not replace host-enforced branch protection, and it cannot constrain a credential that reaches the repository by a route outside the path. Treat it as a complement to the repository and identity layers, not a substitute.