A cloud coding agent should be able to read the repository it is working on, push to a single non-protected branch, and open a pull request. It should not merge, approve, delete branches, push tags, or reach other repositories. A human should review and merge, with branch protection enforced by the host.
A documented example of tight limits
GitHub's risk page for its cloud agent lists a set of controls worth copying as a model:
- Only users with write access can trigger the agent.
- The agent can push to a single branch, either a new branch with a fixed prefix or the existing pull request branch, and branch protections and required checks still apply.
- It cannot run git push or other git commands directly.
- It cannot mark pull requests ready for review, approve them, or merge them.
- The user who requested the pull request cannot approve it.
- Workflows do not run until a user with write access approves them, by default.
Another vendor's proxy design rejects branch deletions and pushes of anything other than a branch, and limits API requests to repositories attached to the session. It also states plainly that the proxy does not limit which branches a push can update, and recommends branch protection or rulesets for that. That detail is worth remembering: a tool's built-in limits and your repository rules are separate layers.
Permission table
| Action | Agent | Why |
|---|---|---|
| Read the target repository | Yes | Needed for the task |
| Read other repositories | No | Limits blast radius |
| Push to a task branch | Yes | Needed to deliver work |
| Push to main or release branches | No | Protect with rules |
| Create or move tags | No | Tags can trigger releases |
| Delete branches | No | Not needed |
| Open a pull request | Yes | Starts review |
| Approve or merge | No | Keep a human in the loop |
| Change workflow files | Review closely | Workflows run with secrets and tokens |
Steps to set it up
- Use a dedicated identity or app for the agent, not a developer's personal token.
- Grant repository access to only the repositories in scope.
- Turn on branch protection for main and release branches, requiring review and status checks.
- Require that the person who started the task is not the sole approver.
- Hold workflow runs from agent pull requests until a reviewer approves.
- Add code owner review for paths such as workflow files, build scripts, and dependency manifests.
Why workflow files deserve extra care
Workflows run with the repository's tokens. GitHub documents that the workflow token is limited to the repository containing the workflow, is created per job, and expires when the job finishes, so keep its permissions minimal. An agent that edits a workflow can change what runs with those tokens, so route those changes through strict review.
Worked example: setting up a repository for agent work
An illustrative setup for a service repository with a main branch and a release branch.
- Create an agent identity. A dedicated app or bot account with access to this repository only.
- Protect main and release. Require a pull request, at least one approving review from someone other than the requester, and passing status checks. Disallow force pushes and deletions.
- Add code owners. Require owner review on workflow files, build scripts, the lockfile, and the dependency manifest.
- Hold workflows. Require approval before workflows run on pull requests from the agent identity.
- Restrict secrets. Move deploy credentials into environments that require a named reviewer.
- Test the setup. Ask the agent to push directly to main, to delete a branch, to create a tag, and to approve its own pull request. All four should fail. Write down the results.
That six step test is the most valuable part. Platforms document their own limits, but only your repository settings prove what your repository will allow.
Token scopes in practice
| Need | Scope to grant | Scope to avoid |
|---|---|---|
| Read code | Read access to one repository | Organization wide read |
| Push work | Write to task branches | Admin, or write to protected branches |
| Open pull requests | Pull request write on one repository | Workflow write unless required |
| Comment on issues | Issue write on one repository | Org wide issue write |
| Read CI results | Checks read | Secrets read |
Fine grained scopes differ across hosts, so map these rows to your host's permission names.
Reviewing the pull request
A pull request from an agent deserves a particular reading order.
- Changed files list. Look for workflow files, build and release scripts, lockfiles, and manifests first.
- Dependency changes. Any new package needs a name check and a reason.
- Test changes. Did the agent weaken a test to make it pass?
- Generated content. Look for unusual URLs, encoded strings, or network calls.
- Session record. Check which commands ran and which hosts were contacted.
Separation of duties
The documented design where the requester cannot approve their own agent pull request prevents a single person from asking for and approving a change. Mirror that rule in your repository: require an approving review from a person other than the requester, and make the agent identity ineligible to approve anything.
Audit evidence
Keep a record of repository settings, the six step test results, and the agent identity's access list. Review them whenever the agent's scope changes. That record answers the question auditors and customers ask most: what can this thing do to our code?
Where Safeguard fits
Safeguard gives agents their own identity and lets you set policies and gates on what they do and what they propose. Its pull request gate can block risky dependency changes.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is held when a check fails, which is the kind of gate that sits between an agent's branch and your main branch.
Quick check
Should the agent use a developer's personal token?
No. A dedicated identity makes actions attributable and lets you limit repositories.
Is branch protection still needed if the agent cannot merge?
Yes. It is an independent control on the repository host and covers every actor.
Should the agent be able to comment on pull requests and issues?
Comments are a write path to an audience, so grant them only if the workflow needs them, and review what it posts. A comment can carry data out, as well as be used to trigger automation.
Sources
- Risks and mitigations for Copilot cloud agent (GitHub Docs)
- Configure cloud environments (Anthropic documentation)
- GITHUB_TOKEN (GitHub Docs)
Last reviewed: 19 October 2026.
