Agentic AI Security Risks, Ranked by Recovery Cost

The board wants to know which AI agent risk to fund first, and a likelihood score cannot answer it. No incident survey gives base rates for agents on your architecture, and an agent can take a different path on the same input. What a CISO can estimate is what each risk would cost to recover from: the work to detect it, scope it, revoke the authority it used, and prove what happened. Ranked on that cost, unexpected code execution drops toward the bottom. Coerced tool use, poisoned memory and inherited privilege rise to the top, because every step they took was permitted.

This article scores the four parts of recovery cost, puts the risks in one ranked table, shows why scoping is where the cost sits, and names what lowers the cost of the top three.

Why the risk lists do not rank

Likelihood is the weak input in an agentic AI risk list. Each row scores how likely a risk is and how bad it would be, and the likelihood score needs a base rate, and a base rate needs a population of incidents on architectures like yours.

Incident surveys supply a population, of a kind. They count incidents across companies running different models, tools, permissions and clusters, which makes them useful for knowing what has happened somewhere. None of them can say how often coerced tool use hits an agent with your service accounts and your MCP connections.

The actor weakens the estimate further. A deterministic service fails the same way each time, so its own history predicts its future. An agent can take a different path on the same input, so even your own incident history predicts next quarter poorly.

Likelihood scores therefore become judgment calls written as numbers, and judgment calls drift toward medium. A list where most rows read medium has no order.

The four-surface risk register stays the right record of which risks exist on which agents, who owns them, and how much damage each could do. What it lacks is an ordering input you can estimate from your own environment today.

Recovery cost has four parts

Recovery cost is the work between an agent doing harm and your team closing the incident with evidence, and it has four parts: detect, scope, revoke and prove. Each part is a property of your current stack, so each can be scored before anything goes wrong.

Score each part from 1 to 3. A 1 means your existing signals and controls handle it. A 2 means they handle part of it and people handle the rest. A 3 means the work starts from nothing and depends on people reconstructing events by hand.

These scores are judgment too. The difference is what the judgment points at: your own logs, identities and controls, which a tabletop exercise can test this week. A likelihood score points at attackers and at a population of incidents you cannot inspect.

Detect

Detect asks whether anything fires when the risk happens. A new shell in an agent container, a denied API call and a CPU spike each produce a signal some tool already watches. An agent reading a table it reads every day, for a reason it has never had before, produces nothing. Score detect by whether the harmful event differs from permitted activity in anything your stack records.

Scope

Scope asks what else the agent touched once you know something happened: which data, which tools, which downstream systems, over what window. One pod and ten minutes is a cheap scope. A scope that opens with “since when?” and has no answer is the expensive one.

Revoke

Revoke asks whether you can pull the authority the agent used without breaking anything else. Killing a pod is clean. Revoking a credential that four workloads share breaks the three that did nothing wrong. Purging a memory store that has been written to for weeks means deciding, entry by entry, what to keep.

Prove

Prove asks whether you can show an auditor, a regulator or the board what happened, from records the agent did not write. Kubernetes audit logs, cloud audit logs and kernel-level events are written outside the agent’s process. The agent framework’s own logs are written inside it. Deciding what to log before an incident decides how much of this part is left to argue about after one.

The ranking

The table scores eight agentic AI risks, named where possible after the OWASP Top 10 for Agentic Applications, against a common starting point for teams at 250 to 5,000 employees: a Kubernetes cluster with admission control, Kubernetes and cloud audit logs flowing to a SIEM, and no per-agent record of normal behavior. Each risk has its own mechanics in the attack taxonomy. The table prices only what it costs to come back from each one.

Risk	Detect	Scope	Revoke	Prove	Total	What drives the cost
Memory and context poisoning	3	3	3	3	12	Writes look like normal use, and the bad entries persist into later sessions
Coerced tool use	3	3	2	3	11	Every call is permitted, and the agent’s own logs record a normal tool call
Inherited privilege	3	3	3	2	11	Actions run under an identity other workloads or users share, so revoking it breaks them
Cascading failures across agents	2	3	2	2	9	The error surfaces in a downstream agent, far from the one that started it
Agentic supply chain (poisoned tool or MCP server)	2	3	2	2	9	Every agent that loaded the component is in scope
Privilege escalation beyond granted permissions	1	2	2	1	6	Denied calls land in audit logs, and scoping has to find the attempts that succeeded
Unexpected code execution	1	2	1	1	5	A new process fires at once, and the pod is disposable
Resource exhaustion	1	1	1	1	4	Cost and latency alarms fire, and a restart or a quota ends it

Your scores will move with your environment. Strict egress policy lowers scope for anything that exfiltrates. One service account per agent lowers revoke for inherited privilege. A cluster with no audit log retention raises prove on every row. An agent that runs generated code by design moves unexpected code execution up the table, because a new process is routine for it, so detect becomes a 2 or a 3. The split between the top and bottom groups holds across most stacks, because it follows from whether a risk breaks a control or uses a permitted action.

The loud risks are the cheap ones

The loud risks break a control or a resource limit, and the break is their signal. In an agent with no code-execution tool, unexpected code execution spawns a process the container has never run. Resource exhaustion trips the cost and latency alarms your platform team already watches. Privilege escalation beyond granted permissions leaves denied calls in the Kubernetes and cloud audit logs, provided the audit policy records denied requests.

They are cheap because every part of recovery has a boundary. Detection is immediate. Scope sits inside one workload, often one pod. Revocation is a pod kill, a network policy or a quota. Proof already sits in audit records written outside the agent.

