When AI agents can apply cloud changes, change control has to change

May 5, 2026

AI-generated Terraform is not new. Engineers have been using Copilot, ChatGPT, Claude, Cursor, and other tools to write infrastructure code for years.

For a while, that was manageable because the human was still the control point. The engineer reviewed the diff. The engineer ran the plan. The engineer decided whether the change should be applied.

That assumption is starting to break.

With permissive settings, a coding agent can move from “generate Terraform” to “run the command that applies it.” Claude Code can execute shell commands through its Bash tool. Cursor can call external systems through MCP servers. AWS access can come from local credentials, development roles, CI credentials, or an MCP server pointed at an AWS account.

Most of these tools ask for approval before sensitive actions in their default configuration. That helps, but it is not the same thing as governance. Approval prompts, auto-run modes, broad allowlists, and bypass settings are local interaction controls. They are not a change-control model.

The real governance question is different:

What happens between “the agent decided to make a change” and “the change is running in your AWS account”?

For many teams, the answer is uncomfortable. Their controls were built around human-authored changes: PR review, CI checks, Terraform plans, manual approvals, and deployment conventions. Those controls often assume that a person is still reading the change, judging the risk, and deciding whether to execute it.

Agentic execution changes that assumption.

This post looks at the failure modes that appear when AI agents get execution access to AWS infrastructure, and how to add a governance layer that catches unsafe changes before apply, not after an incident.

What's actually new here

The risk is not that AI can write Terraform. Teams already know how to think about that.

A human can ask an AI tool to create a security group, read the generated code, notice the open SSH rule, and reject it. In that case, AI speeds up code generation, but the human stays in the execution path.

What is new is agentic execution.

An agent can read a repository, inspect existing infrastructure code, generate a change, run local commands, retry after errors, call tools, and keep working toward the goal. With the wrong access pattern, the agent is no longer just producing code for review. It is participating in the execution path.

That is a different threat model from “an engineer uses AI to write faster.”

Before, the engineer was the control point. Now the control point may be the agent, a local permission prompt, or a broadly scoped credential that was never designed for autonomous use.

Agents are built to complete tasks. They are not naturally built to understand blast radius, compliance evidence, cost discipline, or change-control integrity.

IAM is necessary. It is not sufficient.

The obvious response is to lock down permissions.

That is the right instinct, but it is not enough.

IAM controls what an identity can do. It does not decide whether a specific infrastructure change is appropriate, reviewed, cost-bounded, connected to business intent, or safe to apply right now.

A least-privilege role can still make a bad change inside its allowed scope. A development role can still open an unsafe port in a development VPC. A CI role can still roll every task in a service. A sandbox role can still create resources that exceed budget or violate internal policy.

IAM answers:

Is this API call allowed?

A governance layer answers:

Should this change be applied, in this environment, by this actor, with this blast radius, at this time?

Those are different controls. Agentic execution needs both.

The four failure modes specific to agentic execution

These are different from the broader process failures that show up when teams ship AI-generated infrastructure without a governed path. Those are organizational failures. These are agent-specific technical failures.

1. Permission inheritance without intent boundaries

When you give an agent access to AWS, it inherits whatever permissions are available through that access path.

That access may come from a local developer profile. It may come through an MCP server. It may come from a CI role. It may be a role that was originally created for humans or scripts, not autonomous agents.

If that role has broad permissions, the agent operates with broad permissions. It does not know that the human only meant for it to make a narrow change. It does not know that it should stay in a sandbox unless that boundary is enforced outside the model. It does not know that the RDS cluster is off limits unless the access path prevents it.

AWS IAM has no concept of “the human intended this task to be smaller.” The policy is the policy.

An over-permissioned agent is not a future risk. It is an over-permissioned identity with a fast execution loop.

2. Valid infrastructure that is still wrong

The most dangerous infrastructure mistakes are not always syntax errors.

A configuration can be syntactically valid, pass terraform plan, apply successfully, and still be operationally wrong.

For example:

resource "aws_security_group_rule" "ssh" {
  type              = "ingress"
  security_group_id = aws_security_group.app.id
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
}

Terraform may apply this successfully. AWS may accept it. The agent may see a clean exit code and mark the task complete.

But the change is still unsafe.

The same pattern shows up in less obvious ways:

a larger instance class than needed
a public subnet where a private subnet was expected
missing deletion protection on a database
a permissive IAM action added for convenience
a new NAT gateway or load balancer that changes monthly cost
a deprecated or region-specific resource configuration that works today but fails later

