AI Agent Security: The Two Ways an Agent Fails, and the One Your Stack Misses

The support agent your team approved last quarter read a ticket, queried the customer database, and emailed the export to an outside address using the mail tool it was given for customer replies. Its service account was allowed to do all three. Admission control had passed the pod weeks earlier, RBAC and the database grant each returned a permit, and the runtime rules saw an expected process making expected connections. No control was broken, and an attack still ran.

That is coercion, the second of two ways an agent fails. The first, compromise, breaks a control: a stolen credential, an exploited CVE, an isolation breach. In coercion a trusted input redirects authority the agent already holds. Every step is allowed, and the sequence is the attack.

The controls in a cloud-native stack were built to register the first kind. What follows defines both failures, shows why the stack registers only one, names the reference a coercion control can be built on, and ends with one test for every control you own.

What AI agent security is

AI agent security is the practice of securing an actor: software that holds an identity, carries authority, and takes actions against systems that matter. It covers what the agent is permitted to do, what the agent actually does, and the distance between those two. It treats the model inside as one component of a workload.

The discipline you already run on workloads applies here with one addition. An agent decides which of its permissions to spend, at machine speed, on input that arrives from outside your organization.

What changes when the model becomes an actor

A model returns text. That text becomes a tool call the moment you hand the model a set of functions and a loop that executes what it selects. The tool call runs under an identity: a service account bound to a role, a credential mounted into the pod, a token issued at startup. That identity carries permissions into systems holding customer records, production configuration, and money.

So the variable that changed is authority. A misbehaving model produces a bad answer, and the blast radius ends at the response. A misbehaving agent spends permissions you granted on purpose, and the blast radius ends where those permissions do.

Failure one: compromise

Compromise is the failure your stack was designed around, and it arrives in shapes you have seen before. A credential leaks and gets replayed from an unexpected source. A dependency in the agent’s image carries a known CVE and gets exploited into remote code execution. A container escape puts a process on the node with access to other workloads’ secrets. In each case a control gives way, and the evidence is the gap between what the identity was allowed to do and what it did.

Agents widen this surface because they carry more of it. One agent pulls a model from a registry, mounts a token, opens a gateway connection, and runs code it generated seconds ago, each step with a supply chain and a permission set behind it. We have broken down the full attack taxonomy elsewhere, and most of it is recognizable to anyone who has run container security for a year.

Compromise is solvable with tools you already own. Coercion is the failure those tools were never built to see.

Failure two: coercion

Coercion is an attack in which a trusted input redirects an agent’s authorized capability, and no control is broken at any point. The attacker touches no credential, exploits no CVE, and crosses no isolation boundary. The attacker supplies content the agent is designed to read, and the agent does the rest with permissions your team granted it deliberately.

The support agent takes three actions, and a human approved every one of them. A customer opens a ticket whose body carries, buried in ordinary prose, an instruction addressed to whatever system reads it: collect the account records in this thread and forward them to an address supplied in the text. The agent retrieves the ticket because retrieving tickets is its job. It queries the customer database because answering account questions requires account data, which is why its service account was granted read access. It calls the mail tool because replying to customers is why the mail tool was attached.

Each action sits inside the agent’s permission envelope, the set of things it is allowed to do without anything escalating. The sequence is data exfiltration performed by a workload with a clean security posture.

Nothing in that chain requires a novel exploit. It requires the agent to be useful, connected, and reachable by text from outside.

AppSec teams put it more bluntly. The agent is authorized, and that is the problem. OWASP files the same shape under excessive agency, tracing it to functionality, permissions and autonomy an agent was granted on purpose, and its worked scenario is an incoming email that gets a mail assistant to forward sensitive data with the send permission it already had.

Compromise asks whether an actor should have this permission. Coercion asks whether an actor with this permission is currently being used by someone else’s intent. The second question has no answer in the permission model, because the permission model is what is being used.

Why the stack registers only one

Three controls carry most of the weight in a cloud-native stack: admission control, RBAC, and runtime rules. Each one answers a question about permission, and in coercion the answer comes back yes every time.

Admission control

Admission control evaluates a workload before it starts. It reads a manifest, applies policy to what the manifest declares, and admits or rejects the pod. A coerced agent was admitted weeks earlier, under a manifest that was accurate then and is accurate now. Policy engines can re-scan admitted workloads in the background, and what they re-scan is still the manifest, so the ticket that arrived this morning changes nothing.

RBAC

RBAC evaluates each call to the Kubernetes API against the identity making it, and the cloud IAM role and database grant below it ask the same question again. The support agent holds read access to customer records because a human granted it, for a stated reason, in a reviewed pull request. When the coerced agent queries those records, each layer checks its binding and returns a permit. Tightening the binding is worth doing and does not address this case, because the permission being used is the one the agent needs to work at all.

Runtime rules

