Building a Human-Gated Terraform Review Workflow with Kiro Crew

How I used specialized Kiro agents, real Terraform plans, deterministic guardrails, and human approval to detect, block, remediate, and verify risky infrastructure changes.

Contardo Acuña

Published Aug 23, 2026

Last modified Aug 24, 2026

This was my first project using Kiro Crew.

I wanted to test it against a workflow that has become increasingly familiar to infrastructure teams: a Terraform change originates from a compliance or business requirement, passes syntax validation, and appears ready for production—but quietly introduces a security or reliability regression.

A Terraform plan can be completely valid while still opening SSH to the internet, disabling database deletion protection, or reducing a production service to a single task. Terraform accurately reports the change, but it does not decide whether the change is operationally safe.

That observation became the starting point for ChangeGuard AI, a local and reproducible infrastructure change-review workflow built for the Ready, Spec, Ship Kiro Summer Hackathon.

The objective was not simply to ask an AI model to review Terraform. I wanted to design an accountable multi-agent workflow with explicit responsibilities, real evidence, deterministic safety boundaries, human approval, and a verifiable final result.

The complete source code is available in the ChangeGuard AI repository , and the end-to-end workflow can be seen in the demo video .

Starting with the specification

One of the most valuable parts of working with Kiro was following a simple principle:

Specification first, code second.

Before implementing the agents, I defined the expected behavior, supported rules, responsibilities, safety boundaries, artifact contracts, approval requirements, and conditions for producing a final verdict.

The project stores these decisions under the root .kiro directory:

1
2
3
4
5
.kiro/
├── agents/
├── crew/
├── specs/change-review/
└── steering/

The specification establishes several non-negotiable rules:

Agents must evaluate real Terraform plan evidence.
Missing or malformed evidence must never be treated as a pass.
Any failed or incomplete review must block the change.
No remediation may happen without genuine human approval.
The project must never execute terraform apply or terraform destroy.
A final verdict must be independently verified from artifacts.
SAFE_TO_SHIP only applies to the explicitly supported rules.

Starting with these constraints made it easier to give each agent a narrow purpose and prevented the workflow from becoming an open-ended autonomous system.

The problem: valid Terraform can still be dangerous

ChangeGuard compares two independently generated Terraform plans:

A baseline plan generated from the known-safe configuration.
A candidate plan generated from the proposed change.

Both are real outputs from:

1
2
terraform plan
terraform show -json

The baseline is generated before the candidate exists. This prevents a mutated candidate from inventing or redefining its own “before” state.

For the hackathon MVP, I deliberately limited the system to four high-risk transitions:

Rule	Risky transition	Severity
SEC-001	SSH ingress changes from an internal CIDR to 0.0.0.0/0	Critical
SEC-002	PostgreSQL ingress changes from an internal CIDR to 0.0.0.0/0	Critical
REL-001	ECS desired_count changes from at least 3 to 1	High
BR-001	RDS deletion protection changes from enabled to disabled	Critical

This narrow scope is intentional. ChangeGuard is not presented as a general-purpose Terraform security scanner.

A SAFE_TO_SHIP result means that the candidate or remediated plan passed these four supported checks. It does not claim that the infrastructure is universally secure or production-ready.

A crew of specialized agents

Instead of assigning the entire workflow to one general agent, I divided it among specialized Kiro agents.

Security Reviewer

The Security Reviewer evaluates SEC-001 and SEC-002. It focuses exclusively on changes that expose SSH or PostgreSQL traffic to the public internet.

Reliability Reviewer

The Reliability Reviewer evaluates REL-001 and BR-001. It looks for loss of service redundancy and removal of database deletion protection.

Remediator

The Remediator does not decide whether a change is safe. It receives an already-approved, supported finding and selects the corresponding narrow remediation path.

Crew Runner

A restricted execution agent runs the nodes defined by the Kiro Crew workflow. It coordinates task execution without receiving unrestricted authority over the repository.

Kiro Crew acts like the captain of this crew: it schedules the specialized agents, respects their dependencies, coordinates the two workflow stages, and pauses at the human approval boundary.