They are also the risks security teams rehearse most, because they resemble the container incidents teams already handle. That familiarity keeps them on the list and gives no reason to fund them first.

Cheap assumes the event is caught at its first step. An escape that runs unnoticed for days leaves this group and joins the expensive one.

The quiet authorized ones are expensive

The quiet risks use authority the agent legitimately holds. Coerced tool use is the flagship case: a prompt redirects the agent’s authorized capability, every tool call is allowed, and the sequence is the attack. Poisoned memory writes entries through the agent’s normal memory interface and waits for a later session to act on them. Inherited privilege runs harmful actions under an identity the agent shares with other workloads or with the user it acts for.

These risks clear every permission control, because those controls were built to object to actions outside the grant. They leave detection waiting for a downstream effect: a customer complaint, a failed reconciliation, a notice from a third party. When the investigation opens, every symptom looks normal, because each action is one the agent performs on a healthy day.

Scoping them starts from nothing. No alert marks the first step, so there is no timestamp to work backward from, and nothing flags which of the agent’s thousands of permitted calls were the harmful ones.

Scoping is where the cost sits

Scoping starts when someone confirms an incident, with one question: what did the agent touch? The answer is spread across records. Kubernetes audit logs hold API requests. Cloud audit logs hold identity and storage calls. The SIEM holds whatever the container runtime forwarded, and the agent framework holds its own account of tool calls.

Those records name the same agent differently: a pod name that changed at the last rollout, a service account shared with other workloads, a cloud role assumed through federation. So the analyst joins them by hand, on timestamps, one agent action at a time. For a quiet risk with no known start, that join runs back over weeks of history, and the hours can run into days.

Running that work is the job of an incident response playbook. For the ranking, only its cost matters, and that cost is set before the incident, by whether the join already exists.

The join can already exist when the incident opens. A team holding one timeline per incident, with process, file, network and identity events joined at each step, scopes by reading that timeline. ARMO assembles that timeline as an attack story, and reports investigation time down by more than 90% across its attack stories, compared with correlating alerts from separate tools by hand. That difference lands in the scope column, which scores 3 on all three top risks.

What lowers the cost of the top three

Three investments move the top rows of the table: a behavioral record, revocable authority and independent evidence. Each one lowers a different column.

A behavioral record

A behavioral record is a per-agent history of what the agent normally does, held at the Deployment level so it survives pod restarts and reschedules. It lowers detect, because coerced tool use shows up as a departure from that agent’s own history even when every action is permitted. It lowers scope, because the history marks where normal stopped. ARMO calls this record Application Profile DNA (APD™), and it is the core of ARMO’s runtime behavioral security for AI workloads.

Poisoned memory tests the record hardest. Slow conditioning can drift into what the record treats as normal, so the record scopes poisoned memory only as far back as a point you know was clean.

Revocable authority

Revocable authority means every agent holds credentials that belong to it alone and can be pulled without touching anything else. One service account per agent workload moves inherited privilege from a 3 toward a 1 on revoke. Short-lived credentials shrink the window scope has to cover. Keeping long-lived secrets out of the agent’s reach, so the agent never holds the real key, takes the most expensive revocation off the list.

Independent evidence

Independent evidence is a record of what the agent did that the agent’s own process did not write. Kernel-level events, Kubernetes audit logs and cloud audit logs qualify, as long as the agent’s identity has no permission to change audit configuration. Framework logs do not, because a coerced agent logs a normal tool call. Independent evidence lowers prove for every quiet risk at once, and it gives a board presentation of the incident something to stand on.

Rank by what you would pay on the worst day

A recovery-cost ranking gives the board an order it can check. Each score points at a property of your own environment, so a director who questions a 3 can ask what would make it a 1, and the answer is an investment with a name.

The ranking is built around the worst day for an agent program, which is the quiet one: an authorized agent, a permitted sequence and no timeline. Score your own agents against the four columns before that day arrives, and mark every row where scoping starts from nothing. Those rows are the ones a per-agent behavioral record moves, which is what ARMO’s runtime behavioral security for AI workloads is built to produce: one timeline per incident, assembled while the agent is still running.

FAQ

How do I score recovery cost without incident history of my own? Score each part from what your stack can do today, and test it with a tabletop exercise per risk. For detect, pick one harmful action and name the tool that would fire. For scope, name the records that would show everything the agent touched over the last 30 days, and check whether they share an identifier for that agent. Recovery cost needs no incident history, which is the reason to use it.

Where does this ranking sit next to the risk register we already keep? The register records which risks exist, on which agents, and who owns them. The recovery-cost ranking orders those rows for funding. Add the four cost scores to the rows you already have, and leave the register’s structure as it is.

Which risk should a team with no runtime visibility fix first? Start with inherited privilege, because the fix needs no new tool. Give every agent workload its own service account, remove credentials shared across workloads, and move to short-lived tokens where the cloud provider supports them. Then build the behavioral record, since it lowers detect and scope for coerced tool use and poisoned memory at the same time.

How do I present this to a board that expects likelihood and impact? Keep impact, and state in one sentence why likelihood is replaced for agent risks: no base rates exist for your architecture. Show the ranked table, then the three investments and which scores each one moves. A board can track a score moving from 3 to 1 quarter over quarter, which gives the spend a measurable result.

How often should the ranking be redone? Rescore an agent when it gains a tool or MCP connection, a memory store, a new identity or permission, or a new model. Review the full table quarterly alongside the risk register. After any incident, compare the scores you predicted with the recovery you ran, and correct the column that was wrong.