What Is Agentic AI Security? The 3 Layers and Their Owners

Two of the three layers of agentic AI security already have an owner in your organization, and the third has none. Identity falls to IAM and interaction falls to AppSec, because the controls at both layers extend products those teams already run. The behaviour layer covers what the agent does on the infrastructure once it is running, and it sits between a platform team with no security mandate and a SOC with no sense of what normal looks like for an agent.

That gap is where a coerced agent works. It holds a valid identity and sends well-formed requests, so it clears the first two layers by design.

What follows defines the three layers by where the control sits, explains why the behaviour layer has no owner, shows why coercion lands in the unowned layer, and closes with three questions that settle ownership: who gets paged, who can change the control, and who signs the evidence.

What agentic AI security covers

Agentic AI security is the practice of controlling what an autonomous AI agent is allowed to reach, what goes into and out of its model, and what it does on the infrastructure it runs on. It sorts into three layers by where the control sits: identity, interaction and behaviour. Each layer has its own owner and its own failure mode.

Agentic AI security sorts by control location because location decides ownership. A control that lives in the identity provider belongs to the team that runs the identity provider. A control that lives in front of the model belongs to the team that runs application defences. A control that lives on the node belongs to whoever has been told to watch the node.

It became its own discipline when workloads stopped following fixed code paths, and this post where we explain why this changed covers that shift. It also sits beside the risk view you may already keep: the four risk surfaces describe what an agent can damage, and the three layers describe who operates the controls that limit it.

The identity layer: what an agent is allowed to reach

The identity layer decides what an agent is allowed to reach. It holds the agent’s non-human identity, the standing access attached to that identity, and the entitlements the agent picks up from every system it is connected to. In a Kubernetes cluster it usually starts as a service account, which Kubernetes defines as a non-human account with its own identity in the cluster. From there it extends through cloud roles, API keys and delegated grants to every tool the agent calls.

The identity layer belongs to IAM. Its controls are the ones IAM already operates for workloads: issuance, scoping, rotation, review. Agents raise the volume and the rate of change. The work and the tooling stay the same.

The identity layer fails by over-grant. An agent that can reach more than its job needs hands the surplus to anyone who takes control of it.

From the identity layer you can tell the board what each agent could touch. What the agent did with that reach is recorded two layers down.

The interaction layer: what goes into and out of the model

The interaction layer governs what goes into and out of the model. Going in: user prompts, retrieved content, tool descriptions and tool results. Coming out: responses and the tool calls the model proposes. Its controls screen content at both ends: input filters, output validation, and gateways placed between the agent and its model or between the agent and its tools.

The interaction layer belongs to AppSec. Screening untrusted input and validating output is the discipline AppSec already practises on web applications, and the screens and gateways deploy the way API gateways do. OWASP has listed prompt injection first in every edition of its Top 10 for LLM Applications, including the 2026 release, and the interaction layer is where that risk is screened.

The interaction layer keeps that owner when an AI platform team runs the gateway, provided AppSec writes the screening policy and takes the page. Where neither holds, the interaction layer is open too, and the same three questions settle it.

The interaction layer fails in two ways. Content that reads as ordinary passes the screen. And the layer sees only what crosses it: a process the agent starts or a file it opens on the host never touches the gateway.

The behaviour layer: what the agent does on the infrastructure

The behaviour layer covers what the agent does on the infrastructure once it is running. It takes in the processes the agent starts, the files it reads and writes, the network destinations it connects to, and the identities it uses out of those it holds. It is the record of what agents do, observed from outside the agent’s own process. It is the ground covered by AI workload security.

The behaviour layer fails by absence. Either nobody is watching, or somebody is watching events without knowing which of them are normal for this agent.

Only the behaviour layer can answer the board’s question in the past tense. Identity says what an agent could reach. Interaction says what it was told and what it said. Behaviour says what it did.

The behaviour layer has two candidate owners, the platform team and the SOC, and no default one.

Why the behaviour layer has no owner

The platform team owns the cluster the agents run on. Owning the cluster means owning uptime, cost and deployment, and none of those carries a security mandate. Without a security mandate, agent behaviour becomes a security matter only when it reaches the SOC as an alert.

The SOC owns alerts, and an alert about an agent arrives without a sense of normal. The analyst sees that a process started or a connection opened, and has nothing that says whether this agent does that every day. Without a sense of normal, the alert is closed as noise or escalated to the platform team, which is back where the chain started: holding the cluster, with no mandate to judge what runs on it.

Neither team is wrong. The mandate was never written, because a deterministic service did what its code said, and identity plus network policy described it well enough. An agent decides at run time, so its behaviour became a layer of its own while the org chart stayed the same.

A SOC that already runs a container runtime tool is in the same position. It receives the tool’s alerts and owns its generic detections, such as a shell opened inside a container. It has not been asked to say what is normal for a given agent, and that judgment is the behaviour layer.

The gap shows up in any governance review. The NIST AI Risk Management Framework asks, in GOVERN 2.1, that roles and responsibilities for managing AI risk are documented and clear to every team. For identity and interaction you can produce that document today. For behaviour there is nothing to write down yet.

Coercion lands in the unowned layer

Coercion is an attack in which an authorized agent is steered, through content it was meant to read, into a sequence of individually allowed actions that serves the attacker.

