AWS teaches its DevOps Agent to open the pull request too

The agent gets a hand on the codebase

Your DevOps agent used to hand you a paragraph at 2am. You still had to write the diff. That is the part AWS is chipping at this week.

On 14 July 2026 the AWS DevOps Blog published a walk-through that chains the AWS DevOps Agent, already generally available, with the Kiro CLI running in headless mode. The agent still does what it did before: consume a CloudWatch alarm, correlate telemetry across CloudWatch, deployment pipelines and application logs, publish a lifecycle event to EventBridge. What is new is the second half of the pipeline. A Lambda picks up the finding, CodeBuild launches the Kiro CLI, and the CLI writes the fix into the codebase and opens a pull request. Your on-call is a reviewer now, not an author.

Small change to describe. Large one to reason about.

The plumbing, in one paragraph

The reference architecture is not subtle: CloudWatch to DevOps Agent to EventBridge, then Lambda, then CodeBuild, then the Kiro CLI, then CodeCommit and CodePipeline. The CLI is invoked as kiro CLI chat --no-interactive --trust-tools=read,write,grep,shell. The --trust-tools flag is the least-privilege wall the binary is allowed to punch through inside the build container. A steering file in the repo tells the CLI what the repo looks like, which files are protected, and when to refuse: if the prompt is ambiguous or the tool cannot determine what to change, it makes no changes rather than guessing. That fail-safe is written down.

Then a buildspec runs a second wall of checks: max three files touched, no new files, no new dependencies, no deletions, protected files not modified, Python syntax valid, YAML lint clean. Only after that does a pull request appear. Only after human approval does anything deploy.

Two guardrails inside the box. One on the outside. The outside one is the reviewer.

What the agent is allowed to do, and what it trusts to know

The number to memorise is three. Three files, no new dependencies, no deletions. Everything past that is banned by the steering file and re-banned by the buildspec. If you sat down to write "an AI can only do damage of this shape", you would probably write this list. It is a reasonable list.

It is also a list you have to trust. There is nothing in the post about signing the steering file, pinning it to a commit, or verifying that the CodeBuild container running the CLI is the container your platform team approved. If a maintainer edits the steering file to add another protected path, the next remediation respects it. If an attacker with commit rights edits it to remove one, the next remediation also respects it. The agent is only as narrow as the config it reads at build time.

Signed. Enforced. Still trusts a text file in the repo.

Where this sits next to a normal deploy gate

Read the pattern as an ordinary human PR pipeline where the human at the top has been swapped for an agent. Everything downstream, the review, the required checks, the branch protection, the deploy gate, is doing the work it did last month. What moved is who authored the diff. If you would not merge a stranger's three-file PR without a security scan, do not merge the agent's without one. Payments change still needs two humans. The agent has no special claim on your merge queue.

How popular tools handle "agent proposes, pipeline gates"

The interesting design question here is what keeps the deploy pipeline the last honest actor when the code is machine-generated. Five ways teams handle it today:

• GitHub Actions with branch protection and required checks. The GitHub-native answer. Agent opens a PR against a protected branch, required status checks run (CodeQL, unit tests, secret scanning), CODEOWNERS gates reviewers. Cheap and honest. Weakness: workflow files live in the repo the agent is editing, so .github/workflows/*.yml is exactly the file class you want on the protected list.
• GitLab merge trains with policy MRs. Merge trains plus security policies stored in a separate policy project the agent generally has no commit access to. If you can afford the setup complexity, this is stronger than in-repo config, and for regulated shops it is honestly the better fit than any of the others below.
• Jenkins with a shared library. Old-school and still competitive. The Jenkinsfile stays skeletal in the repo; the gating logic lives in a shared library the platform team owns. The agent's PR cannot rewrite the pipeline; the pipeline is somewhere else.
• Buddy. Buddy defines pipelines in the UI or a YAML file, and any action can be marked as manual approval. One concrete reason to reach for it here: the manual-approval action is a first-class node in the pipeline graph rather than a separate branch-protection concept, so "human approves before deploy" reads the same whether the PR author is a human, an agent, or a scheduled job. Trade-off: fewer prebuilt policy-as-code primitives than a GitLab policy project, and a smaller third-party check ecosystem than the GitHub Actions marketplace.
• Argo CD with sync waves. Not strictly a CI tool. Push the gate into GitOps: the PR merges, Argo runs progressive sync waves, a failed health check pauses the rollout. Overkill for the "restart a Lambda" class of remediation this pattern is aimed at.

Pick the one you already run. The wrong answer is bolting on a new tool because the agent is new. The agent is the interesting piece. The gating is not.

The kicker

A DevOps agent that writes a paragraph is a search engine with a temper. One that writes a diff is a junior engineer with commit rights and no career fear. AWS's answer is a reasonable one: two internal guardrails, one external reviewer, three files max. It also puts the entire trust of the system on a text file in the repo, and on a human who is now reviewing more PRs than they were last week.

Automate the diff. Do not automate the reviewer. And whatever you do, do not let the steering file wander.