How should security teams govern AI-assisted infrastructure automation?

Why This Matters for Security Teams

AI-assisted infrastructure automation is not just a productivity feature. Once an assistant can create, modify, or approve infrastructure changes, it becomes an execution-capable workload with access to secrets, APIs, and control planes. That changes the risk model from “bad output” to “privileged action under uncertain intent.” Security teams should treat the assistant like any other NHI: constrained, logged, and governed by explicit policy. The NIST Cybersecurity Framework 2.0 is useful here because it anchors governance, access control, and continuous monitoring as operational duties rather than advisory ideals.

NHIMG research shows why this matters in practice. In the The 2026 Infrastructure Identity Survey, only 44% of organisations had policies to manage AI agents, even though 92% said governance is critical. That gap explains why over-privilege persists: many teams optimise for speed, then discover the assistant was allowed to change identity, network, or secret-state boundaries without a human checkpoint. In practice, many security teams encounter this only after an automated change has already widened access or exposed a credential path, rather than through intentional design.

How It Works in Practice

The safest operating model is to separate generation from execution. The AI can propose Terraform, Kubernetes manifests, firewall rules, or IAM changes, but the workflow should only execute after policy checks, diff review, and human approval for identity or network-impacting actions. This is where intent-based authorisation becomes more practical than static RBAC: the question is not only who the agent is, but what it is trying to do right now, with which data, against which target. That is consistent with the direction described in Top 10 NHI Issues and with the control emphasis in NIST Cybersecurity Framework 2.0.

For implementation, current guidance suggests four practical controls:

• Use workload identity for the automation agent, not shared human service accounts.
• Issue JIT credentials and short-lived secrets per task, then revoke them immediately after completion.
• Bind tool access to policy-as-code so authorization is evaluated at request time, not just at session start.
• Require an auditable approval path for identity, routing, security group, and secret-management changes.

That model reduces the blast radius when the assistant is “confidently wrong,” which is a real failure mode in infrastructure automation. It also makes secret exposure less durable if the workflow is compromised, because the agent never holds standing credentials for long. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for lifecycle thinking, while the DeepSeek breach underscores how quickly exposed secrets and backend credentials can become operational risk. These controls tend to break down when the automation agent is allowed direct console access or persistent cloud keys, because the workflow then bypasses policy gates entirely.

Common Variations and Edge Cases

Tighter governance often increases change latency and review overhead, so organisations have to balance deployment speed against the cost of an unsafe automation path. That tradeoff is real, especially in high-volume platform teams where every change cannot wait for manual sign-off. Best practice is evolving, but there is no universal standard for full autonomy yet, particularly for identity, network, and secrets changes.

One common edge case is low-risk read-only automation. Search, inventory, and drift-detection assistants can often run with narrow permissions and no human approval, provided they cannot mutate state. A different exception is emergency operations. In break-glass scenarios, pre-authorised JIT elevation may be necessary, but it should still be time-bound, fully logged, and subject to post-event review. Another issue is multi-agent pipelines, where one agent drafts, another validates, and a third executes. That architecture can improve separation of duties, but it also creates new trust chains that need explicit policy boundaries. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame those controls for auditability, while NIST Cybersecurity Framework 2.0 remains the practical baseline for mapping governance to accountable operations. For teams modernising fast, the rule is simple: if the assistant can alter trust boundaries, it is no longer just automation, it is a privileged NHI that needs its own control plane.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams manage permissions for AI agents?