How should security teams govern AI transformation across identity and access programmes?

Why This Matters for Security Teams

AI transformation changes identity and access from a mostly human problem into a mixed population problem. Security teams now have to govern models, agents, workflows, service accounts, API keys, and integration points as if each could make or trigger decisions. That means access reviews, approvals, and revocation must cover the full operating chain, not just the user who clicked “deploy.” Guidance from the NIST Cybersecurity Framework 2.0 supports this broader control view, while NHIMG’s Ultimate Guide to NHIs shows why this is overdue: NHIs outnumber human identities by 25x to 50x in modern enterprises, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The practical failure is usually not lack of policy, but that AI initiatives are approved faster than identity governance can keep up.

Security teams should also assume that AI systems will inherit whatever access sprawl already exists. If secrets are embedded in code, reused across tools, or left outside a secrets manager, AI simply accelerates the blast radius. In practice, many security teams encounter AI-related identity failures only after an agent has already touched production data or invoked privileged tooling, rather than through intentional design review.

How It Works in Practice

Governance starts by classifying each AI use case as a governed identity with an owner, purpose, allowed inputs, approved outputs, and explicit downstream actions. That creates a control boundary for IAM, NHI, and lifecycle processes. For example, an internal assistant that summarizes tickets needs different access than an agent that can open incidents, update records, or call DevOps tools. Current best practice is evolving toward treating those permissions as runtime decisions, not static role assignments.

This is where traditional IAM often fails. Static RBAC works poorly when an agent’s behaviour is goal-driven and context-dependent, because the system may chain tools in ways no one predicted during provisioning. Security teams should instead align access with workload identity and short-lived authorisation. In many environments, that means combining OWASP Non-Human Identity Top 10 guidance with the lifecycle practices in Ultimate Guide to NHIs.

• Issue credentials just in time, for one task or one session, and revoke them automatically when the task ends.
• Prefer short-lived tokens, workload identity, and federated trust over long-lived static secrets.
• Evaluate policy at request time using context such as data sensitivity, tool scope, environment, and approver status.
• Log every retrieval, generation, and action path so audit teams can reconstruct what the AI system actually did.

Where possible, security teams should also separate read, write, and execute permissions so an agent can reason over data without being able to modify systems. This aligns with the operational reality described in NHIMG’s Regulatory and Audit Perspectives: governance must be demonstrable, not implied. These controls tend to break down when AI workflows span multiple business units, each with its own approval path and shadow integrations, because no single team sees the full access chain.

Common Variations and Edge Cases

Tighter AI access control often increases delivery friction, so organisations have to balance safety against speed. That tradeoff becomes sharper in environments with shared platforms, third-party agents, or rapid experimentation. There is no universal standard for this yet, but current guidance suggests treating higher-risk actions, such as code deployment, customer data access, or financial workflow execution, as requiring stronger runtime checks than low-risk summarisation or retrieval tasks.

One common edge case is delegated access through OAuth apps and automation platforms. NHIMG’s State of Non-Human Identity Security notes that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes inherited access difficult to review. Another edge case is agent-to-agent communication inside multi-agent systems, where one agent’s approved scope becomes another agent’s implicit privilege. In those cases, security teams should map trust boundaries explicitly and require separate identities for each autonomous function rather than reusing one broad service account.

For AI governance programmes, the practical goal is not perfect centralisation. It is making every AI identity reviewable, every permission explainable, and every privileged action reversible before a breach forces the issue.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern AI access to sensitive data across hybrid environments?
• How should security teams govern workload identity federation across multiple AI APIs?