AI coding agents are useful because they can inspect repositories, edit files, run tests, open pull requests, and sometimes deploy. Those same abilities create a security boundary that is different from a chat assistant. The agent may see secrets in logs, follow malicious instructions inside a repository, or change production behavior faster than a human reviewer notices.
The safest pattern is to treat a coding agent like a delegated engineer with a narrow task, a temporary workspace, limited credentials, auditable tool calls, and a review path before production changes. This checklist focuses on the practical controls teams need before letting coding agents work on real repositories.
Use it with /guides/agent-permissions/, /guides/agent-monitoring/, /guides/agent-evaluation-framework/, and /guides/ai-cost-governance-checklist/ when you design a secure agent engineering workflow.
Key takeaways
- Give coding agents branch-scoped authority, not permanent production authority.
- Treat repository files, issue comments, web pages, and tool output as untrusted input unless policy says otherwise.
- Keep merge, deploy, billing, credential, and destructive operations behind explicit approval.
Start with a narrow repository task
A coding agent should begin with a specific task, expected files, allowed commands, and a definition of done. Broad prompts like 'fix the app' invite unnecessary exploration and tool use. Narrow prompts reduce the chance that the agent reads unrelated secrets, rewrites unrelated code, or masks the original issue with a large refactor.
Before delegation, classify the task by risk. Documentation edits and isolated UI fixes are lower risk. Authentication, billing, deployment scripts, data migrations, and permission code need stricter review and often a human-designed plan before the agent edits anything.
- Name the repository, branch, goal, allowed directories, and forbidden areas.
- Require a short implementation plan for high-risk auth, billing, security, or migration work.
- Do not allow unrelated refactors unless they are necessary to complete the task.
- Use separate worktrees or containers for untrusted experiments.
Use branch isolation and mandatory review
The default safe flow is inspect, edit on a branch, run tests, summarize the diff, and request review. The agent can be fast without being allowed to merge or deploy by itself. Reviewers should see what changed, why, which tests ran, and which risks remain.
For production deployments, use a separate approval gate. A successful build is not the same as permission to ship. Deployment should be tied to a commit SHA, environment, rollback path, and smoke test plan.
- Use branch-level write access and protected main branches.
- Require tests or focused verification before review.
- Block self-approval for merge, release, DNS, billing, and permission changes.
- Record the commit SHA, deploy target, and smoke-test evidence.
Monitor commands, costs, and destructive actions
A secure coding-agent workflow logs commands, files touched, network calls, package installs, and test results. This is not only for incident response. It helps teams learn which tasks are safe to automate and where agents repeatedly get stuck.
Destructive commands need special treatment. Database mutations, force pushes, hard resets, production deletes, credential rotations, and billing changes should require explicit human confirmation and ideally a dry run.
- Log command, working directory, exit code, and relevant output summary.
- Alert on force push, reset, delete, migration, deploy, and credential operations.
- Limit repeated test loops, package installs, and external API calls to control cost.
- Keep a rollback plan for production-facing changes.
Implementation checklist
- Run coding agents in a branch, worktree, or container with a narrow task scope.
- Keep production secrets out of the agent workspace unless a verified smoke test requires platform-level access.
- Require human review for merge, deploy, billing, credential, and destructive actions.
- Scan diffs and logs for leaked secrets, unexpected network calls, and unrelated edits.
- Tie every deployed agent change to a commit SHA, build result, and production smoke test.
FAQ
Can AI coding agents work on production repositories?
Yes, but they should use branch isolation, least-privilege credentials, focused tasks, audit logs, and human approval for merge or deployment.
Should a coding agent have access to production secrets?
Usually no. Most coding tasks can build and test without production secrets. When verification requires secrets, use platform secret stores and behavior-based smoke tests rather than exposing the value.
What actions should require human approval?
Merges, production deploys, database mutations, billing changes, credential changes, destructive commands, and customer-facing external messages should require explicit approval.
How do prompt injection risks affect coding agents?
A repository file, issue comment, web page, or tool output can contain malicious instructions. The agent must treat those as untrusted data and follow the operator's task and system policy instead.
What evidence should a coding agent report?
It should report files changed, tests run, build results, remaining risks, commit SHA if available, and production smoke evidence after deployment.