Agents do not need to hallucinate a nonexistent AWS API to create risk. They only need to create infrastructure that is valid, but misaligned with your security, cost, reliability, or operational policies.

3. No blast-radius awareness

An agent asked to “update the database connection string” may modify an ECS task definition. That may trigger a rolling deployment across every task in the service.

The agent may not know:

the service has 40 running tasks
the change is happening on Friday afternoon
downstream services reconnect aggressively
the last similar deployment caused elevated error rates
the database is already near its connection limit
the change should happen during a maintenance window

Blast radius is organizational context. It lives in architecture decisions, incident history, customer commitments, team conventions, and runtime behavior.

Agents do not automatically have that context. Even when they do, context inside a prompt is not the same thing as an enforced control.

The governance challenge is to put blast-radius evaluation in the execution path without making the process so slow that teams route around it.

4. Audit trail fragmentation

When an agent applies a change, several systems may record pieces of what happened.

CloudTrail captures AWS API calls. Terraform state records resource changes. Git may contain the code diff. The agent may have a session log. The user’s terminal history may contain commands.

But the decision record is often missing.

What task was the agent completing? Who initiated it? What did the agent propose? What checks ran before apply? What risk was accepted? Who approved the change? What exactly was approved? Did the applied result match the approved intent?

Three months later, when a security group change appears in CloudTrail at 2 a.m., “the agent did it” is not an audit trail. It is a gap.

Compliance teams, enterprise customers, auditors, and incident responders need a coherent record that ties intent, plan, approval, execution, verification, and monitoring back to one change.

Agentic execution makes that record more important, not less.

What a governance layer for agentic execution needs to do

The instinct is usually to go to one of two extremes:

lock the agent down so tightly that it becomes useless
require a human to approve every single action

Neither approach scales well.

A better pattern is a governed path that the agent is required to use. The agent can propose. The governance layer evaluates. Humans approve where judgment is required. Low-risk changes can be policy-approved when the organization is ready.

The important part is that the agent does not evaluate itself.

A real governance layer should enforce five things.

1. Structured intent

The agent should not jump straight from prompt to terraform apply.

It should describe the proposed change as a structured object: what changes, in which environment, why, who or what initiated it, and which resources are affected.

At CloudBooster, this is represented as a ChangeSet.

The ChangeSet becomes the unit of review, approval, execution, audit, and monitoring.

2. Automated checks before approval

Before a human sees the change, automated checks should evaluate it for:

security policy violations
IAM scope changes
network exposure
cost deltas
blast radius
environment mismatch
drift from approved state
missing ownership or ticket context
policy exceptions

This changes the approver’s job.

Instead of reading raw Terraform line by line, the approver reviews the proposed intent, the generated plan, and the policy findings. That creates a faster and more reliable decision surface.

3. Explicit approval or policy-based auto-approval

Not every change needs the same level of human involvement.

A security group change that exposes SSH to the internet should require explicit review. A tag update on an existing resource probably should not. Scaling an ECS service from 4 to 5 tasks may be acceptable if it stays inside a pre-approved range.

The governance layer should support both:

named human approval for material changes
policy-gated auto-approval for routine, low-risk changes

The path should be the same either way. The difference is whether the approval decision comes from a person or from a policy the team has already approved.

4. Controlled execution

The agent should not hold broad AWS credentials and apply changes directly.

Execution should happen through a scoped role and a controlled runner. The runner should apply only what was approved, stop on unexpected state, and record the result.

This is the distinction between IAM and governance:

IAM limits the runner’s maximum possible actions.
Governance limits which specific approved change the runner is allowed to execute.

Both layers matter.

5. Durable audit record

The system should preserve a durable record of:

who or what initiated the change
the proposed ChangeSet
the generated plan
automated check results
approval decision
execution logs
post-apply verification
monitoring and drift signals tied to the change

This record should be queryable later. Teams should not have to reconstruct intent from terminal history, agent logs, Terraform state, and CloudTrail.

How CloudBooster wires this in practice

At CloudBooster, every infrastructure change moves through the same governed path, whether it was authored by a human, generated by an AI tool, or proposed by an autonomous agent:

