How can security teams reduce risk as AI becomes more common in IT operations?

Why This Matters for Security Teams

As AI moves into IT operations, the risk is less about a single model failure and more about AI acting inside real workflows with real permissions. When an agent can read tickets, call APIs, and trigger changes, traditional review points can be bypassed or compressed. That is why governance has to focus on accountability, authorization boundaries, and evidence of control rather than on the AI label itself.

The practical problem is that many teams still manage AI as if it were a passive tool, while the operating model is closer to an autonomous workload with delegated action. NHI Management Group has documented how weak visibility and over-privilege remain common in practice, including the finding that only 1.5 out of 10 organisations are highly confident in securing NHIs in The State of Non-Human Identity Security. That confidence gap matters even more when AI starts using the same identities, tokens, and service accounts that already power operations.

Security teams should treat this as a control design issue, not a model quality issue. The right question is whether an AI-enabled workflow can be constrained, observed, and rolled back before it touches production systems. In practice, many security teams encounter excessive AI-driven access only after a bad change, a leaked token, or an unexplained automation path has already occurred, rather than through intentional governance.

How It Works in Practice

The safest pattern is to treat AI-enabled IT operations as a governed workload with explicit decision points. Start by mapping where the AI can observe, decide, and act, then separate those stages so the system does not inherit broad standing access. Current guidance suggests using least privilege, short-lived access, and logged approval points as the default baseline, aligned to the NIST Cybersecurity Framework 2.0.

For autonomous or semi-autonomous agents, the identity problem changes. A human operator may follow predictable patterns, but an AI assistant can chain tools, repeat actions quickly, and pivot in ways that are not easy to pre-authorize. That is why NHI Management Group emphasises workload-focused control design in resources such as OWASP NHI Top 10 and Top 10 NHI Issues.

• Use just-in-time access for each task, not long-lived credentials that persist across workflows.
• Bind the AI workload to a distinct identity so the system can prove what it is, not just what token it holds.
• Evaluate policy at request time, not only at onboarding, so context changes can block risky actions.
• Require a human or ticket-based approval step for destructive actions, especially in production.
• Log prompts, tool calls, and outbound API actions together so investigations can reconstruct the full chain.

These controls tend to break down in legacy environments where automation shares one service account across many jobs, because there is no clean way to scope, revoke, or attribute AI actions.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, so organisations have to balance speed against the cost of review, logging, and identity lifecycle management. That tradeoff becomes sharper when IT teams want AI to reduce ticket queues or automate remediation. Best practice is evolving, but there is no universal standard yet for how much autonomy an AI system should have before it needs explicit guardrails.

One common edge case is read-only AI assistance. Even when a model cannot make changes directly, it may still expose sensitive data, summarize secrets, or recommend actions that trigger unsafe human follow-through. Another is third-party tooling, where the AI depends on vendor integrations and OAuth grants that are difficult to inventory. In those cases, visibility matters as much as access control, which is why NHI security research has placed so much emphasis on the gap between assumed and actual oversight.

If the AI is connected to incident response, patching, or privileged admin tools, the risk profile changes again. The team should decide in advance what actions are always blocked, what actions require step-up approval, and what actions must be routed to a human operator. For organisations still building this program, the Ultimate Guide to NHIs — Why NHI Security Matters Now provides useful context on why standing privileges and weak lifecycle controls become dangerous once AI is in the loop.

Related resources from NHI Mgmt Group

• How should security teams use DSPM to reduce oversharing risk in AI-enabled environments?
• How should security teams reduce open access risk in data governance programmes?
• How should security teams use data classification to reduce access risk?
• How should security teams reduce Domain Admin risk in environments with PAM and auditing tools?