How should organisations assign ownership for agentic AI security across identity, interaction, and behaviour layers?

A practical ownership model starts by assigning the layer to the team that controls it. IAM owns identity, AppSec owns interaction, and the behaviour layer needs a named security owner plus platform support for sensors and cluster access. The key is to separate detection, enforcement, and infrastructure operations so every layer has someone who can page, change controls, and sign evidence.

How ownership should be split across the three agentic AI security layers

Assign ownership by control plane, not by the label “AI security.” The identity layer belongs with IAM because it governs who or what can act; the interaction layer belongs with AppSec because it governs inputs, outputs, prompts, and tool-facing interfaces; the behaviour layer needs an accountable security owner who can coordinate detection, policy, and response across runtime and infrastructure. NHIMG’s Agentic AI Security Guide is a useful reference point for this layered view.

That split works because each layer has a different failure mode. Identity failures usually look like overbroad authority or weak delegation. Interaction failures show up as prompt injection, unsafe tool invocation, or abused API pathways. Behaviour failures emerge when an agent is technically “allowed” to act but no one is clearly responsible for monitoring drift, anomalous actions, or blast radius. AI Agent Authorisation Guide supports the least-privilege side of that separation, while AI Agent Observability, Audit and Incident Response Guide supports the detection and response side.

The practical test is whether the team assigned to a layer can actually change the controls and answer for the evidence. If a team cannot rotate credentials, change policy, tune guardrails, or validate logs for its layer, it is not really the owner. In mature programmes, ownership is paired with authority: IAM can govern agent identity and access decisions, AppSec can harden the interaction surface, and the behaviour owner can require telemetry, escalation paths, and rollback or kill-switch procedures.

Where the boundaries between teams should be drawn

Identity ownership should sit with IAM because it covers registration, authentication, delegation, lifecycle, and revocation. That includes agent identity issuance, token handling, and who is allowed to represent the agent or act on its behalf. The important judgement is that identity ownership is about trust establishment, not just account administration. Agentic AI Identity Guide is the clearest internal navigation path for that scope.

Interaction ownership should sit with AppSec because the main risk is exposure at the boundary where the agent receives instructions or uses tools. This layer covers prompt handling, input validation, output constraints, tool permissions, and protections against prompt injection or tool abuse. AppSec is the right owner because these controls are implemented in application paths, not in generic identity policy alone. The team should also own the review of interfaces that let agents reach sensitive actions through APIs, plugins, or orchestration layers.

Behaviour ownership should sit with a named security owner, often in security engineering or a platform security function, because no single upstream team owns the emergent runtime risk. That owner should not replace IAM or AppSec. Instead, they coordinate the operating model for sensors, logging, anomaly detection, escalation thresholds, and containment. Where the behaviour layer touches clusters or shared runtime infrastructure, platform engineering provides the operational access, but the security owner remains accountable for what good monitoring and response look like.

What good operating model decisions look like in practice

Good ownership models separate three things that are often collapsed into one: who designs the control, who operates it, and who is accountable when it fails. A useful rule is that detection can be shared, enforcement should be owned by the team closest to the control, and infrastructure operations should remain with the platform team that runs the environment. That separation prevents the common failure where everyone is “consulted” but nobody can actually page, patch, or prove the control worked.

Use IAM ownership for agent identity issuance, delegation, revocation, and access review.
Use AppSec ownership for prompt, tool, and interface hardening, including abuse prevention.
Use a named security owner for behaviour monitoring, escalation criteria, and incident coordination.
Use platform support for the telemetry pipeline, cluster access, and runtime guardrails that the security owner depends on.

For a broader control view, NIST AI Risk Management Framework is useful because it reinforces that AI risk governance is a shared operating discipline, while the implementation details still need clear internal ownership. CSA MAESTRO agentic AI threat modeling framework is also relevant where teams need a structured way to map multi-agent risks to owners and controls.

Risk and Threat Considerations

Ambiguous ownership creates security gaps that attackers and failures both exploit. If identity, interaction, and behaviour are all treated as one umbrella problem, teams usually overfocus on policy design and underinvest in revocation, runtime visibility, and containment. The result is a control stack where the agent can still act after a credential, tool path, or behavioural assumption should have been cut off.

Failure mechanism: Overlapping or missing ownership leaves a gap between policy and operations, so no team is clearly responsible for paging, changing controls, or proving that a control is effective. In agentic systems, that can turn into overprivilege, unsafe tool use, or slow response to anomalous behaviour.

Impact: Blast radius expands because an agent can keep acting with valid access, and incident response slows because evidence, telemetry, and containment steps are split across teams without a single accountable owner.

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 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agentic ownership must address identity and delegated authority.
	ASI02 — Tool Misuse	The interaction layer governs unsafe tool invocation and interface abuse.
	ASI08 — Cascading Failures	Behaviour ownership must limit runtime drift and blast-radius expansion.
Recommendation — Assign IAM ownership for agent identity, delegation, and access boundaries. Put AppSec in charge of tool-facing controls and prompt boundary hardening. Name a security owner for monitoring, containment, and escalation across runtime failures.
NIST AI RMF	GV.2 — Map, Measure, and Manage AI Risks	This question is about assigning accountable AI risk ownership across layers.
Recommendation — Define accountable owners for each AI security layer and require measurable control evidence.
CSA MAESTRO	GOVERN — Governance	MAESTRO fits multi-agent governance and owner assignment across operational layers.
Recommendation — Use a governance model that assigns clear control owners for identity, interaction, and behaviour.

Practitioner Guidance

What to prioritise: Start by naming one accountable owner per layer, then define the handoffs between those owners in writing. The most important question is not who “supports” the control, but who can actually change it when the agent’s risk changes.

What to verify: For each layer, verify that the owner can produce a concrete operational artifact, such as an access policy, an interface control, a monitoring rule, or a response runbook. If the owner cannot show that artifact, the ownership model is only nominal.

Common mistake: Treating the behaviour layer as an extension of AppSec or IAM. Behaviour needs its own accountability because runtime drift, anomalous action, and blast-radius containment are different from identity issuance or input hardening.

Practitioner takeaway: The cleanest model is one owner per layer, with platform teams supplying the operating machinery and security retaining accountability for the risk outcome.