An agent should work on one repository and open pull requests, but never push to main. Which approach fits?
Why C is the answer
Scope it to the repository and a working branch, with branch protection on main
Scoped permissions plus platform controls enforce the boundary, however the agent behaves.
In detail
- Scoping limits access to what the task needs.
- Branch protection enforces the rule on main.
- Combine narrow access with a rule the platform enforces.
Use case
An illustrative scenario, not a real incident.
An agent works on one repository in a feature branch. Branch protection stops any push to main, so a mistake cannot reach production.
See it in different ways
flowchart TD A["Cloud agent"] --> B["Pushes to a single branch"] A --> C["Cannot approve or merge"] A --> D["Workflows wait for approval"] A --> E["Internet access limited by a firewall"]
mindmap
root((Agent limits))
Identity
Write access to trigger
Repository
One branch
Branch protection
Tools
MCP allow list
Tool permissions
Network
Firewall allowlistsequenceDiagram participant P0 as Agent participant P1 as Working branch participant P2 as main P0->>P1: Push changes P1->>P2: Pull request, needs review P2-->>P0: Direct push refused
Key point: Scope access, and enforce it with branch protection.
Why the other options are wrong
- A. Give it an owner token and rely on the prompt not to push to main
- A prompt cannot stop an owner token from pushing.
- B. Let it push anywhere and review its work in the audit log afterward
- An audit log only shows the damage afterward.
- D. Run it locally only, on a developer's own machine and credentials
- A developer's own credentials usually reach more than needed.