A coerced agent acts under its own authorized identity. That identity is valid and in scope, so the identity layer has nothing to report and IAM is never paged. The instruction reached the agent through a trusted channel, as content it was supposed to process. Content that reads as ordinary passes the interaction layer, so AppSec is never paged either.

What follows is a run of allowed actions: every tool call, file read and connection is one the agent is permitted to make. A gateway placed between the agent and its tools sees each of those tool calls, judges each against policy, and passes each one. Whatever the agent does beneath the tool call, on the host, the gateway never sees. Only the sequence differs from what this agent normally does, and sequence is a property of behaviour.

So the page belongs to the behaviour layer’s owner, and there is no such person.

All three layers are present in this attack and two of them work as designed. The third needs a per-agent reference to compare the sequence against, which ARMO builds as Application Profile DNA (APD™), and it needs someone whose job it is to look.

Three questions that settle ownership

The good news is that the gap is an assignment problem, and assignment is within your authority today.

A layer is owned when three questions have a named answer: who gets paged, who can change the control, and who signs the evidence.

Who gets paged

Who gets paged is the test of operational ownership. For identity, an entitlement change or a credential event pages the IAM on-call. For interaction, a blocked prompt or a flagged response pages AppSec. For behaviour, the event lands in a shared SOC queue with no agent context, so nobody is paged.

Who can change the control

Who can change the control decides who holds authority over the layer. IAM can narrow a role. AppSec can tighten a screen. At the behaviour layer the platform team has the access to change what an agent may do on the node and no mandate to decide it, while security has the mandate and no access. The split that holds up in a running security programme gives security the detection rules, the enforcement policy and incident response, and gives platform the sensor and the cluster.

Who signs the evidence

Who signs the evidence is the person accountable for the layer. An auditor or a board member will ask for proof that each agent stayed inside its policy. IAM signs the access review and AppSec signs the application security report. The behaviour layer has no report, so it has no signature.

Run the three questions across the three layers and the gap shows up in one row.

Layer	Owner	Who gets paged	Who can change the control	Who signs the evidence	What is missing today
Identity	IAM	IAM on-call, on a credential or entitlement event	IAM, through the identity provider and cloud roles	IAM lead, in the access review	A review cadence that keeps pace with how fast agents gain tools
Interaction	AppSec	AppSec, on a blocked prompt or flagged response	AppSec, through screen and gateway policy	AppSec lead, in the application security report	Sight of anything the agent does after the model responds
Behaviour	Unassigned	Nobody. The event sits in a SOC queue without agent context	Platform has the access, security has the mandate, neither has both	Nobody	A named owner, a sense of normal for each agent, and a written mandate for platform

The layer you cannot assign is the one you will be attacked through

The layer you cannot assign is the layer where an attack lasts longest, because a valid identity and clean content raise no page in the other two. Assignment comes before tooling for that reason. A tool bought for an unowned layer produces alerts that nobody is paged for, changes that nobody may approve, and evidence that nobody signs.

So write the behaviour row first. Name the security owner who is paged and who signs. Give the platform team a written share of the layer: they run the sensor and the cluster, and they are consulted before anything is enforced.

That second part is where assignment stalls, because the platform team’s first duty is to production. Co-ownership is an easier ask when it carries no production risk. ARMO’s Audit to Enforce path watches first, proves the policy is safe against observed behaviour, and only then enforces, so the platform team sees how each policy fits its own agents before it agrees to block anything.

Once each layer has a name against it, the owner of the behaviour row needs something to answer with. ARMO’s AI workload security gives the platform team one eBPF sensor to run with no code changes, and gives the security owner a baseline of normal for every agent, so a coerced sequence reaches them as one attack story. Start it in Audit, where it records what each agent does and blocks nothing, and the behaviour row’s owner can answer the board’s question in the past tense.

FAQ

Who should own AI agent security, the security team or the platform team?

Both, split by layer. IAM owns identity and AppSec owns interaction. The behaviour layer is shared: security owns detection rules, enforcement policy, incident response and the evidence, while the platform team owns the sensor and the cluster it runs on. One named person in security is accountable for the layer as a whole.

Does an AI gateway cover the behaviour layer?

No. A gateway is an interaction-layer control, and it sees the traffic that passes through it. The processes an agent starts, the files it opens and the connections it makes directly from the host never cross the gateway. Those actions are the behaviour layer, and they need to be observed where they happen.

How do we assign the behaviour layer without hiring a detection engineering team?

Keep the mandate small. Name one security owner for paging and evidence, and ask the platform team to run the sensor in an observe-only mode. The first months then produce a record of what each agent normally does. Detections are tuned against that record, so nobody has to write a rule set from a blank page.

What is the first thing to put in place if we own none of the three layers today?

A one-page assignment: three layers, three questions, a name in every cell. Identity and interaction will fill in quickly because the teams already exist. Then start observing behaviour. It is the layer where nothing is running yet, and observation is the step that carries no production risk.

How does this map to the risk surfaces we already track in our register?

The register describes what can be damaged, and the layers describe who operates the control that limits the damage. Each row in the register gains a control owner drawn from one of the three layers. Rows whose control owner comes out as the behaviour layer are the ones with no accountable name.