Who should own AI agent governance in the identity stack?

Why This Matters for Security Teams

AI agent governance cannot be assigned cleanly to a single operational silo because the control surface is split across identity, secrets, policy, logging, and platform integration. Security and identity teams own the guardrails; application teams own the agent’s behavior; platform teams own the runtime. That division is only workable if one control plane ties them together. Without it, ownership gaps show up as overbroad access, weak revocation, and no reliable audit trail.

This is why current guidance from NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 keeps emphasizing governance, accountability, and runtime controls rather than static ownership labels. NHIMG research on the AI Agents: The New Attack Surface report found that 92% of organisations view governing AI agents as critical, yet only 44% have implemented policies, which is a classic sign that ownership is not translating into control. In practice, many security teams encounter agent misuse only after an access review or incident response case, rather than through intentional governance design.

How It Works in Practice

The practical answer is shared accountability with a named control owner, usually in security or identity, and named engineering owners for implementation. The identity team should define the lifecycle for every agent credential, token, certificate, and workload identity. The security team should define policy, audit requirements, exception handling, and revocation standards. Engineering teams then consume those controls through automation rather than negotiating access manually.

For autonomous systems, static RBAC is rarely enough on its own because an agent’s legitimate actions can change from task to task. Current practice is moving toward runtime authorization, where the decision is based on what the agent is trying to do, what data it is touching, and what context is present at the moment of request. That is the direction reflected in the CSA MAESTRO agentic AI threat modelling framework and in NHIMG’s OWASP Agentic Applications Top 10 analysis.

• Use workload identity as the primary primitive for the agent, not a shared human-style account.
• Issue short-lived, task-scoped credentials through JIT provisioning and revoke them automatically when the task ends.
• Evaluate policy at request time using policy-as-code so access changes with context, not with quarterly reviews.
• Centralize logging so identity, tool invocation, and data access can be reconstructed after the fact.

That model works best when the control plane can integrate with the agent runtime, the secrets manager, and the approval workflow without manual handoffs. These controls tend to break down when teams let agents inherit long-lived service accounts from legacy automation because the runtime becomes too dynamic for pre-defined entitlements.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance fast agent delivery against tighter lifecycle control and auditability. There is no universal standard for ownership in agentic environments yet, so some organisations place the primary control owner in IAM, while others place it in security architecture or platform security. The deciding factor is usually who can enforce revocation and policy without depending on application release cycles.

One common edge case is experimentation environments. Teams often accept broader access there, but those exemptions must be explicit, time-boxed, and visible to security. Another edge case is multi-agent workflows, where one agent hands off to another and inherited trust becomes the real risk. In those cases, governance should track both the originating identity and the delegated action chain. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for translating that lifecycle thinking into operational controls.

Where agentic systems touch regulated data or high-impact decisions, align ownership with NIST AI Risk Management Framework governance and the regulatory and audit perspective from NHIMG. The practical rule is simple: if no one can approve, monitor, and revoke the agent in one motion, ownership is not actually defined.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own AI agent governance when identity and access are shared across teams?
• Who should own AI agent identity governance in an enterprise?
• Who should own AI agent governance in an enterprise identity programme?