Published:
Estimated reading time:
8–9 minutes
Finding a cloud problem is increasingly easy.
Cloud providers, security platforms, compliance scanners, observability systems, and governance tools can identify misconfigurations across enormous cloud environments. They can detect publicly exposed storage, unencrypted databases, overly permissive security groups, missing logging, configuration drift, and thousands of other conditions.
Fixing those problems safely is harder.
A remediation system could simply call a cloud API and change the offending resource. That approach is fast, but it introduces a new problem: the remediation system becomes another actor directly modifying production infrastructure.
For many infrastructure changes, there is a safer model.
Generate the remediation as Infrastructure as Code, review it like any other infrastructure change, and deploy it through the organization’s existing engineering workflow.
This turns remediation from an invisible cloud mutation into an explicit, reviewable change.
The Problem With Direct Cloud Remediation
Consider a governance system that discovers a production database without encryption enabled.
The simplest automated workflow might look like this:
Finding → Automation → Cloud API → Production Change
Technically, this can work.
The automation receives credentials, calls the appropriate provider API, and modifies the infrastructure. Once complete, the system marks the finding as resolved.
But several important questions appear immediately.
Who authorized the change? What exactly changed? Was the proposed configuration reviewed? Can the organization reproduce the change later? Does the new configuration match the infrastructure repository? What happens when the next Terraform deployment runs?
Direct remediation solves the immediate configuration problem while potentially creating a new governance problem.
The infrastructure in the cloud and the infrastructure represented in code may no longer agree.
Infrastructure as Code Changes the Remediation Model
Infrastructure as Code gives organizations a declarative representation of infrastructure configuration.
Instead of expressing remediation as:
Change this production resource now.
the remediation system can express:
This is the infrastructure configuration required to resolve the problem.
That distinction matters.
The proposed change can exist independently of the production environment. It can be inspected, validated, reviewed, versioned, approved, and deployed through controlled workflows.
The remediation path becomes:
Finding → Proposed IaC Change → Validation → Pull Request → Review → Deployment → Verification
The infrastructure change is no longer hidden inside an automation system.
It becomes part of the organization’s engineering process.
Remediation Becomes a Proposal Instead of an Action
This is one of the most important properties of IaC-based remediation.
A direct cloud API call combines two decisions:
What should change?
Should that change happen?
Infrastructure as Code separates them.
A remediation system can determine what configuration would resolve a finding and generate the corresponding change without automatically receiving permission to deploy it.
For example, an AI system might determine that a network rule is too permissive and generate a Terraform modification that narrows the allowed CIDR range.
That does not mean the AI should be allowed to apply the Terraform.
The proposed change can first move through validation, source control, policy checks, human review, and the organization’s normal deployment pipeline.
Generation and execution become separate trust decisions.
Pull Requests Create a Natural Control Point
Many engineering organizations already have a mechanism for reviewing infrastructure changes: the pull request.
Developers understand it. Security teams can inspect it. Platform teams can attach automated checks to it. Git records who proposed, reviewed, approved, and merged the change.
Using pull requests for remediation means organizations do not need an entirely separate approval model just because AI or automation generated the fix.
The remediation enters an existing workflow.
A pull request can show exactly which infrastructure files changed and why. Automated checks can run before approval. CODEOWNERS or repository permissions can determine who must review the change. Existing branch protection rules can prevent unauthorized merges.
The organization’s Git workflow becomes part of the remediation security boundary.
Infrastructure Changes Can Be Validated Before Deployment
Direct API remediation often evaluates the change primarily after it has occurred.
IaC allows more validation before production is touched.
Generated Terraform can be formatted and validated. Linters such as tflint can identify errors or questionable configuration. Policy checks can evaluate the proposed infrastructure. CI workflows can run additional organization-specific tests.
These checks do not guarantee that a change is safe.
A syntactically valid Terraform configuration can still represent a bad operational decision. A policy-compliant change can still create an application problem.
But validation can eliminate entire classes of errors before a human reviewer spends time evaluating the proposal.
That is especially important when AI generates the remediation.
AI should be able to iterate on a proposed solution before asking a person to approve it.
IaC Keeps the Repository and the Cloud Aligned
Imagine Terraform manages a production security group.
A remediation platform detects an overly permissive rule and fixes the security group directly through the AWS API.
The cloud is now compliant.
The Terraform repository still contains the old configuration.
During the next deployment, Terraform may attempt to restore the configuration represented in code. The remediation disappears, and the violation returns.
This is configuration drift created by the remediation system itself.
IaC-based remediation addresses the source of desired state rather than only modifying the current state.
If Terraform defines the infrastructure, the remediation should usually modify Terraform.
Once the approved change is deployed, the repository and cloud environment remain aligned.
Version Control Creates Durable Auditability
Cloud audit logs can show that an API operation occurred.
Version control can explain the engineering decision around that operation.
A remediation pull request can preserve the finding that initiated the work, the proposed infrastructure change, automated validation results, reviewer discussion, approvals, and the final merged configuration.
This creates a durable connection between:
problem → proposed solution → decision → deployment
That context becomes useful during security investigations, compliance reviews, incident retrospectives, and future engineering work.
Instead of knowing only that a resource changed, the organization can understand why it changed and how the decision was made.
Existing Deployment Pipelines Should Stay in Control
Organizations have spent years building deployment controls.
Production infrastructure may require protected branches, mandatory reviewers, policy checks, scheduled deployment windows, change-management tickets, automated testing, environment approvals, or other safeguards.
A remediation platform should not require organizations to bypass those controls.
If remediation produces Infrastructure as Code, the organization’s existing deployment system can remain responsible for execution.
The remediation platform proposes.
The organization’s workflow decides.
This allows intelligent remediation to improve the speed of solving infrastructure problems without becoming a second uncontrolled deployment platform.
IaC Reduces the Credentials AI Needs
Credential scope becomes particularly important when AI participates in remediation.
A simple AI remediation architecture might give an agent production cloud credentials and allow it to directly modify infrastructure.
That creates a large trust boundary.
The agent needs enough privilege to perform potentially many different changes across potentially many environments. A reasoning mistake, software vulnerability, compromised dependency, or authorization failure can therefore have direct production consequences.
IaC-based remediation can dramatically reduce that requirement.
The AI may need access to an isolated code-generation environment and an explicitly authorized Git repository, but it does not necessarily need credentials capable of modifying production infrastructure.
The existing deployment pipeline can retain those privileges.
One of the safest production credentials an AI agent can receive is therefore no production credential at all.
Human Review Becomes More Meaningful
“Human in the loop” is frequently proposed as a solution to AI safety.
But human approval is only useful when the person can understand what they are approving.
A prompt asking:
Allow AI to remediate this finding?
provides very little information.
A pull request is different.
The reviewer can inspect the exact infrastructure change. They can see which files are affected, understand the proposed configuration, examine automated validation, discuss alternatives, and reject or modify the solution.
The human is reviewing an artifact rather than approving an abstract AI action.
That makes human oversight substantially more useful.
Infrastructure as Code Also Improves AI Reasoning
IaC is not only useful as an approval mechanism.
It gives AI a structured representation of the infrastructure it is trying to change.
Suppose a governance finding identifies an insecure database configuration. The correct remediation may depend on surrounding modules, variables, provider configuration, naming conventions, environment structure, and dependencies.
An AI system that can work with the organization’s infrastructure repository can reason about the change within that context.
Instead of generating a generic remediation instruction such as:
Enable encryption on the database.
it can propose the specific code change needed in the organization’s infrastructure.
That moves remediation from generic advice toward an actionable engineering artifact.
Remediation Should Be Re-Evaluated After Deployment
Merging a pull request does not prove that the original problem has been solved.
The deployment may fail. The configuration may not produce the expected cloud state. Another control may prevent the change. The remediation itself may have misunderstood the finding.
The governance system should therefore evaluate the environment again after deployment.
The full lifecycle becomes:
Detect → Understand → Generate → Validate → Review → Deploy → Re-evaluate
Only after the environment satisfies the original requirement should the finding be considered resolved.
This closes the loop between governance and remediation.
IaC Should Be the Default, Not an Absolute Rule
Not every cloud remediation belongs in Terraform, CloudFormation, Pulumi, or another Infrastructure as Code system.
Some findings represent operational state rather than desired infrastructure configuration.
Consider a detached cloud volume that has been unused for months.
The correct remediation may simply be to delete it.
Creating Terraform code whose purpose is to delete an unmanaged orphaned resource would be unnatural. There may be no persistent desired-state configuration that needs to change.
Other examples can include clearing obsolete snapshots, rotating certain temporary artifacts, terminating abandoned ephemeral resources, or performing provider-specific cleanup operations.
Trying to force every possible remediation into IaC can make the workflow less clear rather than safer.
The better rule is:
If the remediation changes infrastructure desired state, prefer Infrastructure as Code.
If the remediation represents a discrete operational action, use a controlled action workflow.
Remediation Playbooks Can Handle Discrete Actions
The same principles that make IaC remediation safe can also apply to operational actions.
Organizations can maintain a remediation playbook repository containing approved action definitions.
A playbook might describe how to delete an orphaned volume, revoke an obsolete access grant, remove an abandoned snapshot, or perform another bounded cloud operation.
Instead of allowing an AI agent to execute arbitrary API calls, the AI can propose invoking a specific approved action with explicit parameters.
That proposal can still enter Git as a pull request.
For example:
Finding → Select Approved Playbook → Generate Action Request → Pull Request → Approval → Controlled Pipeline Execution → Re-evaluate
The artifact is different, but the trust model remains familiar.
The remediation is explicit. The proposed action is reviewable. The execution path is controlled. The result is auditable.
This creates a practical complement to IaC rather than weakening the IaC-first model.
AI Makes This Model More Important
Traditional automation usually executes logic developers defined in advance.
AI is different.
An AI system can reason about an unfamiliar finding, inspect surrounding infrastructure code, decide how the problem should be solved, and generate a solution that did not previously exist.
That flexibility is precisely why AI can help address cloud remediation backlogs.
It is also why direct execution deserves more scrutiny.
If software is dynamically deciding what change to make, organizations benefit from inserting a durable, inspectable artifact between AI reasoning and production execution.
Infrastructure as Code provides that artifact for infrastructure changes.
The AI can be creative in developing the solution while the execution path remains deterministic and governed.
How Strato Cloud Approaches IaC-Based Remediation
Strato Cloud’s Intelligent Remediation is designed around the separation between understanding a finding, generating a solution, and executing the resulting infrastructure change.
Continuous Governance can identify a cloud configuration that violates an organizational requirement. The user can then select findings they want to remediate.
AI Works Inside an Isolated Execution Environment
Strato Cloud can provide the AI with an isolated execution environment where it can work with code and development tools.
This environment is not a separate sandbox cloud account where the proposed infrastructure is deployed.
It is a secure code execution environment where the AI can inspect files, generate Infrastructure as Code, run validation tools, and iterate on the proposed solution without directly modifying production infrastructure.
Generated Infrastructure Can Be Validated
The AI can run tools appropriate to the generated infrastructure, including Terraform validation and linters such as tflint.
If validation discovers a problem, the AI can update the proposed code before it reaches the reviewer.
The goal is to deliver a higher-quality remediation proposal rather than making the reviewer identify basic code errors manually.
GitHub Becomes the Delivery Boundary
The resulting remediation can be committed to a GitHub repository that the organization has explicitly authorized for the workflow.
When permitted, a dedicated remediation repository can also be created for the proposed changes.
Strato Cloud can then open a pull request containing the remediation.
The customer retains control over repository permissions, review requirements, approval rules, and the deployment process.
The Customer’s Pipeline Executes the Change
Strato Cloud does not need to replace the customer’s infrastructure deployment process.
Once approved, the change can flow through the organization’s existing CI/CD pipeline and infrastructure tooling.
This keeps production execution inside the controls the organization already trusts.
Governance Closes the Loop
After the infrastructure change reaches the cloud, Continuous Governance can evaluate the environment again.
If the requirement is now satisfied, the finding can be resolved. If the problem remains, the system has evidence that further investigation is required.
This connects detection and remediation into a continuous lifecycle without giving AI unrestricted control of production infrastructure.
The Goal Is Not Faster Changes at Any Cost
Cloud remediation is often framed as a speed problem.
Organizations discover thousands of findings and do not have enough engineering capacity to resolve them quickly. AI can help reduce that backlog by understanding findings and generating solutions much faster than teams can manually investigate every issue.
But faster remediation is only valuable if the solution does not weaken the controls around infrastructure changes.
Infrastructure as Code provides a useful boundary.
AI can reason dynamically. It can generate solutions. It can validate code. It can prepare a complete remediation proposal.
The organization’s established systems still determine whether that proposal becomes reality.
For infrastructure changes, that combination may be the safest way to turn intelligent cloud remediation from an interesting AI capability into something enterprises can actually trust.
Frequently Asked Questions
Why use Infrastructure as Code for cloud remediation?
Infrastructure as Code makes remediation reviewable, version controlled, testable, auditable, and compatible with existing engineering workflows. It also helps keep the cloud environment aligned with the repository representing desired infrastructure state.
Why not let AI directly fix cloud resources?
Direct AI remediation can require broad production privileges and can bypass existing review and deployment controls. Generating IaC separates the AI’s proposed solution from the decision to execute it.
Can AI-generated Terraform be trusted?
AI-generated Terraform should be treated like other proposed infrastructure code. It should be validated, reviewed, approved, and deployed through controlled workflows rather than assumed to be correct because AI generated it.
Does IaC prevent configuration drift?
IaC can reduce drift when the repository is treated as the source of desired state. Directly changing cloud resources outside that workflow can create drift between the repository and the actual environment.
Should every cloud remediation use Infrastructure as Code?
No. IaC is most appropriate when remediation changes persistent infrastructure desired state. Discrete operational actions, such as deleting an unmanaged orphaned resource, may be better handled through controlled remediation playbooks.
What is a remediation playbook?
A remediation playbook defines a bounded operational action that can be executed through a controlled workflow. It can specify the action, required parameters, permissions, validation, approval process, and execution mechanism.
Why use pull requests for AI remediation?
Pull requests create an inspectable artifact and fit existing engineering controls. Teams can review the exact proposed change, run automated checks, enforce repository permissions, require approvals, and preserve a durable history of the remediation decision.
Does IaC-based remediation require AI to have production credentials?
Not necessarily. AI can generate and validate code and deliver it to an authorized repository while the organization’s existing deployment pipeline retains the credentials required to modify production infrastructure.
What happens after the remediation is deployed?
The environment should be evaluated again against the original governance requirement. Successful deployment alone does not prove that the finding was resolved.
