Agentic risk: the OWASP ASI taxonomy applied

An agent is a system that plans, remembers, calls tools and acts. Each of those four capabilities converts a class of model error into a class of operational consequence, which is why governance designed for a scoring model does not transfer.

The OWASP Top 10 for Agentic Applications 2026, published 9 December 2025 despite the 2026 label, gives the taxonomy. Use it as a control checklist rather than as reading, and map each entry to something in your own system.

The ten, and what each one looks like in a regulated firm

ASI01 Agent Goal Hijack. The agent's objective is redirected by input it processes. In claims, the input is a document a claimant supplies. Control: the instruction channel is separated from the data channel, and content in retrieved documents is never treated as instruction.

ASI02 Tool Misuse and Exploitation. The agent calls a legitimate tool in an illegitimate way: a payment tool called with an adjusted amount, a search tool used to enumerate records. Control: least privilege per tool, parameter validation outside the agent, and a hard limit on value and volume that the agent cannot raise.

ASI03 Identity and Privilege Abuse. The agent acts with a service identity that aggregates permissions no human holds. Control: the agent holds its own identity, scoped narrowly, and acts on behalf of a named user with that user's entitlements where a decision affects a customer.

ASI04 Agentic Supply Chain Vulnerabilities. Tools, plugins, model endpoints and prompt templates arriving from outside. Control: the inventory covers tools and prompts as objects in their own right, not just systems.

ASI05 Unexpected Code Execution. The agent runs generated code. Control: sandboxing with no network or credential access by default, and an explicit decision to grant either.

ASI06 Memory and Context Poisoning. Content written into persistent memory shapes later behaviour long after the interaction that planted it. This is the one that defeats point-in-time testing: the system passes every test and then behaves differently in week six. Control: memory is scoped, attributable, expiring and inspectable.

ASI07 Insecure Inter-Agent Communication. One agent trusts another's output as fact. Control: provenance on messages between agents, and no privilege escalation by relay.

ASI08 Cascading Failures. One bad output becomes the input to the next step, and the error compounds across a chain nobody watches end to end. In claims triage this is how a misread date becomes a coverage decision. Control: checkpoints where a human or a deterministic rule validates state, not just the final output.

ASI09 Human-Agent Trust Exploitation. The agent's fluency and confidence induce the reviewer to approve. This is automation bias, which Article 14(4) names expressly as something the oversight person must remain aware of. Control: show the reviewer the evidence rather than the conclusion, and measure approval rates and time per decision.

ASI10 Rogue Agents. An agent operating outside its intended scope, or one nobody remembers deploying. Control: registration, a named owner, an expiry date, and a kill switch that is tested rather than documented.

What the Act already requires of this

Article 14(4) requires that the oversight person can understand the system's capacities and limitations, remain aware of automation bias, correctly interpret the output, decide not to use the system or to disregard, override or reverse its output, and intervene or interrupt through a stop button so the system halts in a safe state. For an agent that acts, a stop button that halts in a safe state is an engineering requirement with a definition attached: what is a safe state when the agent has already made three tool calls and one of them sent a payment instruction.

Article 12 requires automatic recording of events over the system's lifetime, and Articles 19 and 26(6) set the six-month retention floor. For an agent the log has to carry the plan, the tool calls, the parameters, the results and the memory writes, not just the final output. A log of outputs alone cannot reconstruct an agentic failure.

Article 15 requires resilience against attempts to alter the system's use, outputs or performance, which is where ASI01 and ASI06 land in legal terms.

Worked example: a bank pilots an agent for dispute handling

A retail bank pilots an agent that handles card dispute intake: it reads the customer's message, retrieves the transaction, checks the merchant, decides whether the dispute is eligible, raises a provisional credit up to a limit, and writes a case note.

The design review maps the ten and finds three real exposures. The dispute message is attacker-controlled text that reaches the planner, which is ASI01, so the bank routes customer text as data with instruction parsing disabled and tests with injected instructions before go-live. The provisional credit is a tool call with a money value, which is ASI02 and ASI03 together, so the limit is enforced by the payment service against the agent's own scoped identity rather than by the prompt, and cumulative daily value is capped independently. And the case note the agent writes is read by the agent on the next contact from the same customer, which is ASI06: a customer can shape future handling by what they say now. Case notes become read-only context with an attributed source rather than trusted memory.

The oversight design follows ASI09. Reviewers see the transaction, the merchant record and the eligibility rule that fired, with the agent's recommendation last rather than first. Approval rate and seconds per decision are monitored as a control, because an approval rate of ninety-eight per cent at eight seconds per case is evidence that oversight has stopped happening, whatever the process document says.

As of 24 September 2026.