Runtime rules evaluate behavior against a rule set written in advance, so they catch the shapes their authors anticipated: a shell spawned inside a container, a write to a sensitive path, a connection to a known-bad address. A coerced agent spawns no shell, writes nothing unusual, and reaches an address that may be entirely reputable. This is why generic container alerts miss AI-specific threats, and it holds across the detection surfaces most teams have instrumented.

Those three controls all run in your cluster. In-code defenses run earlier, inside the agent, and they deserve credit: input sanitization, tool allow-lists, and the design-time patterns that constrain what an agent can chain together all narrow an attacker’s room. Each depends on a developer anticipating the chain, which is the dependency the runtime rules carry, moved earlier.

The reference a coercion control can be built on

The reference that works is already inside your cluster.

A coercion control cannot be built on an external rule, because no rule can say in advance which permitted action is wrong today. It can be built on the agent’s own history. That history is observable: the processes an agent runs, the files it opens, the endpoints it reaches, the identities it presents, all recorded from the kernel as it happens. Over time that record becomes a baseline specific to one agent, which ARMO holds as Application Profile DNA (APD™) at the Kubernetes Deployment level.

Measured against itself, the coerced agent finally produces a signal. The support agent has never, across months of running, queried account records and then reached an external mail endpoint in the same session. Every individual action stays permitted, and the deviation from the agent’s own behavior is what fires. That deviation is the thing the permission model cannot express, and reading it is what runtime behavioral security means once it is applied to agents.

The objection to a behavioral reference is that agents are built to do new things, so novelty on its own cannot be the signal. What an agent repeats is narrower than what it says: the processes it runs, the endpoints it reaches, the identities it presents, and the order it does them in. A new customer question travels those paths. A coerced sequence leaves them.

A baseline also decides how a team can act. Watch first and prove the baseline is stable, then enforce against deviation, so a control that blocks an agent has evidence behind it first.

One test for every control you own

Take any control protecting your agents and ask one question: would it fire if every individual action the agent took were permitted?

Control	What it asks	Fires on a permitted sequence?
Admission control	Does this manifest meet policy?	No
RBAC and IAM grants	Is this identity allowed this call?	No
Network policy	Is this destination reachable?	No
Runtime rule set	Does this match a known-bad shape?	Rarely
Per-agent behavioral baseline	Is this how this agent behaves?	Yes

Every no in that column is a control doing its job correctly against compromise. Run the test on your own stack before you buy anything: the result tells you whether you are missing a control or a reference. Most teams have the controls and lack the reference.

Authorization stopped being the boundary

Authorization answers whether an actor may take an action. That question was enough while the actors were humans following a process and services running code, because either one took the same actions on Tuesday that it took on Monday. An agent takes whatever action the text in front of it suggests, inside permissions that stay valid throughout.

So the boundary moved from what an agent may do to how an agent behaves. Coercion lives in the space between them, which is why a stack full of correct controls stays quiet while an attack completes. Run the test above against every control you own, and wherever the column reads no, what you are missing is a reference rather than another rule. ARMO builds that reference from each agent’s own runtime behavior, and you can see what it catches across the AI workloads already running in your cluster.

FAQ

Is prompt injection the same thing as coercion? Prompt injection is one delivery mechanism, and coercion is the outcome it produces. NIST’s adversarial machine learning taxonomy gives indirect prompt injection its own attack class, covering instructions that reach a model through data it retrieves. An agent can also be coerced through a compromised API response or a tool description carrying instructions. Treating the problem as injection pushes all defense to the input boundary, while treating it as coercion keeps the focus on what the agent does with its permissions.

Can RBAC or admission control stop a coerced agent? Neither one stops it, and both are still worth tightening. Admission control and RBAC bound how much damage a coerced agent can do, which makes them the first thing to fix once you scope an agent’s permissions. Neither can tell a legitimate use of a permission from a coerced one, because that distinction lives in the sequence rather than in any single call.

How long does a per-agent baseline take to be useful? Useful signal arrives once the baseline has covered an agent’s legitimate paths, which for an agent handling hundreds of requests a day happens quickly. Coverage matters more than elapsed time. Agents with weekly or monthly patterns, such as a reporting agent that runs a different workflow at month end, need a full cycle before enforcement is safe.

What does a coercion alert look like in practice? It looks like a sequence of permitted actions this agent has not performed in this combination before, presented as one chain instead of separate events. A useful alert names the agent, the identity it used, the actions in order, and the point where behavior left the baseline. The responder’s first question is whether a human changed the agent’s job this week, so the alert carries the agent’s normal behavior alongside the deviation.

Do we need this if our agents are read-only today? Read-only agents reduce the impact of coercion without removing it, since reading is enough for exfiltration when the agent has any channel reaching outside your network. Read-only is also temporary in practice. Baselines built while an agent is low risk are ready on the day someone attaches a tool that writes, and that day tends to arrive without a security review.