Who should own governance when identity programmes span people, machines, and AI agents?

Why This Matters for Security Teams

When identity programmes span employees, service accounts, workloads, and AI agents, the failure mode is rarely technical first. It is organisational: no one team owns the full lifecycle, so approvals, policy exceptions, and revocations drift between IAM, PAM, cloud, and SecOps. That gap is especially dangerous for machine and agent identities because access is often API-driven, ephemeral, and hard to reconstruct after the fact.

NHI Management Group’s research on The 2024 ESG Report: Managing Non-Human Identities shows how widespread the problem has become, while the NIST Cybersecurity Framework 2.0 reinforces that governance needs clear ownership, not just control coverage. For AI agents, the issue is even sharper because autonomy changes access patterns after deployment. Guidance from OWASP Agentic AI Top 10 and current NIST AI risk guidance both point toward runtime accountability, not static entitlement review alone.

In practice, many security teams encounter identity sprawl only after an audit failure, a privileged token leak, or an agent has already acted outside scope.

How It Works in Practice

The ownership model should be single-threaded at the governance layer, even if operations are distributed. A central identity governance authority defines policy for all identity classes, while domain teams execute the controls they are best suited to manage. Human identities may follow HR-driven joiner, mover, leaver flows. Service accounts may be governed through workload identity standards. AI agents need task-scoped approval, context-aware authorization, and short-lived credentials.

This is where a single governance model prevents the common split between “human IAM” and “everything else.” The governance owner sets baseline rules for lifecycle, attestation, risk acceptance, and exception handling. IAM can enforce identity proofing and access requests, PAM can control elevation, cloud teams can enforce workload bindings, and SecOps can monitor anomalous use. But the decision rights should remain unified so revocation, review, and incident response do not depend on which team noticed the issue first.

For agents, current best practice is evolving toward workload identity and policy evaluated at request time. That means using cryptographic identity for the workload, runtime policy engines, and just-in-time credentials rather than durable secrets. NHI Management Group’s Ultimate Guide to NHIs and its section on lifecycle processes for managing NHIs are useful references for aligning ownership to provisioning, rotation, and decommissioning. External guidance such as the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both support this shift toward traceable accountability and runtime controls.

• Define one governance owner for all identity classes.
• Map execution responsibilities by domain, not by accountability.
• Require task-level approval for AI agents and privileged automation.
• Use short-lived credentials and automated revocation for non-human identities.
• Make exception handling and incident review part of the same governance workflow.

These controls tend to break down in fast-moving platform environments where teams can mint identities directly in cloud services without passing through a shared governance workflow.

Common Variations and Edge Cases

Tighter central governance often increases coordination overhead, so organisations have to balance speed against assurance. That tradeoff is real in cloud-native and M&A environments, where identity platforms may be fragmented and teams are already operating with different toolchains.

There is no universal standard for exactly how much should be centralised versus federated. Current guidance suggests central ownership should govern policy, risk acceptance, and lifecycle standards, while delegated teams handle enforcement and local operations. A mature model may allow product teams to provision service accounts, but only if those accounts are bound to centrally defined policy, expiry, and review requirements.

AI agents create the hardest edge case because they can change behaviour after deployment. If a governance model treats them like static service accounts, it will miss task chaining, tool escalation, and data access drift. That is why NHI Management Group’s OWASP Agentic Applications Top 10 and regulatory and audit perspectives matter here: they show why ownership must support evidence, traceability, and fast revocation, not just access approval. The right answer is not separate governance silos for people, machines, and agents. It is one accountable model with different control patterns underneath it.

Related resources from NHI Mgmt Group

• How do data governance and identity governance intersect in AI programmes?
• How should organizations approach the governance of AI agents?
• Who should own governance when AI agents cross identity, access, and application teams?
• Why do silent data changes create governance risk for identity and security programmes?