AI assistants for infrastructure as code have gained traction quickly, and for sound reasons: provisioning cloud infrastructure by hand is time-intensive, repetitive and prone to inconsistency, and a tool that drafts the Terraform or the pipeline in seconds is a meaningful gain. We see clear value in their adoption. Infrastructure code does, however, carry a distinct profile. When it runs, it creates networks, opens ports, grants permissions and commits spend across the wider estate. The same acceleration that shortens authoring time also shortens the path by which an unreviewed change reaches production. At L&T Vyoma, we believe the productivity gain is best realised when review and approval are designed in before anything is provisioned.
A Category Now Tracked by Analysts
The category is maturing. Gartner has published a Market Guide for AI Assistants for Infrastructure as Code, a clear indication that it has moved beyond early experimentation into a class of tooling enterprises are increasingly expected to evaluate. The direction it describes is instructive: these assistants are moving beyond code completion toward agentic workflows that plan and apply infrastructure changes with less human involvement at each step. That is where the value lies, and it is also where governance matters most. As assistants take on more of the workflow, confidence in what the generated code contains before it is applied becomes correspondingly more important.
For that reason, enterprises are well served by assessing these tools on governance as carefully as on capability. Where agentic assistants are piloted without defined guardrails, the operating model tends to form by default rather than by design, and retrofitting controls later is typically more costly. Treating policy enforcement, approval workflow and audit logging as weighted criteria in any evaluation, alongside productivity, helps keep both considerations in balance from the outset.
Why the 45% Finding Matters
The case for governance rests on published evidence. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 curated coding tasks and found that, when a model could choose between a secure and an insecure way to write something, it chose the insecure option 45% of the time. Applied to infrastructure, the implication becomes clearer: an overly permissive security group, a public storage bucket, a missing encryption setting or a hard-coded secret rarely remains confined to a single service. Infrastructure code is written to be repeated, so a single insecure pattern an assistant favours may be replicated across every environment it touches, at machine speed, ahead of human review. Manual authoring offered an informal safety margin, because its pace allowed errors to be noticed; assistants largely remove that margin, so it is best replaced by design.
Because infrastructure code is built for reuse, a weakness at the level of a single pattern carries consequences at the level of the estate. A permissive default can travel across environments before it is noticed, enlarging both the remediation effort and the compliance exposure. A practical safeguard is a baseline set of policy-as-code rules covering network exposure, storage access, encryption and secrets handling, applied to every generated change before it is merged, with guardrails scoped to each environment and account.
Faster Authoring Calls for Stronger Review
We see the appropriate response not as restriction but as a defined control baseline, consistent with the approach we recommend for any AI that acts on infrastructure. Generated infrastructure code should pass automated policy checks before it is applied, so an insecure pattern is caught consistently by a gate rather than by chance. Changes affecting security posture benefit from a human review step, scoped so the assistant accelerates routine work while a named reviewer approves the changes that matter most. The running estate also benefits from observability, so that what the code actually provisioned is visible and attributable after the fact, rather than reconstructed under incident pressure. Within that framework, an AI assistant for infrastructure as code is a strong accelerator; outside it, the same speed applies equally to configuration errors. In our experience, the platform the code lands on shapes outcomes more than the sophistication of the assistant.
The effort invested in review should also be proportionate to the change: light for routine updates, deliberate for anything that alters security posture. Without that tiering, teams tend to drift toward one of two outcomes, either slowing every change until the productivity case weakens, or approving routinely until the control loses its meaning. Classifying changes by risk, automating approval for low-risk categories and reserving named sign-off for identity, network and data-protection changes help avoid both.
Observability, in our experience, is what turns governance from an intention into evidence. When the deployed state drifts from the approved code without being noticed, root-cause analysis slows and audit evidence has to be assembled after the fact. Continuous drift detection, resources tagged to their originating change, and drift reports reviewed as part of routine operations help keep that record current rather than reconstructed.
|
Dimension |
IaC Assistant, Ad Hoc Controls |
IaC Assistant on a Governed Platform |
|
Policy checks |
Applied inconsistently, at reviewer discretion |
Automated gate before apply |
|
Security changes |
Applied without a defined approval step |
Human review and sign-off |
|
Visibility |
Established retrospectively, after an event |
Observable and attributable by default |
|
Scope of impact |
Can extend across the estate |
Bounded by guardrails |
|
Accountability |
Not clearly assigned |
Owned by a managed operations team |
Where Deferral Carries Risk, and How to Mitigate It
Each control area below carries a specific risk when its governance is deferred, set against the mitigation we recommend.
|
Control area |
Risk if deferred |
Recommended mitigation |
|
Tool evaluation |
Operating model forms by default and is costly to retrofit |
Governance criteria weighted alongside productivity |
|
Policy checks |
Insecure defaults may reach production undetected |
Policy-as-code gate on every generated change |
|
Security changes |
Identity and network changes approved without proportionate scrutiny |
Risk-tiered review with named sign-off |
|
Visibility |
Root cause established slowly, under pressure |
Drift detection and attributable change logs |
|
Scope of impact |
One pattern propagates across environments |
Guardrails scoped per environment and account |
|
Accountability |
Weaker position with auditors and regulators |
Defined owner per change; tested rollback path |
|
Adoption |
Inconsistent controls across teams |
Governed pilot, then staged production rollout |
Ownership When a Generated Change Affects Production
Review reduces risk, but ownership still needs to be clearly defined. When AI-generated infrastructure code contributes to a service disruption or a security event — an exposed endpoint, an over-broad role, a misrouted dependency — the incident review asks who authorised the change and how it gets rolled back, and attributing the change to the assistant is unlikely to satisfy audit, regulatory or customer expectations. In our view, accountability for infrastructure remains with the team that operates the estate rather than with the tool that generated the code. This has practical implications. Every change an assistant proposes should be attributable to a person or a pipeline that approved it, logged so an audit can follow it, and reversible through a tested path. Without that chain, an assistant effectively becomes an unattributed contributor with production access, an arrangement most governance frameworks are designed to avoid.