Susceptibility, damage, and recovery time are the three numbers that decide how bad a compromise gets. AI agents need the same three numbers, but each one works differently once the system involved can read instructions and act on them.

The three questions you need to ask are simple. What lets someone reach the system, what can they do once they're in, and how long before the team notices and cleans up. A traditional system like a database or a server answers all three through controls like firewall rules, admin permissions, and a documented restore process. An agent, on the other hand, answers them through something looser, whatever content it reads and tools it's allowed to call, and whatever trace it leaves behind once it's already acted.

Here's the thing, almost anything that puts text in front of an agent can reach it, a user message, a document it summarizes, or a webpage it fetches to draft a reply. Any one of these can carry instructions the agent treats as legitimate, stretching its input surface far wider than a network diagram would ever show. Testing that surface works much like testing a firewall rule, feed the agent a normal-looking task with a hidden instruction inside it, then check whether it follows that instruction instead of the real one.

An agent's tools and credentials set the real limit on what a compromise can do, and that limit often runs wider than a single admin login, since a useful agent tends to hold a slice of access across several systems at once. A support agent that reads tickets, issues refunds, and searches customer records carries all three abilities the moment something manipulates it, not just the one task a user asked for. Listing every tool an agent can call, along with the permission sitting behind each one, turns a vague sense of its reach into a specific list worth defending, and asking what the worst version of each call could do if triggered by something other than the real user fills in the rest of the picture.

Recovery is where things break a bit...

An agent that took a string of bad actions over an unknown stretch of time has no equivalent playbook waiting for it the way a compromised database does. Revoking access, isolating a system, and restoring from a clean backup returns a database to a known state, but rolling back an agent that sent emails, or changed records while manipulated cannot undo actions that already happened out in the world. A model steered gradually through its own context raises the same problem in a different shape, since that kind of manipulation rarely produces one clean event to point at and reverse. Most incident plans built for traditional infrastructure say nothing about this scenario, and that "void" tends to surface for the first time during an actual incident rather than before one.

Answering the same three questions for an agent just takes different instrumentation. Logging every tool call in enough detail to reconstruct a full sequence afterward gives the team the closest thing to a timeline once something goes wrong. Scoping an agent's credentials down to the minimum its task needs shrinks the damage question before any incident forces an answer to it. Testing how long it actually takes to notice an agent behaving badly, rather than assuming detection happens fast, turns that number into something real, since an agent running unsupervised for three days before anyone notices has a three-day detection time no matter what the incident plan claims on paper.

Running this same exercise against every agent in production, one at a time, starting with whichever one holds the widest tool access or touches the most consequential system it can reach, turns this from a thought experiment into an actual ranking. The playbook for recovering from a manipulated agent may not exist yet in most places, and knowing that now beats discovering it while an incident is already underway.