Can AI Agents Change Infrastructure and Stay Compliant?

The question comes up in every SOC 2 audit prep now: we let an AI coding agent modify Terraform, is that a finding? The short answer is no, provided the change went through the same gate everything else does. The longer answer is about what that gate has to record, because the frameworks care about evidence, and agents change where the evidence comes from.

This post covers what the frameworks actually require, what auditors ask for in practice, and where a Terraform automation platform fits. It builds on the safety architecture in our primer on infrastructure as code with AI coding agents; this is the audit-facing view of the same boundary.

Does SOC 2 Allow AI Agents to Change Infrastructure?

Yes. SOC 2's change-management criterion, CC8.1, requires that the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives" (AICPA Trust Services Criteria, 2022 points of focus). Nothing in that sentence names the author. The criteria are technology-neutral, and an agent-authored change passes or fails on the same evidence a human-authored one does.

Where teams get in trouble isn't the AI part. It's that agents make it easy to skip the ceremony: a change that went from prompt to production without a ticket, a test artifact, or a rollback plan conflicts with CC8.1 whether a person or a model typed it. Identity practitioners at Teleport put it plainly in their February 2026 analysis: an AI system updating production without documented request and approval evidence directly conflicts with change-management expectations. The agent didn't create that gap. It industrialized it.

What Evidence Do Auditors Ask For When an Agent Made the Change?

Across practitioner guidance (Teleport's SOC 2 analysis, Microsoft's Cloud Adoption Framework guidance on agent governance, ISACA's and KPMG's agentic-AI pieces from 2025), four asks recur:

A unique identity per agent. Every action attributable to a distinct non-human identity, registered and linked to an owner. Shared service accounts are the classic finding: a log that attributes fifty changes to "automation" answers no auditor question.

A human approver who isn't the author. Separation of duties survives the transition to agents intact. The person who approves the apply can't be the same identity that authored the change, and "the human who clicked accept" has to be traceable by name.

Tamper-evident logs. Inputs, outputs, and trigger events for agent actions, retained immutably, stored where the agent itself has no write access.

Standard CC8 evidence, unchanged. Documented request, test artifacts, rollback plan. Plus a newer item: change management applied to the agent's own configuration, since a modified system prompt or tool list changes what the agent will do in production.

None of these is exotic. They're the same controls as always, with the new requirement that your platform can distinguish the agent's identity from everyone else's.

What About ISO 42001 and the EU AI Act?

ISO/IEC 42001, published December 2023, is a management-system standard for AI, structured like ISO 27001 but scoped to AI risk. The detail that surprises platform teams: it applies to organizations that use AI systems, not only those that build them. If your platform team runs coding agents against production infrastructure, that use belongs in an AIMS scope, with a documented policy, an impact assessment, and defined human oversight. Adoption is moving from early to expected; major cloud and AI vendors hold certifications, and enterprise procurement questionnaires started asking for it in 2025.

The EU AI Act is less demanding here than most teams fear. An AI coding agent editing Terraform isn't an Annex III high-risk system, and the general-purpose AI obligations that became applicable in August 2025 bind the model provider, not the enterprise using the model. In June 2026 EU legislators approved the Digital Omnibus delay pushing high-risk obligations to December 2027; that change was awaiting Official Journal publication as of July 2026, so re-verify the dates before building a compliance calendar on them.

Where Does the Terraform Platform Fit?

The platform is the enforcement point, because it's where intent becomes infrastructure. The controls above map onto capabilities most Terraform automation platforms already have; what varies is granularity and tier.

Identity. Run the agent as its own service account. In Scalr, service accounts are first-class IAM objects with their own access policies, and OIDC federation exchanges a workload's identity token for a short-lived access token, so agent sessions don't depend on a long-lived secret. HCP Terraform, Spacelift, and env0 offer team tokens or workload identity along similar lines.

Policy on every plan. Encode the non-negotiables (tagging, no public ingress, no IAM wildcards) as OPA policies evaluated server-side against each run. The agent gets deterministic rejection as feedback, and the auditor gets a uniform control across human and agent authors. Our review checklist for AI-generated Terraform covers the human half of that gate.

Approval held by a named human. In Scalr, applying a run is a distinct permission, so approval sits with named people while the agent's service account creates plan-only runs. Watch the auto-apply toggle on any platform: convenience settings that skip the approval step also skip the evidence it generates.

Audit logs, with a tier caveat. Scalr's audit logs stream control-plane events to Datadog or AWS EventBridge and batch to object storage as immutable append-only objects, which is the tamper-evidence auditors want. They're an Enterprise-tier feature as of July 2026, so factor that into platform selection if audit logging is a hard requirement. Run history and plan output are available on every tier; the streaming audit trail is the Enterprise layer. For deeper background, see our guide to Terraform audit logs.

One distinction worth making when evaluating vendors: a platform's terms for its own AI features are not the same thing as governance for your agents. Spacelift, for example, publishes AI-service terms covering data handling for its Saturnhead AI assistant (opt-in, no training on customer data). That's good practice, and it answers a different question than whether the platform can attribute, gate, and log what your coding agents do. Evaluate both separately.

Where Should You Start?

Take one agent that's already making changes and get it a distinct service-account identity this week; identity is the control every other one depends on. Then confirm the approval evidence: pick a recent agent-authored change and check you can produce who approved it, what tests ran, and what the rollback was. If that takes more than a few minutes, the gap is process, not tooling, and it's the same gap an auditor will find. Fix it before the audit does.