A drift report tells you a security group ingress rule appeared that is not in your Terraform. Useful. What you actually want to know is what changed, whether it matters, and what to type next. That last part is where language models are genuinely helpful and also where they are most dangerous, because a confident wrong command against production infrastructure is worse than no suggestion at all.

This page is about the constraints that make the feature safe rather than about the model.

The gap between detection and action

Drift detection produces a fact: this resource differs from your configuration, in this attribute. Acting on it needs three things the fact does not contain.

  • What it means. An ingress rule added to a security group could be a debugging shortcut somebody left behind or a deliberate change nobody codified. The report cannot tell them apart.
  • Whether it is urgent. A tag difference and an open port are not the same class of problem, and severity is not derivable from the attribute name.
  • What to do. Either bring the account back to the code, or bring the code up to the account. Those are opposite actions and choosing between them is a judgement about intent.

Some drift items make this harder still. Live drift detected from account events has no before and after values by design: the event says a change happened, not what the previous state was. Any advice about those items has to work from what the event and the current state actually contain, and must not narrate a "previous value" that was never observed.

Every suggested command is read-only

This is the constraint that matters most, and the reasoning is worth spelling out because the obvious implementation is wrong.

The obvious approach is a denylist: refuse commands containing delete, terminate, remove and so on. A mutating-verb denylist fails open. It has to enumerate every dangerous verb across every AWS service, and it will always be incomplete. aws s3 rm does not contain any of those words. Global flags and alternate invocation forms give further ways around it. A filter that fails open on the cases you did not think of is not a safety control; it is the appearance of one.

The inverse is what works. Commands are validated against a real AWS service model, checking that the service and operation exist and that the operation is one that reads. Anything that does not validate does not ship. If the model produces something unrecognised, the system retries with corrective feedback, and if it still cannot be verified the output is marked as unverified by InfraSync rather than presented as checked.

The verification flag is set by InfraSync and never by the model. A model asked to self-report whether its own output is safe will sometimes say yes. The whole point of a check is that it is performed by something other than the thing being checked.

So the advice tells you how to investigate. It describes what to look at, gives you the read command to look at it with, and leaves the change to you.

Why there is no automatic revert

An automatic revert is the feature everyone asks for and it should not exist in this form. Reverting drift by issuing AWS CLI commands means a tool making unreviewed changes to production based on a model's inference about intent, with no plan, no diff and no approval step. If the inference is wrong the damage is done before anyone sees it.

The right shape for automated correction is a Terraform plan and a pull request, which is the same argument as not pushing generated code straight to main. The change becomes reviewable, diffable and revertible, and it goes through the process your team already trusts.

Accepting drift, and the trap inside it

Sometimes the account is right and the code is stale. Somebody made a deliberate change and did not codify it, and the correct resolution is to update the Terraform rather than undo the change.

There is a specific trap here worth knowing about whether or not you use a tool for it.

For drift where a resource exists in the account but not in your configuration, the resolution is an import: write the configuration and bring the resource under management. That needs the resource's actual attribute values.

For drift where a resource exists in your configuration but not in the account, the resolution is a deletion from the configuration. That needs no values at all, because you are removing a block rather than describing a thing.

A system that reads live values before proposing a resolution has to know which case it is in. Applying a read-values step to the second case means going to look for a resource that is not there, and getting nothing back, which then looks like a failure of the analysis rather than the expected answer. The distinction has to be explicit in the code, and it is easy to miss because both are called "drift".

What it cannot do

Four honest limits.

It does not read your Terraform. The analysis compares an approved baseline against the account. It does not parse your repository, so it cannot tell you which file or module a change belongs in.

It cannot infer intent. Nothing in an API record distinguishes a deliberate emergency fix from a mistake. The advice describes what changed and what it affects; whether it should stay is yours.

It is rate limited. Ten insight requests per minute per user. Generation is not free and unbounded generation is a cost bug rather than a feature.

Large attributes are truncated in the prompt. Some imported attributes are multi-kilobyte JSON, such as IAM policy documents or Batch compute environments. Those are capped before being sent, so advice about a very large attribute may be working from a partial view. Better a bounded prompt than a request that fails or costs unpredictably, but it is a limit worth knowing.

Results are cached per drift item, so re-opening one does not regenerate it. That keeps the advice stable, which matters more than it sounds: advice that changes wording every time you look at it is advice nobody trusts.

Frequently asked questions

Can AI automatically fix Terraform drift?

It should not do so by issuing commands against your account. That means a tool making unreviewed production changes based on an inference about intent, with no plan, no diff and no approval. The right shape for automated correction is a Terraform plan and a pull request, so the change is reviewable and revertible through the process your team already trusts.

How do you stop an AI from suggesting a destructive AWS command?

By validating against a real AWS service model rather than filtering for dangerous words. A mutating-verb denylist fails open: it must enumerate every dangerous verb across every service and will always be incomplete, and aws s3 rm contains none of the obvious words. Validating that the operation exists and is a read operation refuses everything that does not affirmatively check out.

Does the model decide whether its own command is safe?

No. The verification flag is set by InfraSync, never by the model. A model asked to self-report on its own output will sometimes say yes when it should not, and the point of a check is that something other than the thing being checked performs it. Output that cannot be verified after a corrective retry is marked unverified rather than presented as checked.

Why do some drift items have no before and after values?

Because live drift detected from account events is event-sourced by design. The event records that a change happened, not what the state was beforehand. Advice on those items has to work from the event and the current state, and must not narrate a previous value that was never observed.

What is the difference between reverting drift and accepting it?

Reverting brings the account back to the code. Accepting brings the code up to the account, for a deliberate change that was never codified. They need different information: accepting a resource that exists in the account but not in configuration requires reading its live attribute values to write an import, while removing a resource that exists in configuration but not in the account requires no values at all.

Can the AI see my Terraform code?

No. The analysis compares an approved baseline against the AWS account and does not parse your repository, so it cannot tell you which file or module a change belongs in. It also cannot infer intent, because nothing in an API record distinguishes a deliberate emergency fix from a mistake.