Release readiness code reviews

Release readiness code reviews evaluate your code changes for cross-repository dependency risks, internal standards compliance, and access-control correctness. It also performs simulated verification – it builds, runs, and tests your code changes – in a sandbox environment managed by the AWS DevOps Agent.

Getting started

To use release readiness code reviews, complete the following setup steps.

Step 1: Enable change reviews on your repositories

Change reviews must be enabled on your connected GitHub or GitLab repositories before automated code reviews can trigger.

For GitHub: Navigate to the Code Review and Automated Testing section in your GitHub integration settings and verify the Change review checkbox is enabled for each repository. Change review is enabled by default when you connect repositories. For detailed instructions, see Configuring Code Review and Automated Testing.

For GitLab: Navigate to the Code Review and Automated Testing section in your GitLab integration settings and enable change reviews for your projects. For detailed instructions, see Configuring Code Review and Automated Testing.

Step 2: Configure private VPC access for the simulated verification environment (optional)

Release readiness code reviews can perform simulated verification by building, running, and testing your code changes in a sandbox environment (see #Simulated-verificaton). If your code build process requires artifacts from internal systems — such as private image repositories (for example, Artifactory, Docker Hub Enterprise), internal build artifact stores, or dependent code repositories — you need to give the simulated verification environment access to a VPC that can reach those service endpoints.

The simulated verification environment runs in an isolated sandbox with Internet access. By default, it does not have network access to your internal systems. To enable access, create a private connection and associate it with your pipeline provider (GitHub or GitLab). The simulated verification environment uses the VPC associated with that private connection by creating and managing an ENI inside the VPC, giving the build sandbox network access to your internal services.

To configure private VPC access for simulated verification:

Once associated, the simulated verification environment will provision an ENI in the private connection's VPC, giving it direct network access to your internal services during code review builds.

Step 3: Add credentials for simulated verification (optional)

When the simulated verification environment builds your code project, it may need credentials to authenticate with internal services — for example, credentials for Artifactory, Docker Hub, private npm registries, or internal Maven repositories.

These credentials are stored in AWS Secrets Manager in the same AWS account as your Agent Space and are securely injected into the simulated verification environment at build time.

Storing credentials in Secrets Manager

Mapping credentials to the simulated verification environment

After storing your credentials in Secrets Manager, use a DevOps Agent Skills to map each secret ARN to the intended technology and instruct the agent on how to populate credential configurations in the sandbox environment.

Create a Skill with instructions that tell the agent which secrets to retrieve and how to use them. For example:

---
name: simulated-verification-credentials
description: Instructions for configuring build credentials during simulated
  verification. Use this skill when setting up the sandbox environment for
  code review builds.
---

# Build Credential Configuration

When setting up the simulated verification environment, retrieve and configure
the following credentials:

## Docker Hub

- Secret ARN: `arn:aws:secretsmanager:us-east-1:123456789012:secret:devops-agent/build/docker-hub`
- Technology: Docker
- Set the `DOCKER_USERNAME` and `DOCKER_PASSWORD` environment variables from this secret
- Run `docker login` with these credentials before executing builds

## Artifactory

- Secret ARN: `arn:aws:secretsmanager:us-east-1:123456789012:secret:devops-agent/build/artifactory`
- Technology: Artifactory (npm registry)
- Write the token to `.npmrc` as `//your-artifactory.example.com/:_authToken=<token>`

## Application Secrets

- Secret ARN: `arn:aws:secretsmanager:us-east-1:123456789012:secret:devops-agent/build/app-env`
- Create a `.env` file in the project root with the following keys from this secret:
  - `DATABASE_URL`
  - `API_KEY`
  - `REDIS_URL`

The agent automatically loads this Skill during simulated verification and uses the instructions to retrieve secrets from Secrets Manager and configure the sandbox environment — setting environment variables, writing .env files, or populating tool-specific configuration files as needed.

Performing a code review

You can request a code review on-demand through DevOps Agent chat:

The agent evaluates the specified scope — a branch, commit, or set of changes — and returns a release readiness report. The report includes:

Reviews typically complete in 8–10 minutes, depending on the size and complexity of the change.

Automated code reviews

Automated code reviews run without manual intervention. They can trigger in two contexts:

Code reviews during code generation

When using the Kiro Power or Claude Code plugin, the coding agent can invoke a release readiness review as code is being generated. The review evaluates the in-progress changes against your policies and dependencies, surfacing findings directly in the IDE before the code is committed.

If issues are found, the coding agent is notified and can address them immediately — fixing policy violations, correcting over-permissioned IAM policies, or preparing dependent changes in other repositories.

Code reviews in pull requests and merge requests

When automated PR/MR reviews are enabled, the agent reviews every new pull request and merge request in your connected repositories. Reviews trigger when:

Findings appear as inline comments on the affected lines of code, with the overall assessment posted as a PR/MR comment. You can configure whether findings block merges (required status check) or are advisory only.

Simulated verificaton

When a release readiness review performed, the agent creates a sandboxed environment to build, run, and test your application for simulated verification. This provides functional validation beyond static code analysis — the agent compiles your code, starts the application in an isolated sandbox, and executes tests to verify that the changes work as expected.

Findings from sandboxed functional testing are included in the final release readiness report alongside standards, dependency, and access-control findings.

You can use Agent instructions (AGENTS.md) to tune how simulated validation testing is performed — for example, specifying which test commands to run, what constitutes a passing build, or which parts of the application to exercise during verification.

Reviewing code review results

Each code review produces a report accessible in the Release Manager section of the DevOps Agent web app. Reports include:

You can also ask follow-up questions in DevOps Agent chat: "Why did the review flag the IAM change in line 42?" or "What repositories depend on the API endpoint I modified?"

Integrate with Kiro IDE and CLI

To use release readiness code reviews in Kiro:

From the Kiro CLI, you can also trigger reviews explicitly: the coding agent will invoke the release readiness review and incorporate findings into its workflow.

Integrate with Claude Code

To use release readiness code reviews in Claude Code:

Integrate with AWS Transform custom

To use release readiness code reviews in AWS Transform custom :

Using code reviews in GitHub

Prerequisites: GitHub repository connected to your Agent Space with automated reviews enabled.

Using code reviews in GitLab

Prerequisites: GitLab repository connected to your Agent Space with automated reviews enabled.

Using code reviews in DevOps Agent chat

From DevOps Agent chat, you can:

Agentic safety guardrails

Release readiness reviews include built-in safety guardrails that prevent common unsafe agent behaviors. These guardrails are always active during the review process. Specific coverage and enforcement behavior may change as the feature evolves. While we aim to cover as many common unsafe behaviors as we can, some behaviors will not have corresponding guardrails in place.

Credential exposure prevention

The agent blocks any tool call where the tool input contains common credential patterns in plaintext, such as AWS keys, access tokens and private keys.

Sensitive file exfiltration detection

The agent scans and blocks shell commands that combine access to sensitive file paths with network operations, preventing data exfiltration attempts.

Mutative AWS operation blocking

The agent blocks any AWS API call that would modify your infrastructure. This prevents the review agent from making changes to your AWS environment during analysis. Read-only operations (describe, get, list) are permitted; mutative operations are blocked.

Read-only operations such as describe_*, get_*, and list_* are permitted.