Who is accountable when an AI system changes infrastructure configuration?

Why This Matters for Security Teams

When an AI system can change infrastructure, the accountability problem is no longer just about access. It becomes a question of who approved the system’s operating scope, who owns the control plane, and who is responsible when a change crosses a boundary. NIST’s NIST Cybersecurity Framework 2.0 makes governance and oversight explicit, but AI-driven configuration changes often blur those lines unless ownership is formalised up front.

NHIMG’s The 2026 Infrastructure Identity Survey shows that 70% of organisations already grant AI systems more access than they would give a human in the same role, while 69% say identity management must fundamentally shift for agentic AI. That gap matters because change incidents rarely originate from one obvious mistake; they emerge when access, logging, and approval are treated as separate concerns instead of one accountable operating model. The lesson is not that AI should never touch infrastructure, but that the change path must be owned like any other production control. In practice, many security teams encounter accountability only after an autonomous change has already altered service behaviour, rather than through intentional change governance.

How It Works in Practice

Accountability should be assigned to the programme owner for the AI system, but that role only works if the technical controls map cleanly to the decision path. The owner defines what the system may change, under what conditions, and with what rollback and escalation requirements. The change governance process then enforces that scope through policy, logging, and review. Current guidance suggests treating AI-driven configuration as a controlled workload, not as a human operator with informal exceptions.

Practically, that means separating three layers of responsibility:

• Access authority: who can grant the AI system permission to change infrastructure.
• Execution authority: what the system is allowed to do at runtime, including limits on scope and frequency.
• Outcome authority: who must review, approve, or reverse the change after execution.

This is where agent identity matters. If the AI system uses short-lived credentials, workload identity, and policy evaluation at request time, then the organisation can prove not only that a change occurred, but also why the system was allowed to make it. That approach aligns with emerging agentic guidance in the DeepSeek breach analysis, where identity and control failure were more consequential than the model itself. Mature teams increasingly pair this with external identity and policy patterns from sources such as the NIST Cybersecurity Framework 2.0 and workload-bound automation controls.

Best practice is to require per-change logging, approval thresholds for high-risk systems, and an explicit human owner for rollback decisions. These controls tend to break down when AI agents are allowed to chain tool access across environments because the original approval scope no longer matches the effective blast radius.

Common Variations and Edge Cases

Tighter approval and logging often increases operational overhead, requiring organisations to balance deployment speed against change assurance. That tradeoff becomes especially visible when AI systems manage low-risk, high-frequency configuration tasks such as scaling, tag updates, or routine remediation. In those cases, current guidance suggests a tiered model: low-risk actions may be pre-authorised within policy, while high-risk actions still require explicit human approval.

There is no universal standard for this yet. Some organisations place accountability with the service owner, others with the platform team, and more regulated environments may add a separate approver in the control tower or change advisory function. The important point is that accountability cannot sit with the model alone, because a model cannot own risk acceptance, sanctions, or post-incident review. It also cannot own the evidence chain unless the system architecture preserves immutable logs and decision context.

Edge cases include outsourced operations, multi-agent workflows, and environments where the AI system only proposes changes that another automation layer executes. In those cases, the accountable party is still the human or programme that authorised the end-to-end workflow, not the intermediate tool. NHIMG’s research on The State of Secrets in AppSec reinforces how quickly control fragments when multiple teams manage secrets, access, and remediation separately. The same fragmentation applies to AI change authority, especially in hybrid cloud estates where ownership lines are already weak.

Related resources from NHI Mgmt Group

• Who is accountable when untrusted project configuration changes what an AI assistant sees?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• Why is single-provider AI agent governance not enough for enterprise security?