Separating AI judgment from deterministic mechanics

A central architectural decision was to separate policy judgment from mechanical execution.

The Kiro reviewer agents own the decision to return:

PASS
FAIL
INCOMPLETE

Deterministic Python scripts handle the mechanical parts:

Generating Terraform plans.
Extracting plain facts from plan JSON.
Aggregating structured results.
Applying a narrow, approved HCL edit.
Validating execution artifacts.
Producing the final verdict.

The deterministic rule-extraction code does not decide whether a value is safe. It provides structured evidence for the reviewer agents.

Conversely, the agents cannot arbitrarily rewrite Terraform. The remediation script only supports the small set of whitelisted edits associated with the four known rules.

This creates a useful division:

1
2
3
4
5
AI agents:
  interpret evidence and make scoped policy judgments

Deterministic code:
  generates evidence, performs approved mechanics, and verifies outcomes

The two-stage Kiro Crew workflow

ChangeGuard uses two Kiro Crew YAML DAGs.

Stage A: review

Stage A performs the initial review:

1
2
3
4
5
6
7
Baseline Terraform plan
        +
Candidate Terraform plan
        ↓
Security Reviewer ─┐
                   ├─→ Aggregation
Reliability Reviewer ─┘

The Security and Reliability Reviewers can execute concurrently because they evaluate independent rule sets.

The aggregation step applies fail-closed semantics:

Both reviewers return PASS → SAFE_TO_SHIP.
Either reviewer returns FAIL → CHANGE_BLOCKED.
Either reviewer returns INCOMPLETE → CHANGE_BLOCKED.

A successful security review cannot override an incomplete or failed reliability review.

Stage B: approval, remediation, and re-review

When Stage A blocks a change, Stage B is created:

1
2
3
4
5
6
7
8
9
10
11
CHANGE_BLOCKED
      ↓
Human approval gate
      ↓
Restricted remediation
      ↓
Real remediated Terraform plan
      ↓
Security re-review + Reliability re-review
      ↓
Independent final verdict

Kiro Crew’s force_approval mechanism provides the real human approval boundary. The workflow cannot continue until a person explicitly approves or rejects the remediation through the Gateway dashboard or the ChangeGuard Control Room.

Rejection leaves the Terraform configuration untouched and prevents all downstream remediation and verification tasks.

Demonstrating REL-001

The primary demo scenario starts with a safe Amazon ECS service:

1
desired_count = 3

The candidate change reduces it to:

1
desired_count = 1

The live workflow produces the following result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Candidate plan generated
        ↓
Security Reviewer: PASS
Reliability Reviewer: FAIL / REL-001
        ↓
CHANGE_BLOCKED
        ↓
HUMAN APPROVAL REQUIRED
        ↓
APPROVED
        ↓
desired_count restored from 1 to 3
        ↓
Remediated plan generated
        ↓
Security re-review: PASS
Reliability re-review: PASS
        ↓
SAFE_TO_SHIP

Every stage writes a structured JSON artifact. These include the baseline plan, candidate plan, reviewer results, blocked verdict, remediation result, remediated plan, re-review results, and final verdict.

The filesystem therefore becomes an explicit data plane between DAG tasks. A downstream task reads a known artifact path instead of relying on conversational memory or an implicit handoff between agents.

Building a live Control Room

To make the multi-agent process easier to understand, I also built an optional browser-based Control Room.

It visualizes:

The candidate Terraform change.
Security and Reliability Reviewer status.
Findings and severity.
Available workflow artifacts.
Human approval or rejection.
Remediator status.
The final verdict.

The Control Room does not replace the CLI workflow. It is an additive interface over the same Kiro Crew Gateway and local artifacts.

Security was also important in this layer. Gateway authentication remains inside the server-side Node process. Gateway tokens, cookies, internal secrets, and private filesystem paths are never sent to browser code.

This interface added a light gamification element, but its main purpose was observability: I wanted to see the crew operating in real time instead of treating the workflow as a black box.

Guardrails beyond the prompt

Prompt instructions alone are not a sufficient safety boundary.

ChangeGuard uses a Kiro preToolUse hook to block commands matching:

