Minimum governance set
Start with identity, permission tiers, allowed tools, approval rules, audit logs, sandbox policy, cost controls, and incident response. If any of these are missing, keep the rollout small.
The first rollout should use low-risk repos, read-heavy tasks, and clear human review. Add write access only when the team can explain what happened after each agent run.
Permission levels
Use tiers instead of one broad agent permission. Tier 0 is read-only explanation and search. Tier 1 allows local file edits on a branch. Tier 2 allows command execution for approved test, lint, and build commands. Tier 3 allows network or MCP access. Tier 4 covers deploy, migration, billing, production, or destructive actions and should require explicit human approval.
A team can start with only Tier 0 and Tier 1. Add higher tiers when audit logs, owners, rollback, and approval prompts are already working.
Prohibited actions and approval conditions
Ban agents from copying secrets into prompts, changing production configuration, deleting data, editing migrations, changing billing, widening permissions, or publishing external messages without approval. These are not productivity tasks; they are control-plane actions.
Require approval when a task touches credentials, customer data, deployment paths, database schema, external network writes, large generated changes, or repeated failed retries. The approval prompt should name the actor, repository, action, target, rollback limit, and expected evidence.
Audit log fields
Keep logs useful and secret-redacted. Record actor, team, repository, branch, agent surface, model or tool version when available, prompt summary, tools called, files changed, commands run, approval state, final outcome, and rollback link.
Do not store raw secrets, customer payloads, access tokens, or private content unrelated to the review. Good logs let a reviewer reconstruct a consequential action without collecting sensitive data by accident.
Good policy feels practical
A good policy tells developers what they can do today. It should not read like a legal memo. Use simple rules: which tasks are allowed, which tasks need approval, which data is off-limits, and which command or review proves the work is safe.
Recommended play
- Run a two-week pilot with one team, one repository, and a narrow set of agent permissions.
- Write approval rules before enabling write, deploy, external network, or production-data access.
- Review logs weekly during the pilot and update the policy from real incidents, not imagined edge cases.
Coding agent governance checklist
Use this as a first-pass policy map before enabling agents across a software team.
| Area | Minimum rule | Why it matters | Launch gate |
|---|---|---|---|
| Identity | Know which user, team, and repo started the agent | Makes accountability possible | Agent activity is tied to a user or service account |
| Permissions | Split read, write, command, network, and deploy access | Limits damage when context is wrong | High-risk actions need approval |
| Forbidden actions | List actions agents may not perform without explicit approval | Prevents control-plane drift | Secrets, production writes, billing, deploy, deletion, and migrations are gated |
| Logs | Record prompt summary, tools, changed files, commands, and approvals | Makes review and incident response possible | Logs avoid secrets but keep useful traceability |
| Review | Require a human diff review before merge | Agents can pass tests and still change the wrong thing | No auto-merge for high-risk repos |
| Emergency stop | Disable agent access, revoke credentials, close branches, and preserve logs | Limits blast radius after a bad run | Owner and rollback path are known before launch |
Execution steps
Write the pilot boundary
Choose one team, one repository type, allowed tasks, forbidden tasks, and a review owner.
Create permission tiers
Separate read-only, limited write, command execution, network access, and deployment paths.
Define audit fields
Record actor, repo, session, tools called, files changed, commands run, approval state, and final outcome.
Review after two weeks
Keep what developers actually used, remove confusing rules, and close gaps found in logs or reviews.
Publish the Markdown policy
Keep a copyable checklist in the engineering handbook or repo instructions so developers can apply the same approval, logging, and rollback rules during real work.
Common pitfalls
Starting with a company-wide rollout
Start with a small pilot so the policy learns from real work before it scales.
Treating all tools as equal
A read-only docs lookup and a deploy command need different approval paths.
Logging either too much or too little
Keep traceability, but do not store secrets or unnecessary private payloads.
Implementation checklist
- Name the pilot team and repository scope.
- Separate read, write, command, network, and deploy permissions.
- Require approval for destructive or production-facing actions.
- Ban agents from copying secrets, changing billing, deleting data, or deploying without approval.
- Record actor, repo, branch, tool surface, files changed, commands run, approval state, and outcome.
- Keep audit logs without storing secrets.
- Require human review before merging agent changes.
- Document rollback and emergency stop steps.
- Write an incident response path before broad rollout.
Questions this guide answers
What should you do first?
Run a two-week pilot with one team, one repository, and a narrow set of agent permissions.
Who is this guide for?
Engineering managers, platform teams, security reviewers, and developer-experience teams rolling out coding agents.
What evidence supports this guide?
This guide uses listed source material from GitHub, Cursor, OWASP. Source links and scope notes are available on this page.