Configuration drift is not a new problem. Sysadmins have been fighting it for decades. But AI agents introduce a new variant that's harder to catch: high-frequency, low-visibility incremental drift.
A human engineer making a config change is a relatively rare event. It leaves a memory, a Slack message, maybe a ticket. An AI agent making a config change is nearly invisible — it's part of a larger automated task, logged somewhere in a run history that nobody reads unless something breaks.
What drift looks like in practice
Here's a realistic scenario. You have a coding agent that helps with deployments. Over three weeks, it:
- Adds
DEBUG=trueto an env file "temporarily" to diagnose an issue - Increases a database connection pool size to fix a timeout
- Adds an exception to a firewall rule to let a webhook through
- Modifies a cron job schedule to run a data migration task
- Creates a new API key in a third-party service for a test it was running
- Disables a TLS verification flag to unblock a deployment
Each of these was approved in context. Each seemed reasonable at the time. None of them were ever reversed. And now you have a production system in a state that doesn't match your documentation, your IaC repo, or your security baseline.
Why agents make this worse
Human engineers make config changes too — but the cognitive overhead of doing so acts as a natural rate limiter. Agents don't have that overhead. They can make dozens of config changes per hour as side effects of other tasks.
There are three specific properties of AI agents that amplify drift:
1. Agents optimize locally. An agent solving a problem right now will take the path of least resistance. If disabling a check unblocks the task, it will disable the check. It's not thinking about your security posture in three months.
2. Agents lack cleanup instincts. Humans usually know when a change is temporary and have some vague intention to revert it. Agents don't carry that intent forward across sessions. A "temporary" debug flag stays forever.
3. Agent changes are hard to attribute. When you're reviewing your git history or audit logs, an agent's change looks like any other automated change. It often doesn't have a clear business justification attached to it — just "agent run #4471 modified nginx.conf".
The security consequences
Drift isn't just an ops problem. Specific categories of drift have direct security implications:
| Type of drift | Security consequence |
|---|---|
| Debug flags left enabled | Verbose error output, internal stack traces exposed to users |
| Firewall rule exceptions | Expanded attack surface; rules intended as temporary become permanent |
| TLS verification disabled | MITM exposure on internal service-to-service calls |
| Orphaned API keys | Unrevoked credentials that agents created and nobody knows about |
| Connection limit increases | Changed resource bounds create DoS exposure or mask performance regressions |
| Modified cron schedules | Security jobs (rotation, cleanup, audit) run at unexpected times or not at all |
The detection problem
Standard drift detection tools (Terraform plan, AWS Config, CSPM scanners) compare your infrastructure against a declared desired state. They work well when humans maintain that desired state.
The problem with agents: they often update the desired state too.
An agent that modifies a Terraform file and then runs terraform apply has effectively
moved the goalposts. Your drift detection tool now thinks the new state is correct.
This creates a gap: you can detect unauthorized drift (things that changed without going through IaC), but you can't easily detect authorized drift that shouldn't have happened.
Command authorization as a drift control
The most reliable lever you have is requiring human approval before any write to configuration. Not just infrastructure-as-code changes — all config writes, at the shell layer.
This means the agent can still do its work, but every sed -i, every
echo "..." >> .env, every crontab -e goes through a human checkpoint.
The human sees the command in context and can approve or deny it.
The key properties of this approach:
- Captures intent: the approval captures not just the change but why it was made (the agent's stated reason)
- Forces reversibility thinking: reviewers naturally ask "is this temporary?" and can annotate accordingly
- Creates an attributable audit trail: you know exactly which agent made which change and who approved it
- Doesn't slow down non-config work: whitelist read-only commands; only writes get reviewed
Complementary controls
Command authorization is necessary but not sufficient on its own. A few things that work alongside it:
Ephemeral agent sessions. Agents that start with a fresh environment each run can't accumulate cross-session context about previous workarounds they've applied. Each session starts from declared state.
Automated reconciliation. Periodic jobs that compare running state against your IaC and flag divergence. Even if an agent changed the IaC, you can catch cases where the runtime doesn't match.
Change expiry. Approve a config change with a TTL. After the TTL expires, the change is flagged for review — either it gets re-approved or it gets reverted. Forces explicit decisions about what was "temporary" vs. permanent.
Agent scope limits. Agents that can only write to specific directories or modify specific config files have a bounded drift surface. If a coding agent can't touch firewall rules, it can't drift firewall rules — regardless of what it decides is the optimal path.
Practical baseline
If you're running agents in production today and want to reduce drift risk without a large tooling investment:
- Require approval for any write to config files. Whitelist files or patterns that agents should read freely; flag writes on everything else.
- Audit orphaned credentials quarterly. Any API key or secret created by an agent run that isn't referenced in your IaC is a candidate for revocation.
- Run
terraform plan(or equivalent) on a schedule. Even if agents can update IaC, periodic plans surface unexpected delta between declared and actual state. - Log agent session scope at session start. What files, what services, what credentials did this agent have access to? You need this for post-incident reconstruction.
- Review agent-authored IaC changes with extra scrutiny. Same code review process as human changes, but specifically looking for workarounds, disabled checks, and unexplained resource increases.
The honest assessment
No single control eliminates configuration drift from AI agents. The nature of autonomous systems is that they'll find paths you haven't anticipated.
What you're aiming for is drift that's detectable and attributable. Drift you can find, drift you can explain, drift you can reverse. That's a realistic goal. "Zero drift" is not.
The teams that manage this best treat agent-authored changes with the same skepticism they'd apply to any automated system —
not trusted by default, verified against declared intent, subject to expiry.
The same instincts that make you question a shell script that writes to /etc should apply when an agent does it.
Expacti adds a command authorization layer between your AI agents and your infrastructure. Every write command gets a human checkpoint before execution — with full context, not just a raw command string. See how it works.