How can IAM leaders prepare for AI changing security operating models?

Why This Matters for Security Teams

AI is changing IAM because the operating model is no longer just about authenticating people and enforcing static entitlements. As AI assistants, automations, and agentic workflows gain tool access, security teams have to govern dynamic behaviour, short-lived credentials, and machine-to-machine trust paths at the same time. That creates pressure on review cycles, approval flows, and exception handling that were designed for predictable human access patterns. The NIST Cybersecurity Framework 2.0 is useful here because it pushes leaders to treat identity, monitoring, and governance as continuous functions rather than periodic checks.

NHIMG research shows why confidence is slipping: in The State of Non-Human Identity Security, only 1.5 out of 10 organisations said they are highly confident in securing NHIs, while 45% cited lack of credential rotation as the top cause of NHI-related attacks. For IAM leaders, that is a warning that the next operating model cannot rely on long-lived secrets, manual exceptions, or access reviews that lag behind real usage. In practice, many security teams encounter AI-driven overreach only after a tool chain has already been abused, rather than through intentional design of the control plane.

How It Works in Practice

Preparation starts by splitting the identity estate into two lanes: controls for people and controls for workloads, agents, and automations. People still need joiner-mover-leaver governance, but AI-driven systems need workload identity, runtime policy checks, and ephemeral access. That means shifting from “who approved this role” to “what is this agent trying to do right now, with what context, and should it be allowed.” Current guidance suggests that static RBAC alone will not keep pace with goal-driven systems because their execution path changes as they chain tools, call APIs, and react to new prompts.

A practical model includes:

• Workload identity as the primary primitive for agents, using cryptographic proof of what the agent is and what environment it runs in.
• Just-in-time credentials issued per task, with short TTLs and automatic revocation when the task ends.
• Real-time policy evaluation through policy-as-code so authorisation can account for prompt, resource, sensitivity, and risk signals.
• Continuous logging and session tracing so tool use can be reconstructed after an incident.

For implementation depth, teams can look to The State of Secrets in AppSec for why fragmented secrets and slow remediation create operational drag, then map those lessons to AI workflows that should not inherit long-lived keys at all. Emerging standards such as SPIFFE/SPIRE and OIDC-based workload tokens are often used to bind identity to runtime context, while frameworks such as NIST Cybersecurity Framework 2.0 help leaders formalise governance and recovery responsibilities. These controls tend to break down when AI tools are allowed to call legacy systems that only support static service accounts because the workload cannot be cleanly re-authenticated at each step.

Common Variations and Edge Cases

Tighter control over AI and machine identities often increases latency and operational overhead, so organisations have to balance security assurance against delivery speed. Best practice is evolving, and there is no universal standard for this yet, especially for multi-agent orchestration and cross-domain tool use. Some environments will keep limited static credentials for transitional systems, but that should be treated as an exception with compensating controls, not the default operating model.

One common edge case is delegated AI assistance inside business applications, where the agent acts on behalf of a user but also uses its own service identity. That creates a mixed-trust model that should be explicitly logged and approved. Another is third-party AI integrations, where vendors may retain opaque access paths and hidden token lifecycles. NHIMG’s NHI research shows how weak visibility already affects OAuth-connected third parties, which becomes more serious once those integrations can execute actions, not just read data. The right question for IAM leaders is not whether AI will use identities, but whether the control model can still explain and contain that use when behaviour changes faster than review cycles.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• What is MCP in the context of AI security?
• What are the security risks associated with AI agents?
• How should security teams govern machine identity credentials in agentic AI environments?