AI Agents in the SDLC: Permissions and Checkpoints

Assistants and agents are different risks

	Assistant	Agent
How it works	Suggests code or answers; a person applies it	Plans and carries out multi-step work: edits files, runs commands, calls tools
Where a person sits	On every change, by default	Wherever you put a checkpoint, and nowhere else
Main risk	Accepting a wrong suggestion	Actions taken with the permissions it was given
Main control	Review	Permissions, environments and approval points

The practical rule: an agent can do anything its credentials allow. Design its access as you would for a new contractor on their first day, and then narrower.

Where agents fit in each stage

Stage	Useful agent work	Keep with a person
Planning	Summarizing issues, drafting task breakdowns, finding related code	Priorities, scope, and what not to build
Design	Listing options, drafting a design note from a brief	Choosing between options with long-term cost
Implementation	Well-specified changes, migrations, test scaffolding	Security-sensitive and safety-related code decisions
Testing	Writing and running tests, reproducing bugs	Judging whether the tests prove the right behavior
Review	First-pass comments, consistency checks	Approval and merge
Release	Preparing release notes, checking the pipeline	The decision to deploy, and rollback calls
Operations	Gathering logs and timelines during incidents	Production changes and customer communication

Designing permissions and checkpoints

List the actions. Read code, write code, run tests, install packages, open pull requests, comment, merge, deploy, change infrastructure, read production data, use secrets.
Classify each action. Allowed without approval, allowed with approval, or never. A common starting point: agents may read code, edit in a branch, run tests in a sandbox and open pull requests; they may not merge, deploy, change infrastructure or touch secrets without a named person approving.
Separate environments. Run agents in sandboxes or containers with no production credentials and limited network access.
Use scoped credentials. Short-lived tokens with only the permissions needed, tied to an identifiable agent account so its actions are distinguishable from a person's.
Protect the main branch. Require review and passing checks for every change, whoever or whatever opened it.
Log everything. Commands run, files changed, tools called. You cannot review what you cannot see.

Write these decisions into your AI coding assistant policy so the team works from the same rules.

Risks specific to agents

Scope creep: the agent changes files beyond the task. Check the full diff, not just the files you expected.
Untrusted input: agents read issues, web pages, documents and code comments. Text in those sources can contain instructions the agent may follow. Treat anything an agent reads from outside as untrusted, and limit what it can do as a result.
Supply chain: agents may install packages. Restrict installs to approved registries and review manifest changes.
Weakened checks: an agent asked to make tests pass may change the tests. Review test changes separately.
Secrets exposure: anything in the agent's environment can end up in logs, prompts or pull requests.
Cost and runaway loops: set limits on run time and spend.

Writing tasks agents can do well

Agents do better with the same things that help people: a clear goal, context and a definition of done.

Task template

Goal: one sentence describing the outcome.
Context: relevant files, related issues, constraints, patterns to follow.
Out of scope: what must not change.
Done when: tests that must pass, behavior to demonstrate.
Report back: summary of the approach, what was tried and rejected, open questions.

Rolling agents out to a team

Start with low-risk work: tests, documentation, dependency updates, small refactors in well-tested code.
Pair first. An engineer supervises the agent closely until the team knows where it fails.
Review the reviews. Check whether agent pull requests are getting real scrutiny. See reviewing AI-generated code.
Expand gradually, one permission at a time, based on what you observe.
Measure outcomes, including rework and incidents, not only volume. See DORA, SPACE and DX Core 4.

What to monitor once agents are running

Signal	Why it matters
Share of agent pull requests merged without changes	Very high can mean light review, not perfect output
Agent pull requests reverted or reworked	Shows where agents are not yet reliable
Files changed outside the task scope	Early warning of scope creep
Permission denials and approval requests	Shows whether boundaries are set in the right place
Run time and spend per task	Catches loops and tasks that are poorly specified
Incidents with an agent action as a contributing factor	Feeds your permission design

Review these with the team every few weeks during rollout. When an agent action does contribute to an incident, run the same review you would for any other cause; see blameless postmortems.

Common questions

Can an agent merge its own pull requests?

It can if you let it. Most teams keep merge with a person and enforce that through branch protection. Decide deliberately, and write the decision down.

Who is accountable for an agent's change?

The person who assigned the task and the person who approved the merge. An agent cannot hold responsibility. In regulated work this needs to be explicit; see AI in regulated engineering.

Should agents have access to production?

Read-only access to logs and metrics can help during incidents. Write access to production raises the stakes considerably; most teams require a person to approve each such action.

Will agents replace junior engineers?

Teams still need people who will become the senior engineers of the future. Agents change what early career work looks like; they do not remove the need to grow people.