Who should own AI identity governance in an organisation?

Why This Matters for Security Teams

AI identity governance fails when organisations treat it as a narrow IAM ticket instead of an operational ownership problem. Autonomous systems create access, act on data, and trigger side effects faster than traditional approval chains can keep up. That means the real risk is not just who can log in, but who can authorise, monitor, rotate, and revoke machine access across the full lifecycle.

Current guidance suggests that ownership must extend beyond the AI project team. Central identity and security teams should define standards, but platform, architecture, and system owners need to carry those controls into deployment. That division of labour matters because AI identities often outnumber human identities and are more likely to be overprivileged, as shown in Ultimate Guide to NHIs. NIST also frames identity, access, and accountability as core governance concerns in NIST Cybersecurity Framework 2.0.

One useful signal from The 2026 Infrastructure Identity Survey is that 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite. In practice, many security teams encounter governance failure only after an AI system has already been granted broad access and no one can explain who approved it.

How It Works in Practice

Ownership should be assigned by control domain, not by project enthusiasm. IAM or identity engineering should own standards for authentication, credential issuance, secret rotation, and revocation. Security architecture should define policy boundaries, logging requirements, and exception handling. Data governance should decide what classes of data an AI identity may access, while platform and application owners must implement those controls in the runtime environment.

For AI and agentic systems, this model works best when ownership is explicit at each stage of the identity lifecycle. That includes onboarding, environment binding, secret injection, JIT access, policy checks, session monitoring, and offboarding. NHIMG research on Lifecycle Processes for Managing NHIs shows why lifecycle discipline matters: without revocation and rotation, machine identities accumulate standing access and become durable attack paths.

• Central identity teams define the control baseline: TTL, rotation, approval, and audit requirements.
• Platform teams enforce those requirements in CI/CD, runtime platforms, and orchestration layers.
• Security teams validate logs, exceptions, and segregation of duties.
• System owners remain accountable for the business risk created by the AI workload.

For governance, NIST’s AI risk guidance and security control thinking are helpful starting points, especially NIST Cyber AI Profile (IR 8596). It is best practice to make the owner of the workload responsible for proving that the AI identity only has the access needed for the current task. These controls tend to break down when platform teams run AI infrastructure as a shared service but no one is designated to approve or revoke the identities used inside that service.

Common Variations and Edge Cases

Tighter ownership often increases operational overhead, requiring organisations to balance control clarity against deployment speed. That tradeoff becomes sharper when AI systems are embedded in product teams, data science environments, or cloud-native platforms where identity is created automatically and disappears just as quickly.

There is no universal standard for who should approve every AI identity decision. Current guidance suggests a federated model is more workable: central teams set policy, while platform and workload owners execute it. In high-change environments, that may mean policy-as-code, delegated approvals, and automated evidence collection rather than manual sign-off for every secret or token.

Some teams also separate ownership by risk level. Low-risk internal copilots may sit under a platform owner, while higher-risk autonomous agents require joint oversight from security architecture, IAM, and data governance. NHIMG’s Top 10 NHI Issues research highlights why this matters: excessive privilege, weak rotation, and poor visibility are recurring failure modes, not edge cases. The most common mistake is assigning governance to the team that built the AI rather than the team that can actually enforce identity controls after launch.

Related resources from NHI Mgmt Group

• Why do AI helpdesks and security tools increase identity governance risk?
• Who should be accountable for AI identity governance?
• Who should own identity and device governance in a consolidated work platform?
• Who should own privileged access governance in an identity programme?