Published:
Estimated reading time:
9–10 minutes
AI can already understand cloud configurations, analyze security findings, generate Infrastructure as Code, and recommend changes.
The next question is much harder:
Should AI be allowed to change production infrastructure?
Giving an AI agent administrative cloud credentials and allowing it to execute whatever changes it determines are appropriate is technically possible.
It is also an enormous trust decision.
Cloud infrastructure controls networks, identities, databases, applications, encryption, storage, and production availability. A seemingly reasonable change can introduce an outage, create a security vulnerability, destroy data, or affect systems the AI did not realize were connected.
The answer is not necessarily to prevent AI from participating in infrastructure changes.
Instead, organizations need to control where AI operates, what it can access, how it proposes changes, how those changes are validated, and who ultimately decides whether they reach production.
A safer model treats AI as a powerful participant in an existing engineering process rather than an unrestricted production administrator.
Why AI Infrastructure Changes Are Different
Infrastructure automation is not new.
Organizations have used scripts, configuration management, Infrastructure as Code, CI/CD pipelines, and cloud automation for years.
Those systems generally execute predefined logic.
A Terraform pipeline applies infrastructure that engineers previously wrote and reviewed. An automation script performs operations someone explicitly programmed. A deployment workflow follows steps established in advance.
AI introduces something different.
An AI agent can reason about a problem and generate a new solution dynamically.
Given a security finding, it might determine that an IAM policy needs to change. Given an operational problem, it might decide to modify a network rule. Given a compliance violation, it might generate Terraform that changes encryption or storage configuration.
The action was not necessarily predefined.
The AI determined what change it believed would accomplish the goal.
That makes the execution boundary much more important.
The Most Dangerous Model Is Also the Simplest
The simplest AI remediation architecture looks something like this:
Finding → AI Agent → Production Credentials → Cloud API → Change
The AI discovers or receives a problem, determines what should happen, and uses privileged credentials to modify the environment directly.
This architecture is attractive because it is fast.
It also concentrates an extraordinary amount of authority in the AI system.
The agent needs credentials powerful enough to modify infrastructure. Its reasoning determines what gets changed. The change may happen before anyone reviews it. A mistake in interpretation, generated configuration, tool selection, or scope can immediately become a production incident.
There are also difficult questions about identity.
Whose authority is the AI using?
Can it modify every environment?
Does every user interacting with the AI effectively inherit the AI's permissions?
Can an organization reconstruct why a particular change occurred?
Direct autonomous execution collapses reasoning, authorization, generation, and production modification into one trust boundary.
A safer architecture separates them.
Start With Identity
Before asking what an AI agent should be allowed to do, organizations need to know on whose behalf it is acting.
An AI operation usually begins somewhere else.
A security engineer selects a finding.
A platform engineer requests a change.
A compliance workflow identifies a failed control.
An automated system triggers an investigation.
The AI should not erase that initiating identity.
If every request eventually becomes an operation performed by the same globally privileged AI identity, the organization loses an important part of its authorization and audit chain.
A stronger model preserves:
Who initiated the request → what they were authorized to do → what the AI did on their behalf
This becomes the foundation for deciding which tools, environments, repositories, and operations should be available to the AI.
Authorization Should Come Before AI Execution
A natural-language request is not authorization.
Neither is a compliance finding.
If someone asks:
Fix this production security issue
the AI's ability to understand the request does not mean the user is authorized to initiate the change.
Authorization should therefore occur before privileged tools or environments become available.
The system can evaluate factors such as:
requesting identity
target environment
requested operation
organizational policy
environment criticality
applicable approvals
contextual signals
scope of the requested task
The resulting authorization should determine what the AI can do.
This is particularly important in multi-cloud environments where a single AI interface may be capable of interacting with many AWS accounts, Azure subscriptions, and GCP projects.
The AI should not inherit access to all of them simply because the platform does.
Least Privilege Applies to AI Too
AI agents should follow the same least-privilege principle applied to humans and workloads.
An agent generating a Terraform remediation does not necessarily need permission to modify the corresponding production resources.
It may only need:
information about the finding
relevant cloud configuration
access to an isolated development environment
development and validation tools
permission to work with a specific repository
Separating these capabilities matters.
If the AI's job is to produce a proposed change, then production write access may not be necessary at all.
The safest credential is often the credential the agent never receives.
Give AI an Isolated Place to Work
AI agents need somewhere to perform their work.
Generating an infrastructure change may require creating files, modifying code, inspecting repository structure, running command-line tools, executing linters, or iterating after validation errors.
Those capabilities should not require giving the AI an unrestricted workstation or production environment.
An isolated execution environment provides a controlled workspace where the agent can perform development tasks without having direct access to unrelated systems.
For Infrastructure as Code remediation, the AI might:
inspect the finding and relevant configuration
generate Terraform
create or modify files
run formatting and linting tools
inspect errors
revise the code
repeat until validation succeeds
The isolation boundary limits what the agent can reach while still giving it useful tools.
It is important to distinguish this from a sandbox cloud account.
The purpose is not necessarily to deploy the proposed infrastructure into a fake version of production.
It is to provide a sandboxed execution environment for the AI itself.
Infrastructure as Code Is a Safer Interface for AI
AI can interact with cloud infrastructure in two fundamentally different ways.
It can call cloud APIs directly.
Or it can produce a description of the desired infrastructure change as code.
Infrastructure as Code provides several useful safety properties.
The proposed change is inspectable.
It can be version controlled.
It can be validated.
It can be compared with existing infrastructure definitions.
It can go through code review.
It can be deployed using established organizational workflows.
Most importantly, generating the change and executing the change become separate events.
The AI can contribute substantial value without being the final authority over production.
Validation Should Happen Before Human Review
Human review is important, but humans should not have to catch every basic problem in AI-generated code.
The AI execution environment can run automated validation before the proposed change reaches a reviewer.
Depending on the Infrastructure as Code technology, this can include:
syntax validation
formatting
linting
static analysis
policy checks
security checks
repository-specific tests
For Terraform, tools such as terraform validate and tflint can identify problems before a pull request is presented for review.
The AI can also use the output from those tools to iterate.
Instead of generating code once and handing the first attempt to a human, the workflow becomes:
Generate → Validate → Inspect Errors → Correct → Validate Again
This makes AI-generated infrastructure changes more similar to normal software engineering.
Validation Does Not Mean the Change Is Safe
Automated validation has limits.
Terraform can be syntactically valid and still describe a dangerous change.
A network rule can be perfectly formatted while exposing a production service.
An IAM policy can pass validation while granting excessive permissions.
A database change can be technically valid while creating downtime.
Validation therefore needs multiple layers.
Some tools determine whether the code is structurally valid.
Others can identify security or policy problems.
Repository tests may enforce organizational requirements.
Human reviewers can evaluate architectural intent, operational impact, and business context.
No single validation mechanism proves that an infrastructure change is safe.
The goal is defense in depth.
Git Can Become a Trust Boundary
Git is already a central control point for many infrastructure teams.
Organizations use repositories to define infrastructure, require reviews, enforce branch protection, run CI checks, preserve history, and control deployment.
AI-generated infrastructure can enter the same system.
Instead of:
AI → Production
the boundary becomes:
AI → Authorized Repository → Pull Request
This is a meaningful architectural change.
The AI can propose a modification without controlling whether that modification is merged.
Repository permissions can limit where the AI is allowed to write.
Branch protection can prevent direct modification of protected branches.
CI pipelines can run additional tests.
CODEOWNERS or similar mechanisms can require review from appropriate teams.
The organization retains the controls it already trusts.
The AI Should Not Choose Its Own Trust Boundary
An AI agent capable of generating code should not automatically be allowed to select any repository it wants.
Repository authorization should be explicit.
The organization may authorize the AI to work with a particular infrastructure repository or a defined set of repositories.
If the workflow permits creating a new repository for remediation, that capability should also be governed.
This prevents an apparently harmless remediation workflow from becoming a general-purpose mechanism for writing code anywhere in the organization.
Least privilege applies to source control as much as it applies to cloud credentials.
Pull Requests Create a Natural Human Decision Point
Pull requests provide a useful interface between AI reasoning and human authority.
The AI can explain:
what problem it is addressing
which infrastructure it proposes changing
why the change should resolve the issue
which files were modified
what validation was performed
A reviewer can inspect the actual code and supporting context.
The reviewer can approve it, request changes, or reject it.
This is much stronger than asking a user to approve an abstract instruction such as:
AI wants to fix the security issue. Allow?
Approval should be attached to something concrete.
Infrastructure as Code provides that concrete artifact.
Existing Deployment Pipelines Should Remain in Control
Approving an AI-generated pull request does not necessarily mean the AI should deploy it.
Once approved, the change can move through the same deployment process used for human-authored infrastructure.
That process may include:
CI validation
security checks
policy enforcement
change-management approval
environment protection
deployment windows
Terraform plan review
deployment automation
This avoids creating a separate privileged path to production simply because AI generated the change.
The AI participates in the engineering workflow rather than bypassing it.
Human-in-the-Loop Does Not Mean Humans Do Everything
There is sometimes a false choice between full automation and completely manual operation.
Human-in-the-loop systems can automate most of the expensive work while preserving human authority at important decision points.
AI can investigate the problem.
AI can understand the relevant configuration.
AI can generate the proposed solution.
AI can run validation tools.
AI can correct its own code.
AI can prepare the pull request.
The human does not need to reproduce all of that work manually.
The reviewer focuses on the decision that matters:
Should this proposed change be allowed to proceed?
That is a much more scalable use of human attention.
Some Actions Do Not Fit Infrastructure as Code
Not every cloud remediation is naturally represented as a persistent infrastructure configuration.
Consider a detached storage volume that has been verified as unnecessary.
The desired operation may simply be:
Delete it.
There may be no meaningful Terraform configuration to create.
This does not mean the action should bypass governance.
Discrete operational actions can still be represented through controlled remediation workflows.
For example, a remediation action can be defined in a repository as an executable playbook. The AI or governance system can propose invoking that action with specific parameters.
The request itself can move through a pull request.
After approval, the organization's pipeline executes the action using its normal credentials and controls.
This preserves the same fundamental separation:
AI proposes → organization approves → trusted automation executes
The artifact changes, but the trust model remains.
Auditability Needs More Than the Final Git Commit
Git provides an excellent record of the proposed infrastructure change.
It does not necessarily capture the entire AI decision chain.
Organizations may also need to know:
which finding initiated the workflow
who selected the finding
what identity initiated the AI operation
which environment was involved
which tools the AI used
which repository it accessed
what validation was performed
which pull request resulted
who approved the change
what ultimately deployed
This creates an end-to-end audit chain from operational intent to infrastructure modification.
As AI takes on more engineering work, that provenance becomes increasingly important.
Verify What Happened After Deployment
A successful deployment does not prove that the original problem was solved.
Suppose an AI-generated remediation is intended to correct a compliance violation.
The code passes validation.
A reviewer approves it.
The deployment succeeds.
The relevant control should still be evaluated again.
The cloud environment is the ultimate source of truth for whether the desired state was achieved.
The workflow therefore becomes:
Detect → Understand → Propose → Validate → Approve → Deploy → Re-evaluate
If the finding disappears, the organization has evidence that the remediation achieved its objective.
If it remains, the workflow continues.
AI Safety Is an Architectural Property
Organizations sometimes approach AI safety primarily through instructions.
Tell the AI not to modify production without permission.
Tell it not to delete critical resources.
Tell it to follow security best practices.
Good instructions matter, but they are not a sufficient security boundary.
A safer architecture assumes that the AI can misunderstand a request, generate incorrect code, select the wrong tool, or make a bad recommendation.
The surrounding system limits the consequences.
The AI does not have unrestricted production credentials.
It operates inside an isolated environment.
Its repository access is constrained.
Generated code is validated.
Changes are visible.
Approvals are enforced outside the model.
Deployment remains controlled by established systems.
Audit evidence records what occurred.
This is the same principle used throughout security engineering:
Do not rely on perfect behavior when you can enforce boundaries.
How Strato Cloud Approaches AI Infrastructure Changes
Strato Cloud's Intelligent Remediation architecture follows this separation between AI reasoning and production authority.
Continuous Governance or Strato Cloud's compliance capabilities can identify a finding that requires remediation.
The user chooses whether to initiate remediation.
The AI Works Inside an Isolated Execution Environment
Strato Cloud provides the AI with a controlled execution environment where it can work with code and development tools.
The AI can use the context of the finding to generate an Infrastructure as Code solution.
It can run validation and linting tools such as tflint, inspect the results, and iterate on the proposed remediation.
This sandbox isolates the AI's development activity.
It is not a separate cloud environment where Strato automatically deploys a copy of the customer's infrastructure.
Repository Access Is Explicit
The generated remediation can be committed to a GitHub repository that the organization has explicitly authorized for the workflow.
When permitted, Strato Cloud can also create a new repository containing the remediation.
The AI does not need unrestricted access across the organization's source-control environment.
The Output Is a Pull Request
The proposed infrastructure change is delivered through a pull request.
The pull request creates a reviewable artifact containing the change the AI believes will resolve the finding.
The organization's existing review controls can then determine what happens next.
The AI has contributed the investigation, generation, and validation work without becoming the final production authority.
The Organization Deploys Through Its Normal Workflow
After approval, the organization deploys the remediation through its established infrastructure pipeline.
Existing CI/CD controls, environment protections, approvals, and deployment policies remain in place.
Strato Cloud does not need to create an alternative privileged deployment path simply because AI generated the remediation.
Secure Execution Protects AI Operations
When AI needs access to cloud environments or other protected systems, Strato Cloud's Secure Execution model can apply identity, authorization, contextual policy, and temporary credentials to those operations.
The goal is to avoid creating permanently privileged AI identities.
The system can preserve who initiated an operation, what was authorized, and how that authorization was exercised.
This connects AI remediation with the same identity and access principles used for humans and workloads.
Governance Closes the Loop
After the organization deploys the change, the relevant governance or compliance control can evaluate the environment again.
The original finding can then be compared with current cloud state.
This closes the remediation lifecycle:
Finding → User Selects Fix → AI Generates IaC → Validate → Pull Request → Human Review → Normal Deployment → Re-evaluate
AI performs much of the expensive engineering work.
The organization's existing controls remain responsible for deciding what reaches production.
Principles for Safe AI Infrastructure Modification
Organizations designing AI infrastructure systems should consider several principles.
Preserve identity. Know who or what initiated the AI operation.
Authorize before execution. A request should not automatically grant the AI access to the target environment.
Apply least privilege. Give the AI only the capabilities required for the current task.
Prefer temporary access. Avoid permanent privileged AI credentials when short-lived credentials can satisfy the operation.
Isolate AI execution. Give agents controlled environments for code generation and tool use.
Prefer proposals over direct changes. Infrastructure as Code creates an inspectable boundary between AI reasoning and production execution.
Validate automatically. Catch syntax, linting, policy, and security problems before human review.
Constrain repository access. Source control is part of the security boundary.
Make approvals concrete. Humans should review the actual proposed change rather than approving an abstract AI intention.
Reuse existing deployment controls. AI should not create a shortcut around established production workflows.
Preserve provenance. Record the chain from initiating identity through AI activity, code change, approval, and deployment.
Verify outcomes. Re-evaluate the environment after deployment to confirm that the intended result was achieved.
The objective is not to remove AI from infrastructure operations.
It is to make AI useful without requiring organizations to trust it with unlimited authority.
Frequently Asked Questions
Should AI agents have production cloud credentials?
Not necessarily. If the AI's role is to investigate a problem and generate a proposed Infrastructure as Code change, it may not require production write credentials at all.
Can AI safely modify production infrastructure?
AI can participate safely in infrastructure modification when appropriate boundaries exist around identity, authorization, credentials, execution, validation, approval, deployment, and auditability. Direct unrestricted production access creates significantly more risk.
Why use Infrastructure as Code for AI remediation?
Infrastructure as Code makes the proposed change visible, versioned, testable, reviewable, and compatible with existing engineering workflows. It separates generating a change from executing it.
What is a sandbox for an AI agent?
An AI sandbox is an isolated execution environment where the agent can create files, run tools, validate code, and perform development tasks without receiving unrestricted access to other systems. It does not necessarily mean a sandbox copy of the customer's cloud infrastructure.
Should AI-generated Terraform be automatically deployed?
For sensitive infrastructure, organizations should generally preserve existing review and deployment controls. AI can automate generation and validation while a pull request and normal deployment workflow provide additional trust boundaries.
What should be validated in AI-generated Infrastructure as Code?
Validation can include syntax, formatting, linting, security checks, policy evaluation, repository-specific tests, and other automated controls appropriate to the organization's infrastructure workflow.
Why use pull requests for AI-generated changes?
Pull requests create a concrete review point. They allow teams to inspect exactly what the AI proposes, run existing CI controls, enforce branch protection, and preserve a history of the decision.
Can AI remediate problems that are not Infrastructure as Code changes?
Yes. Discrete actions can be represented as governed remediation playbooks or similar workflows. The AI can propose the action while approval and execution remain controlled by the organization's trusted automation.
How does least privilege apply to AI agents?
AI agents should receive only the environments, tools, credentials, repositories, and operations required for the specific task. They should not receive broad permissions simply because future requests might need them.
Why re-evaluate after an AI remediation?
A successful code change or deployment does not prove that the original finding was resolved. Re-evaluating the environment confirms whether the desired security, governance, or compliance state was actually achieved.
