Who should own governance when AI agents cross identity, access, and application teams?

Why Governance Ownership Matters When Agents Span Teams

AI agents create a governance problem that does not fit neatly inside identity, application, or platform silos. They cross federation, authorization, credential lifecycle, and audit evidence in a single execution path, so ownership has to be explicit. Current guidance suggests treating the control plane as a shared responsibility model, with identity governance and security architecture setting the rules while application and platform teams implement them.

That matters because agentic workloads behave differently from traditional service accounts. They can chain tools, request new permissions mid-task, and expose gaps between systems that a single team would not see on its own. NHI Management Group’s Ultimate Guide to NHIs and the OWASP Agentic AI Top 10 both point to the same operational reality: identity controls fail when no one owns the full lifecycle. In practice, many security teams encounter this only after an agent has already crossed an application boundary that nobody believed was their problem.

How to Split Accountability Without Splitting Control

The cleanest model is to separate governance ownership from implementation accountability. Identity governance and security architecture should define the policy baseline: what the agent may do, which identities it may assume, how approvals work, what evidence is required, and when access must expire. Application teams then wire those controls into the workflow, and platform teams operate the underlying identity and secrets services.

That division works because AI agents need runtime decisions, not only static role assignments. The current best practice is moving toward intent-based authorization, short-lived credentials, and workload identity rather than long-lived static secrets. NHI teams should align this model with the Top 10 NHI Issues, especially where auditability and rotation failures overlap. External guidance from the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework supports the same pattern: define governance centrally, then enforce it at the point where the agent requests action.

• Identity governance owns policy, exceptions, and assurance evidence.
• Security architecture owns control design and cross-domain standards.
• Application teams integrate policy checks, consent flows, and logging.
• Platform teams operate IAM, secrets, federation, and revocation plumbing.

Ownership also needs a named escalation path for disputes. If a control breaks, the question should not be “whose system is this?” but “which owner is accountable for the risk decision and remediation?” These controls tend to break down when agent permissions are embedded in ad hoc application logic because no team can reliably reconstruct the decision trail.

Common Operating Models and Where They Break

Tighter governance often increases coordination overhead, so organisations have to balance speed against control fidelity. There is no universal standard for this yet, especially for multi-agent systems that span business units and cloud platforms. The practical answer is usually a federated model with central policy and local execution, not a single central team doing everything.

One common variation is a security architecture-led council that sets standards, while product or platform owners execute within approved guardrails. Another is a shared service model where identity engineering owns lifecycle automation and application owners own agent-specific permissions. Both can work if they produce consistent audit evidence and fast revocation. For broader context, NHI Management Group’s Lifecycle Processes for Managing NHIs and Regulatory and Audit Perspectives are useful references for defining that split.

The edge cases are usually the hardest. Vendor-managed agents, embedded copilots, and cross-tenant automations often sit outside standard IAM review cycles, which makes ownership ambiguous. The most reliable rule is to assign governance to the team that can approve risk and enforce revocation, even if another team writes the code. That approach works until the organisation treats agent identity as a feature request instead of a security control, because then accountability disappears into delivery pressure.

Related resources from NHI Mgmt Group

• Who should own AI agent governance when identity and access are shared across teams?
• How should security teams govern identity observability across humans, workloads, and AI agents?
• Who should own AI agent identity governance in an enterprise?
• When should security teams treat AI design tooling as an identity governance issue?