AI code review: permissions on GitHub and Azure DevOps

Code review is a natural place for AI agents in the development process. An agent can read a pull request (PR), compare it with the rest of the repository, check the CI results and leave comments within minutes, before a human reviewer has opened the diff. Tools such as Claude Code, Cursor or VS Code can do this through the Model Context Protocol (MCP) when they are connected to GitHub or Azure DevOps.

The difficult part is not the review itself, but the permissions behind it. The same connection that lets an agent comment on a pull request can, depending on the token, also approve it, merge it, push to a branch or trigger a release. This post describes which permissions a review agent actually needs, where the real risks are, and how the access can be scoped. It is part of our series on AI agents in the software development lifecycle.

What a review agent needs to do

A review agent has a clearly defined task. It reads the changed files, the commits of the PR, related files in the repository and, where useful, the results of the CI workflow. It then writes its findings as review comments or as a general comment on the PR. Some teams also let the agent request additional reviewers when a change touches a sensitive area.

For this, the agent needs read access to the repository, the pull request and the workflow runs, plus the ability to comment. It does not need to write files, create branches, merge pull requests or create releases. Those are different tasks, and if a team wants an agent for them, it is a different agent with a different risk profile.

Where the real risks are

Three operations deserve particular attention, because they change the state of the code rather than only describing it.

Approving a pull request. A review with the event APPROVE counts towards the required approvals of a protected branch, if the account behind the token is an eligible reviewer. An agent that approves its own findings, or approves a PR written by another agent, can therefore bypass the four-eyes principle that the branch protection was meant to enforce.

Merging a pull request. A merge puts the change into the main line and, in many setups, starts a deployment. It is the step where a wrong decision has the largest effect.

Writing files and triggering workflows. Writing a file creates a commit. Triggering or re-running a workflow can start a build or a deployment with the repository's secrets. Both are legitimate tasks for automation, but not for a review agent.

There is a fourth, less visible risk: prompt injection. The agent reads text written by other people, including PR descriptions, code comments and issue texts. If that text contains instructions aimed at the model, a poorly constrained agent may try to follow them. The permissions of the agent define how much damage such an instruction can cause in the worst case.

Why a personal access token is the wrong unit

A personal access token on GitHub or Azure DevOps carries the permissions of the person who created it. Fine-grained GitHub tokens improve this by limiting repositories and permission categories, but the categories are coarse. Write access to pull requests allows a comment as well as an approval, and the token cannot express "comment, but never approve". The audit trail also shows the person's account, not the agent.

The unit that fits better is the operation: comment, create review, merge, write file. Each can be allowed or denied separately, for a specific repository and branch.

How Vordix scopes a review agent

Vordix is a self-hosted gateway between agents and tools. The agent connects to a Vordix workspace, and every call is checked before it reaches GitHub or Azure DevOps.

Operations are enabled individually. For GitHub, Vordix exposes reading files, branches, commits, issues, pull requests, PR files and commits, reviews, workflows, runs and releases. On the write side, there are separate operations for commenting, creating a review, approving a PR, requesting reviewers, creating or updating a PR, merging a PR, writing or deleting a file, creating or deleting a branch, triggering, re-running or cancelling a workflow, and creating a release. For Azure DevOps, the corresponding operations cover repositories, files, branches, commits, pull requests with comments and pipelines. Every operation starts disabled, and a review agent's workspace receives only the read operations and commenting.

Repositories and branches are allowlisted. GitHub access is scoped by repository, with an allowlist for branches below it (and for authors when searching). Azure DevOps is scoped by project, with an allowlist of repositories per project. A review agent for the payment service therefore sees that repository and nothing else.

Approve and merge are separate decisions. Because create_review, approve_pr and merge_pr are separate operations, a team can give an agent review rights without approval rights: create_review only comments or requests changes, and an approval is possible only through approve_pr, which stays disabled unless someone switches it on. If a team does want an agent to merge, for example for dependency updates, it can attach an approval policy to merge_pr: the call is held until a human confirms it. Approval policies are configured per operation by an admin; nothing requires approval by default.

One workspace per agent. Different agents get different workspaces. The review agent and a release agent do not share permissions, and each has its own API key, rate limit and audit trail. A workspace can also be switched off immediately with its kill switch.

Prompt injection can be flagged or blocked. Vordix can scan the parameters an agent sends and either flag suspicious content or deny the call, with stricter handling for write operations. This does not make injection impossible, but it adds a check at the point where the agent tries to act.

Every decision is recorded. Allowed, denied and held calls are written to an append-only, hash-chained audit log. If an agent tries to merge without permission, the attempt and the reason for the denial are visible afterwards. The post on audit trails for AI agents explains what such a log should contain.

Limitations

Some controls are not yet available, and they matter for review workflows. Labels, assignees and the list of requested reviewers are not governed as allowlists today: if the agent may request reviewers, it may request any reviewer.

Vordix also does not replace branch protection. Required reviews, status checks and code owners should stay configured in GitHub or Azure DevOps. The gateway decides what the agent may attempt; branch protection decides what the repository accepts. Both layers together are more robust than either alone.

Finally, a well-scoped agent is not automatically a good reviewer. It can miss problems or comment on things that do not matter. The permissions limit the damage, but the value of the review still depends on the model, the prompt and the team's willingness to read the comments critically.

Conclusion

An AI review agent needs read access and the ability to comment. Approval, merge, file writes and workflow triggers are separate risks and should be separate decisions. Scoping by operation, repository and branch, with a workspace per agent and a complete audit trail, makes it possible to use agents in code review without weakening the controls that protect the main branch. For the planning side of the same process, see AI agents in Jira sprint planning; for the underlying architecture, see what an MCP gateway is.

The Vordix documentation lists the GitHub and Azure DevOps operations in detail, and a demo shows a review workspace on a real repository.