Risk taxonomy
AI agent risk register
An AI agent risk register records, for each agent you operate, what could go wrong, how far it would go before anyone noticed, who owns that, and what is currently preventing it. Agent risks do not sit comfortably in a conventional IT risk register, for three specific reasons set out below — along with twelve named risks to start from.
Why agent risks do not fit an IT risk register
The temptation is to add a few rows to the existing register and move on. Three properties defeat that, and each one requires a column the standard template does not have.
1. The threat actor can be the input
Conventional IT risk assumes a boundary: a system, and things outside trying to get in. An agent consumes text and acts on it. A support ticket, a web page, a document, a tool response — any of these can carry instructions, and the agent's credentials work exactly as issued while it follows them. Nothing is compromised in the traditional sense, which is why detection tuned for compromise does not fire.
2. Consequence scales with rate, not with severity
A human making a wrong judgement makes it once. An agent making the same wrong judgement makes it at whatever rate its trigger allows, until something stops it. The relevant quantity is not how bad one wrong action is, but how many wrong actions occur before detection. That is a different number and it needs its own column.
3. The system changes without a change record
An unpinned model version moves. A prompt is edited in a file nobody treats as code. A tool is added to a config. The agent's behaviour changes materially and no change-management process fired, so the register describes something that no longer exists — and nothing signalled that it had gone stale.
The three scoring dimensions to add
Keep likelihood and impact. Add three, and score them per agent rather than per risk, because they are properties of the deployment.
| Dimension | Scale | What it determines |
|---|---|---|
| Autonomy | 1 suggests · 2 proposes for approval · 3 acts within stated bounds · 4 acts unbounded | Whether a human is structurally positioned to catch the error at all |
| Blast radius | Worst credible consequence at full rate until detection | The actual exposure. An agent at 200 actions/hour with a 4-hour detection window has a 800-action blast radius, not a one-action one |
| Reversibility | 1 trivially undone · 2 undone with effort · 3 partially · 4 not at all | Whether detection is a sufficient control or merely a consolation |
Autonomy 4 with reversibility 4 is the combination that should never exist without an explicit, expiring, executive-level acceptance. An agent that acts without bounds and whose actions cannot be undone has no control between intent and consequence — every other mitigation on the row is detective, and detection after an irreversible action is reporting, not control.
Blast radius is the dimension worth computing rather than estimating. Rate limit × detection latency gives you a number, and that number is usually much larger than the intuition it replaces. Most teams discover that their detection latency — not their agent's permissions — is the dominant term.
Twelve named agent risks
A starting taxonomy. Not exhaustive; chosen because each has a distinct treatment, which is what makes a taxonomy useful rather than decorative.
| # | Risk | Mechanism | Primary treatment |
|---|---|---|---|
| 1 | Instruction injection via processed content | Text the agent reads contains directives it follows | Taint marking; act-tier permissions refuse tainted input |
| 2 | Confused deputy | Agent exercises its own privilege on behalf of a caller with less | Delegated identity rather than service account; check the caller's rights, not the agent's |
| 3 | Silent scope expansion | A tool or server added to config; permissions unchanged, reach doubled | Declared-vs-observed tool comparison; alarm on change |
| 4 | Rate-amplified error | One wrong judgement repeated thousands of times | Rate caps and anomaly thresholds per action type |
| 5 | Model drift | Unpinned model version changes behaviour with no change on your side | Pin versions; regression suite on the behaviours you rely on |
| 6 | Data egress through the prompt | Confidential context sent to a provider whose terms permit training | Classification-aware context assembly; contracted no-training terms |
| 7 | Orphaned agent | Owner leaves; agent keeps running with live credentials | Owner as a required field; agents in the leaver process |
| 8 | Chained privilege | Two correctly-permissioned agents compose into one that is not | Agent-to-agent invocation as an explicit permission |
| 9 | Fabricated output acted upon | A confident wrong answer becomes a record downstream | Require source attribution; propose-tier for anything entering a system of record |
| 10 | Untestable non-determinism | Cannot demonstrate it will behave as it did in testing | Bounded action space; the constraint is the guarantee, not the model |
| 11 | Missing evidence | Cannot reconstruct what the agent did or why | Log the decision inputs, not just the outputs; defined retention |
| 12 | Undeclared vendor agent | Approved product ships an AI feature; deployer duties attach unnoticed | AI question in the vendor questionnaire; release-note monitoring for tier 1 |
Risks 7 and 12 are the two most reliably present and least often recorded. The orphaned agent is a governance failure with a trivially cheap fix. The undeclared vendor agent is the one that makes an otherwise complete register wrong, because the agents you did not build outnumber the ones you did.
Writing a row that is actionable
The same convention that works for any risk register, with one agent-specific addition. Write cause → event → consequence, and state the rate.
| Weak | Actionable | |
|---|---|---|
| Description | "Support agent may be manipulated by prompt injection" | "Support triage agent reads inbound ticket text and holds an act-tier refund permission, so content in a customer-submitted ticket can cause refunds without an employee involved — at up to 200 tickets/hour against a 4-hour review cycle" |
| Treatment | "Improve prompt hardening" | "Refund permission conditioned on human-originated trigger; taint flag on ticket-derived content; alert at 3 refunds/hour" |
The strong version is longer and every clause earns its place: it names the permission, the untrusted input, the rate and the detection window. It is also the version from which someone can write a control without asking a follow-up question.
Prompt hardening is not a treatment. It reduces the
probability that a given attempt succeeds and provides no bound on consequence
when one does. It belongs in controls_in_place; it does not belong
in the treatment column, because it cannot be verified and cannot be relied
upon.
Review triggers specific to agents
Calendar review is necessary and insufficient here, because the thing being described changes without a release. The triggers that should force a row back onto the agenda:
- A tool, function or MCP server is added to the agent's configuration
- The model identifier or version changes, including an unpinned upgrade
- System prompt or instruction changes materially
- The agent gains access to a new system or data classification
- Its trigger changes — particularly from human-initiated to scheduled or event-driven
- Its rate limit is raised
- The owner changes or leaves
- An action of its type is involved in an incident anywhere in the estate
- A vendor whose product embeds an agent ships a material AI release
Six of these nine are detectable from configuration and telemetry, which means they can raise the review automatically rather than waiting for someone to remember. That automation is what separates an agent risk register that reflects the estate from one that reflects the last time somebody looked.
Which of the twelve risks a product can actually treat
Treatments in the taxonomy above split three ways, and the split is worth making explicit before anyone assumes a purchase closes twelve rows.
Treated by tooling in the call path
Risks 1, 2, 4, 8 and 11 — injection, confused deputy, rate-amplified error, chained privilege, missing evidence. These all require something between the agent and the action: the runtime gateway and policy engine for the first four, the audit ledger for the fifth. None of them can be treated inside the agent, which is why prompt hardening does not appear as a treatment anywhere on this page.
Treated by detection
Risks 3, 5 and 12 — silent scope expansion, model drift, undeclared vendor agents. The treatment is noticing, promptly. Discover and the registry compare declared configuration against observed behaviour; risk 12 also needs an AI question in your vendor questionnaire, which is process rather than product.
Not treatable by any product
Risks 6, 7, 9 and 10 — prompt egress, orphaned agents, fabricated output acted on, untestable non-determinism. These are decisions. What data may enter a prompt is a classification judgement. An orphaned agent is fixed by putting agents in your leaver process. Fabricated output is contained by choosing propose-tier for anything entering a system of record. Tooling can surface all four and resolve none of them.
The number this page asks you to compute — blast radius as rate × detection latency — is the one you cannot estimate in a workshop. Both terms come from runtime telemetry. Most teams find that detection latency, not permissions, is the dominant term, and that finding usually reorders the whole register. The free Discover plan will measure it.
What the register is evidence for
Beyond its operational use, this artefact is what gets asked for in three situations. Knowing which you are serving decides what you cannot leave blank.
After an incident. Was this a known risk, was it accepted, by whom, and what was the control believed to be? A register that shows the risk was identified and accepted with a named owner is a very different conversation from one that shows it was never considered.
EU AI Act deployer obligations. Article 26 requires human
oversight assigned to competent persons, use in line with the provider's
instructions, and log retention. The autonomy, owner
and evidence fields speak directly to whether you can demonstrate that.
Customer and prospect due diligence. Increasingly a vendor questionnaire asks whether AI is used in delivering the service and how it is governed. An agent risk register with owners and treatments is a substantially better answer than a policy document, and it is becoming a commercial question rather than only a compliance one.
Common questions about AI agent risk register
What is an AI agent risk register?
An AI agent risk register records, for each AI agent an organisation operates, the specific ways it could cause harm, how far that harm would extend before detection, who owns the risk, what currently constrains it and when the assessment was last reviewed.
How is agent risk different from normal IT risk?
Three ways: the threat can arrive as ordinary input the agent is supposed to read rather than as an intrusion; consequence scales with action rate rather than with the severity of a single event; and an agent's behaviour can change materially through a configuration or model-version change that triggers no change-management process.
How do you score AI agent risk?
Keep likelihood and impact, and add three dimensions: autonomy level — whether a human is positioned to intervene at all; blast radius, computed as action rate multiplied by detection latency; and reversibility, which determines whether detection is a real control or only a record of what already happened.
What are the main AI agent risks?
Instruction injection through processed content, confused-deputy privilege use, silent scope expansion when tools are added, rate-amplified error, model drift, data egress through prompts, orphaned agents whose owner has left, chained privilege across agents, fabricated output entering systems of record, untestable non-determinism, missing evidence, and undeclared AI features inside vendor products.
Is prompt hardening a valid risk treatment?
No. It lowers the probability that a given attempt succeeds but places no bound on the consequence when one does, and it cannot be verified. Record it as a control in place; the treatment needs to be something that constrains the action — a permission condition, a rate cap, or a required human step.
When should an AI agent risk row be reviewed?
On event rather than only on schedule: a tool added to its configuration, a model version change, a material prompt change, new system or data access, a change of trigger, a raised rate limit, an owner change, an incident involving that action type, or a vendor AI release. Most of these are detectable automatically.