How to Set Permissions for AI Coding Agents
A three-tier permission model for AI coding agents on a team: read-only reviewer, sandbox builder, and deploy-authorized, with the real mechanisms that enforce each tier.
Permissions for an AI coding agent on a team come down to one question: what can this agent touch without a human in the loop? The answer should never be all of it. The practical fix is a tiered system: give every agent a starting tier based on what it needs to do today, not what it might need eventually, and promote it only when the work actually demands more access. Most teams need just three tiers: read-only, sandboxed build access, and deploy access gated by human approval. Everything below covers how to define those tiers and enforce them with real mechanisms, not policy documents nobody reads.
Why "be careful" is not a permission model
Telling an agent to "only make safe changes" is not a control. It is a hope. Agents follow instructions literally and act on whatever credentials are handed to them. If an agent's token can push to main, deploy to production, or read every secret in your environment, it will eventually do something with that access, whether through a bad prompt, a misread instruction, or a tool call that goes further than intended.
A permission tier is different from an instruction. It is a hard boundary enforced by the systems the agent touches: git hosting, cloud provider, CI pipeline, secrets manager. The agent does not need to be told not to deploy if its credentials cannot deploy in the first place.
A three-tier model for team agent access
Most teams do not need a complex role matrix. Three tiers cover the vast majority of situations, from a new hire's first day to a senior engineer running an agent against production tooling.
Tier | What it can do | What it cannot do | Typical starting user |
|---|---|---|---|
1. Read-only reviewer | Read code, read issues, read logs, comment on PRs, propose diffs | Write to any branch, run code against real data, touch secrets | New hire, unfamiliar codebase, one-off audit task |
2. Sandbox builder | Write to feature branches, run tests, install dependencies, open pull requests | Merge to main, deploy, access production credentials or customer data | Agent working a normal feature or bugfix ticket |
3. Deploy-authorized | Merge after review, trigger deploys, use environment-scoped production credentials | Bypass required human approval on the deploy step | Trusted workflow with a track record and a human still signing off |
The tiers are cumulative in scope but not in trust. A tier 3 agent should still require a human approval gate on the step that actually ships code, because deploy access and unattended deploy authority are two different things. Giving an agent the ability to deploy is not the same as letting it deploy without a person confirming it.
Worked example: a new hire's agent
A new engineer joins and wants to run a coding agent against the team's main repository on day one. Here is how the tiers play out in practice.
Day 1, tier 1: the agent gets a read-only token scoped to the repositories the engineer is actually working in. It can summarize code, draft PRs as suggestions, and answer questions about the codebase. It cannot push anywhere.
Week 1-2, tier 2: once the engineer has reviewed a handful of the agent's suggestions and trusts its output on routine tasks, it moves to a sandbox token. This token can create branches, open PRs, and run the test suite in a non-production environment. Merges still require a human, because the tier controls agent credentials, not code review policy.
Month 2+, tier 3, situational: only for a specific, narrow workflow, like automated dependency bumps or a well-tested deploy script, does the agent get environment-scoped production credentials, and only alongside a required approval gate in CI. Most agents never need this tier at all, and that is fine.
Notice what does not change: the human decision points. Tiering controls what an agent is technically capable of, not whether a person reviews its work. Those are separate layers and both matter.
When to promote an agent to the next tier
Promotion should be driven by observed behavior on a specific task type, not by tenure or enthusiasm. Reasonable triggers:
The task genuinely requires the next tier's access and no lower-tier workaround exists.
A person has reviewed enough of the agent's output on the current tier to trust the pattern of mistakes it makes, not just its best outputs.
The blast radius of a mistake at the new tier is understood and acceptable, meaning someone has asked "what happens if this goes wrong" and has an answer.
Promotion should also be reversible. If an agent's mistakes on a lower tier keep recurring, that is a signal to fix the underlying workflow, not to hand it broader access hoping the problem disappears.
Mechanisms that actually enforce a tier
A tier is only real if something outside the agent enforces it. These are the mechanisms teams commonly use, none of which depend on the agent behaving well:
Separate API keys or tokens per tier. Do not reuse a developer's personal token for an agent. Issue a distinct credential scoped to exactly what that tier needs, so revoking or auditing one tier never touches another.
Branch protection rules. Require pull request review and passing checks before merging to main or release branches. A tier 2 agent with write access still cannot merge unreviewed code if the branch itself enforces review.
Environment-scoped credentials. Give staging and production separate secrets, separate service accounts, and separate cloud roles. An agent working in staging should hold credentials that simply do not exist in the production environment.
CI approval gates. Add a manual approval step in the pipeline before any job that deploys or touches production data runs, even for a tier 3 agent. The gate is the actual control, not the agent's tier label.
None of these require exotic tooling. They are the same access controls teams already use for human contractors and junior engineers, applied consistently to agent credentials instead of assumed unnecessary because "it's just an AI."
Common mistakes
Giving every agent the same broad token because provisioning separate credentials feels like overhead. It is the single biggest source of unnecessary blast radius on a team.
Treating tier promotion as permanent and one-directional. Access should shrink back down when a project ends or a workflow is retired.
Confusing code review with credential scope. A human reviewing a PR does not help if the agent's token could have deployed before anyone looked at the diff.
Skipping the sandbox tier entirely and jumping agents straight from read-only to deploy-capable because tier 2 feels like unnecessary process. It is usually where an agent spends most of its working life.
FAQ
Should every AI coding agent on a team have its own credentials?
Yes. Shared credentials make it impossible to know which agent, task, or person triggered a given action, and they mean revoking access for one use case revokes it for all of them.
Does a deploy-authorized agent still need a human approval step?
Yes. Having the technical ability to deploy and being allowed to deploy unattended are different things. Keep a required approval gate on the deploy step regardless of tier.
How do spending limits relate to permission tiers?
They are separate controls that work well together. Spending limits cap how much an agent can cost you; permission tiers cap what it can touch. See how to set spending limits for AI agents for the cost side of the equation.
Does repository structure affect how permissions get scoped?
It can. A well-organized repository makes it far easier to scope an agent's write access to a specific package or service instead of the whole codebase. See how to structure a monorepo for AI coding agents if you are setting up a new repo layout.
What is the biggest risk of getting agent permissions wrong?
Credential exposure is a common downstream effect of over-broad access, since a token that can reach more systems can leak more if something goes wrong. Can an AI coding agent leak your API keys? covers how that risk shows up in practice.
For a broader look at building an agent workflow around your team, see the AI coding tools overview.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
