Who should own security for agentic systems?

Why This Matters for Security Teams

Agentic systems blur the old boundary between software and operator. Once an AI agent can plan, call tools, retrieve memory, and trigger workflows, security ownership can no longer sit neatly with one team. The real issue is accountability for the full control plane: identity, permissions, prompts, tool access, logs, and change management. Guidance from the NIST AI Risk Management Framework is useful here because it treats governance as a lifecycle obligation, not a one-time approval.

Security teams often misread agentic risk as either an application problem or an AI governance problem. In practice, it is both. If IAM approves broad access but application security owns only the code path, no single team sees how a model prompt, a stale secret, or a permissive tool connector can turn into real-world action. That gap matters because agent behaviour changes when the runtime, retrieval sources, or integrations change, even when the user interface looks unchanged. In practice, many security teams encounter agentic risk only after a privileged action, data exposure, or unsafe tool call has already occurred, rather than through intentional design review.

How It Works in Practice

Practical ownership works best as a named accountable team with shared operational inputs. The accountable group is usually the one that can approve privilege, control release gates, and force re-testing when the agent’s tools, memory, or policy layer changes. That does not mean centralising every task. It means one team must own the decision record, while IAM, PAM, application security, and AI governance each retain clear responsibilities for their slice of the stack. This is consistent with the control emphasis in the OWASP Agentic AI Top 10 and the threat focus in the MITRE ATLAS adversarial AI threat matrix.

A workable operating model usually includes:

• One accountable owner for the agent service, its approval chain, and its risk acceptance.
• IAM ownership of human and service identities, with scoped entitlements and periodic review.
• PAM ownership of elevated actions, just-in-time access, and break-glass workflows.
• Application security ownership of code, APIs, prompt handling, and release testing.
• AI governance ownership of model selection, evaluation, monitoring, and acceptable-use policy.

Teams should also define who can approve tool connectors, who can rotate secrets, who can disable autonomy, and who receives alerts when an agent crosses a risk threshold. The most important practical control is change coupling: any change to model behaviour, retrieval sources, or tool permissions should trigger a security review, not just a product sign-off. Recent industry reporting, including Anthropic’s first AI-orchestrated cyber espionage campaign report, reinforces how quickly agent capability can become an operational security issue when tool use is weakly governed. These controls tend to break down when agents are connected to live production APIs without a formal owner for runtime changes and secret rotation.

Common Variations and Edge Cases

Tighter ownership often increases delivery overhead, requiring organisations to balance faster experimentation against stronger approval and review discipline. That tradeoff is real, especially for teams running many short-lived agents or prototype workflows. There is no universal standard for this yet, but current guidance suggests that the more autonomous the agent, the stronger the ownership model must be.

Edge cases usually appear when a vendor hosts part of the stack, when multiple business units share one agent platform, or when the agent is embedded inside an existing application team. In those environments, responsibility can fragment unless the service owner is explicitly named in policy and in the risk register. The same issue arises with RAG-enabled assistants, where one team owns the model while another owns the knowledge base, and a third owns the downstream workflow. That split is manageable only if there is a single escalation path and a shared control inventory.

For higher-risk use cases, such as systems that can move money, change records, or invoke administrative tools, best practice is evolving toward stricter separation of duties and stronger pre-production evaluation. The CSA MAESTRO agentic AI threat modeling framework is useful for deciding where those boundaries belong. In practice, ownership fails most often in environments where autonomy is added to an existing workflow without revisiting who can approve the agent’s actions, revoke its access, or halt it during incident response.

Related resources from NHI Mgmt Group

• Why do agentic security tools need IAM and PAM controls?
• How should security teams govern RAG and agentic AI differently?
• Who should own identity detection coverage in a mature security programme?
• Who should own risk decisions when security fixes affect service stability?