Your organization defines three agent autonomy tiers: Tier 1 (read-only exploration), Tier 2 (can propose changes via PR), Tier 3 (can merge approved PRs). Which GitHub Actions workflow permissions mapping is correct for this tiered model?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Permission tiers are blast radius controls — Tier 1 agents can look but not touch, Tier 2 can propose but not decide, Tier 3 can execute but only through a protected gate. Each tier's permissions are exactly what that tier's role requires and nothing more.
Full explanation below image
Full Explanation
The correct permission mapping follows least-privilege at each tier:
Tier 1 (read-only exploration): contents:read only. The agent can read repository files, check history, and generate insights. It cannot write any files or create any resources. This is the lowest risk tier — even if the agent malfunctions, it cannot cause any changes.
Tier 2 (propose changes via PR): contents:write (to push to a feature branch) and pull-requests:write (to open a PR). The agent can create code changes but cannot approve or merge them. Human reviewers must approve the PR.
Tier 3 (merge approved PRs): Same as Tier 2 (contents:write, pull-requests:write) but with environment protection rules configured on the target branch. The agent's merge action requires an environment approval gate (e.g., a required reviewer approval of the environment deployment). This prevents the agent from auto-merging without human sign-off, even though it has write access.
Option A incorrectly assigns contents:write to Tier 1, which would allow file modifications — violating read-only.
Option C (no permissions / admin / admin) is incorrectly extreme in both directions: Tier 1 needs at minimum contents:read to function, and admin for Tiers 2-3 grants far more access than needed.
Option D (same permissions with rate limiting) does not enforce tier boundaries — rate limits control frequency, not action type.