Propose — the change is captured as a typed ChangeSet: what changes, in which environment, and who or what initiated it.
Validate — security, cost, blast-radius, and policy checks run before approval.
Approve — a named approver reviews the ChangeSet, the plan, and the check results.
Execute — CloudBooster applies the approved change in your AWS account through a scoped IAM role.
Record — the decision, plan, approval, execution result, and evidence are attached to the ChangeSet.
Monitor — drift and regressions are tied back to the specific change that introduced or affected them.

The key point for agentic execution is simple:

The agent proposes. The governance layer evaluates. A human or approved policy decides. Controlled execution applies.

The agent never gets unmediated production apply access.

That preserves the speed of AI-assisted infrastructure work without turning the agent into the change-control authority.

How to wire this with AI coding agents

Option 1: Agent proposes, CloudBooster governs, human approves

This is the cleanest starting point for teams using Claude Code, Cursor, or similar tools.

Configure the agent so infrastructure execution paths are denied or approval-gated. Block direct terraform apply from the agent. Require it to emit a structured ChangeSet instead of executing the change directly.

The flow looks like this:

The engineer asks the agent to make an infrastructure change.
The agent inspects the repository and proposes a ChangeSet.
CloudBooster runs checks against security, cost, blast-radius, and policy rules.
The approver sees the proposed change, the generated plan, and the check results.
On approval, CloudBooster applies through a scoped AWS role.
The result is recorded and monitored.

The approver is not reviewing a wall of raw Terraform. They are reviewing intent, plan, and risk findings.

That is the difference between a slow manual gate and a usable governance layer.

Option 2: Policy-gated auto-approval for low-risk changes

As your policy graph matures, routine changes can move faster.

Examples include:

adding approved tags to existing resources
scaling an ECS service inside a defined range
rotating a secret through an approved path
updating non-production resources inside a sandbox boundary
changing configuration that has passed the same checks many times before

These changes can be auto-approved when they match a pre-approved policy.

The governance layer still runs. The ChangeSet is still recorded. Checks still execute. Execution still happens through the controlled path.

The difference is that the approval decision is made by policy instead of waiting for a person.

This is how teams scale agent-generated infrastructure work without hiring more approvers. They codify more judgment into policy and keep humans focused on exceptions.

Option 3: Stop on unsafe or unexpected state

Agents will run into situations they were not designed for.

A plan may not match the proposed intent. The environment may have drifted. A generated change may affect more resources than expected. A dependency may behave differently in production than it did in the agent’s local context.

The governed path needs an emergency stop that does not depend on humans coordinating under pressure.

If what is about to execute does not match what was checked and approved, execution should halt before the inconsistency reaches production.

This is different from Terraform error handling. Terraform catches many syntax, provider, and state errors. It does not know your business intent, approved blast radius, or internal policy boundary.

A governance layer should stop on those semantic mismatches and preserve the break-glass record: what stopped, why, who was notified, and what state the environment was in.

What this is not

It is not a prompt-injection defense

If an attacker can manipulate an agent’s inputs, a governance layer helps by forcing the resulting infrastructure change through checks and approval.

But prompt injection is a separate class of risk. It requires controls around inputs, tool access, model behavior, secrets, and execution boundaries.

Infrastructure governance is not a complete prompt-injection mitigation.

It is not a replacement for least-privilege IAM

Governance and IAM work together.

The execution role should be scoped. Credentials should be limited and revocable. Agents should not hold broad AWS access. Production apply should not run under a developer’s local profile.

But IAM alone cannot decide whether a specific change is safe, expected, cost-bounded, and approved.

It is not a reason to slow teams down

The bottleneck in most infrastructure teams is not approval itself. It is the lack of a fast, reliable, evidence-backed approval path.

A 30-second decision based on pre-run checks is faster than an incident that takes hours to diagnose.

The goal is not more bureaucracy. The goal is to move the right judgment to the right point in the workflow.

The trajectory

The volume of agent-generated infrastructure changes is going up.

Claude Code, Cursor, MCP servers, AWS integrations, CI agents, and the next generation of coding tools are all moving in the same direction: more autonomy, more tool use, and deeper access to production-adjacent systems.

The teams that handle this well will not be the teams that ban AI agents entirely. They will be the teams that put a governed execution path between agents and infrastructure before the first major incident makes it mandatory.

The primitive is simple:

No agent gets direct production apply. Every change becomes a governed ChangeSet.

If you are building on AWS and already using AI coding tools — or planning to — the CloudBooster pilot is the right next step. We walk through your AWS scope, your agent setup, and your policy starting point. You leave with the governed path wired in.