AI Coding Agents
Infrastructure
Configuration drift repair with coding agents
September 24, 2026 - 2 minute read
Configuration drift repair with coding agents begins by comparing an approved baseline with observed state. Drift appears when cloud resources, deployment settings, policy files, or service configuration change outside the expected delivery path. An agent can trace the difference and prepare a patch, but it needs a trusted declaration of the intended state.
NIST’s security-focused configuration management guidance treats baseline configuration, change control, and monitoring as connected practices. That distinction matters because a difference is evidence, not automatic permission to overwrite a running system.
Establish the configuration drift baseline
Identify which source is authoritative for each setting. Infrastructure as code may define a resource, while a deployment system supplies secrets and an organization policy enforces constraints. Document the precedence rather than asking the agent to infer it from timestamps.
Collect drift output in a read-only step. Preserve the provider, account, region, resource identifier, tool version, and time of observation. Remove secrets and user data before sending logs into an agent workflow. If the tool supports a machine-readable plan, retain it as the review artifact.
Classify differences before remediation. Some are unauthorized changes, some are emergency changes awaiting codification, and some are expected values generated by the provider. Suppress only well-understood computed fields. A broad ignore rule can hide the next meaningful change.
Repair configuration drift through code
Choose whether the declared configuration or the running state should change. If the live change is approved, update the repository so future deployments preserve it. If the declaration remains correct, prepare a reviewed deployment that restores the baseline.
Keep the patch limited to the affected resources. Factory’s automated code review can inspect a pull request using repository-specific guidance, including rules for sensitive infrastructure paths. Deterministic policy checks and the infrastructure planner should remain the required evidence.
Do not let the repair task apply changes to production as part of diagnosis. Separate observation, code generation, review, and deployment. This boundary gives infrastructure owners a clear plan to approve and preserves the existing release process.
For repeated drift across repositories, Factory Automations can run a scheduled read-only check and create a report. Configure the workflow to deduplicate findings and stop when credentials, provider access, or the baseline is uncertain.
Validate configuration drift repair
Re-run formatting, validation, policy checks, and the infrastructure plan after the patch. The new plan should contain only the intended changes. Review replacements, deletions, network exposure, identity permissions, data retention, and regional placement explicitly because a small source diff can have a broad effect.
After an authorized deployment, run the drift detector again and attach its result to the change record. A clean result supports closure. Persistent differences may indicate provider defaults, another management system, or a resource that cannot converge under the current declaration.
Finish by addressing the path that allowed drift. Tighten direct-change permissions, improve import procedures, document emergency changes, or add scheduled detection as appropriate. The lasting result is a reliable reconciliation process, not merely an empty plan on one day.