terraform apply
terraform destroy
AWS CLI invocations
Destructive recursive filesystem deletion

The deterministic scripts also enforce their own independent command allow-list. There is no code path that constructs an apply, destroy, AWS CLI, or destructive removal command.

The demo uses fake provider credentials with Terraform’s credential and metadata checks disabled. It creates real local plans but never contacts an AWS account or creates infrastructure.

No AWS credentials, LocalStack instance, Docker environment, or cloud deployment are required.

A lesson from live Kiro Crew execution

Testing the workflow exposed an important orchestration lesson.

A Kiro Crew DAG node executes as an agent conversation rather than as a literal deterministic subprocess. A nested command can fail without its exit status being represented exactly as expected by the higher-level task state.

Crew task status can also lag behind an artifact that has already been written.

Because of this, ChangeGuard does not treat the Crew task status or plain agent output as the final source of truth.

The independent final_verdict.py backstop verifies that:

A dedicated remediation execution artifact exists.
The artifact reports a successful supported remediation.
The remediated Terraform plan was generated successfully.
The Security re-review returned PASS.
The Reliability re-review returned PASS.

Only then can it produce SAFE_TO_SHIP.

This was one of my most useful takeaways from the project: orchestration state is helpful for coordinating work, but a safety-critical result should be grounded in explicit, independently validated evidence.

Testing without consuming live credits

The default test suite is deterministic and skips live agent calls:

1
make test

Live reviewer tests are available separately:

1
make test-live

This separation matters because live agent tests consume Kiro credits and are slower than deterministic checks.

At the time of the final validation, the project had:

286 passing core Python tests.
24 live-only tests skipped by the deterministic suite.
111 passing Control Room tests.
A successfully validated live REL-001 workflow.

Running the demo locally

The required tools are:

Terraform
Python 3
Kiro CLI
Kiro Crew

Start by checking the environment and generating the baseline:

1
2
3
make setup
make baseline
make demo-rel

Start the Kiro Crew Gateway in another terminal:

1
kirocrew gateway --approval interactive --port 8787

Then launch Stage A:

1
2
3
python3 scripts/changeguard_launch.py \
  --gateway-url http://127.0.0.1:8787 \
  --stage review

If the result is CHANGE_BLOCKED, launch Stage B:

1
2
3
python3 scripts/changeguard_launch.py \
  --gateway-url http://127.0.0.1:8787 \
  --stage remediation

Approve or reject the remediation through the Gateway dashboard or the Control Room.

The final result can be inspected in:

1
artifacts/final-verdict.json

The repository README contains the complete setup, testing, architecture, and safety documentation.

What I learned from my first Kiro Crew project

Kiro Crew made it possible to coordinate specialized agents around a real engineering workflow rather than a single prompt.

The strongest results came from combining:

Clear specifications.
Narrow agent responsibilities.
Structured artifact contracts.
Deterministic mechanical operations.
Explicit permission boundaries.
Human approval before mutation.
Independent verification after agent execution.
Honest limitations on what SAFE_TO_SHIP means.

The goal was not maximum autonomy. The goal was useful automation inside a workflow that remained understandable, auditable, and controlled by a human.

That distinction changed the project from “AI reviewing Terraform” into a small but complete infrastructure change-management system.

For a first experience with Kiro Crew, it was an excellent opportunity to explore not only what a coordinated group of agents can do, but also how to design the boundaries that make their work trustworthy.

Resources

# kiro-agent # kiro # terraform # github

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Building a Human-Gated Terraform Review Workflow with Kiro Crew

Contardo Acuña

Starting with the specification

The problem: valid Terraform can still be dangerous

A crew of specialized agents

Security Reviewer

Reliability Reviewer

Remediator

Crew Runner

Separating AI judgment from deterministic mechanics

The two-stage Kiro Crew workflow

Stage A: review

Stage B: approval, remediation, and re-review

Demonstrating REL-001

Building a live Control Room

Guardrails beyond the prompt

A lesson from live Kiro Crew execution

Testing without consuming live credits

Running the demo locally

What I learned from my first Kiro Crew project

Resources