Ownership should sit with identity and security teams, not with model governance alone, because the operational risk comes from credentials, privilege, and runtime enforcement. The accountable team must be able to see the agent identity, scope its access, and retire it when the workflow changes.
Why This Matters for Security Teams
AI agent governance becomes an identity problem as soon as an agent can authenticate, call tools, or request secrets on its own. That is why ownership belongs with identity and security teams: they already manage credential issuance, privilege boundaries, and runtime enforcement. Model governance can define acceptable behavior, but it cannot retire a compromised token or revoke access when a workflow changes.
This is especially important because agent risk is not static. A single agent may chain APIs, escalate through delegated permissions, and act at machine speed, which makes traditional review cycles too slow. NHI Management Group’s research on the LLMjacking threat shows how quickly exposed credentials can be abused, while the Ultimate Guide to NHIs frames lifecycle control as the core discipline. In practice, many security teams discover agent overreach only after a token has already been reused, not through an intentional governance review.
Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points toward accountable runtime control, not policy documents alone.
How It Works in Practice
In an enterprise identity programme, ownership should be assigned to the team that can issue, constrain, observe, and revoke the agent’s workload identity. That usually means IAM, PAM, or a dedicated identity security function working with platform and model teams. The practical model is not “approve the AI” once, but continuously govern the agent as a non-human identity with a narrow task scope.
Best practice is evolving toward intent-based authorisation, where access is decided at request time using context such as task, risk, environment, and current approval state. Static RBAC alone fails here because agents do not follow fixed human job patterns. A better pattern is to combine workload identity, short-lived secrets, and policy-as-code so the agent proves what it is, receives only what it needs, and loses access when the task ends.
- Use workload identity as the anchor, such as SPIFFE/SPIRE or OIDC-backed service identities.
- Issue JIT credentials per task, with short TTLs and automatic revocation.
- Evaluate policy in real time with controls such as OPA or Cedar.
- Separate model governance from access governance, but keep a shared approval workflow.
- Log every tool call, secret request, and privilege escalation attempt for auditability.
The CSA MAESTRO agentic AI threat modelling framework and OWASP NHI Top 10 both reinforce that identity, privilege, and runtime decisioning are where agent risk becomes operational. These controls tend to break down when the agent is embedded in legacy automation that still depends on long-lived API keys and manual exception handling.
Common Variations and Edge Cases
Tighter governance often increases delivery overhead, requiring organisations to balance speed against the need for revocation, traceability, and least privilege. That tradeoff is real, especially when teams want to prototype agents quickly and treat identity as an implementation detail.
There is no universal standard for this yet, so governance design should match the autonomy level of the agent. For low-risk assistants, security teams may only need scoped service accounts and constrained tool access. For high-autonomy agents that can browse, write, buy, deploy, or trigger downstream workflows, identity ownership must include runtime policy, emergency kill switches, and secret retirement across every integration point.
Edge cases also include multi-agent systems, where one agent can inherit another’s output or delegated access. In those environments, the question is not just who owns the agent, but who owns the chain of trust between agents. NHI Management Group’s 52 NHI Breaches Analysis shows how often weak lifecycle discipline and fragmented ownership turn into audit failures. The emerging consensus is that model teams should own behavior controls, while identity security owns credentials, privilege, and retirement. That split is practical, but it only works if both sides share a single governance record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems need runtime controls, not static approvals. |
| CSA MAESTRO | MAESTRO frames agent risk as identity, privilege, and orchestration. | |
| NIST AI RMF | AI RMF supports accountable governance for autonomous AI behavior. |
Map each agent to runtime policy, then limit tool access by task and revoke it when the task ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
