When an assistant can act, the review changes
An assistant that reads a document, chooses a tool, and acts under a service identity crosses several boundaries in one request. Reviewing its final answer tells you only part of the story. You also need to understand the decisions and actions that produced it.
The OWASP Gen AI Security Project’s Top 10 for Agentic Applications, 2026 edition, names ten risk categories, ASI01 through ASI10. Below we explain each category in plain language. The illustrative business scenarios and review questions are ours; they are not claims about incidents at a particular company.
ASI01 · Agent goal hijack
Untrusted content redirects what the agent is trying to accomplish.
Imagine a purchasing assistant reading a supplier attachment that tells it to bypass the normal review. Your review question: does the proposed order still match the task the buyer authorized?
ASI02 · Tool misuse and exploitation
A legitimate tool is used in an unintended or harmful way.
An agent asked to identify obsolete records decides to delete them. Check the boundary between finding candidates and changing the database. Each action needs a defined purpose and permission, even when the tool itself is approved.
ASI03 · Identity and privilege abuse
The agent uses access that the requesting user should not have.
A regional manager asks for sales figures and receives company-wide results because the connector uses one shared credential. Test the same request with differently entitled accounts, and confirm that authorization follows the user through each handoff.
ASI04 · Agentic supply chain vulnerabilities
Compromised components enter through the tools and dependencies an agent relies on.
Consider a connector update that introduces a new outbound destination. Who approved that change, and which identity can it use? Inventory deployed connectors, their versions, and the permissions they receive. Review changes before they reach production.
ASI05 · Unexpected code execution (RCE)
Agent-controlled input becomes executable code outside the intended boundary.
A reporting agent turns a spreadsheet value into part of a generated script. Ask whether that value remains data throughout execution. Review generated code paths separately from ordinary tool arguments, and isolate execution from production credentials.
ASI06 · Memory and context poisoning
Corrupted stored context influences future work beyond the original interaction.
A support agent saves an unverified customer instruction as an account policy, then applies it to later tickets. Inspect who can write memory, how provenance is retained, and whether an operator can identify and remove a poisoned entry.
ASI07 · Insecure inter-agent communication
Messages between agents cross boundaries without adequate identity or integrity checks.
A scheduling agent accepts a message claiming to come from the approval agent. Verify the sender and the request’s scope at the receiving system. A familiar agent name in the message body is not evidence of authority.
ASI08 · Cascading failures
One failure propagates through connected agents and workflows.
An inventory agent makes a mistaken shortage call. Procurement and customer communications then act on it. Trace which downstream actions can proceed automatically, where validation occurs, and how an operator can stop the chain before more systems change.
ASI09 · Human-agent trust exploitation
People are persuaded to trust or approve unsafe agent behavior.
An agent labels an unusual payment change routine and asks for approval. Does the reviewer see the recipient, amount, and supporting evidence, or only the agent’s reassuring summary? Design approvals around the action and its evidence.
ASI10 · Rogue agents
An agent diverges from its intended behavior and escapes effective oversight.
Imagine an optimization agent continuing to change schedules after an operator withdraws permission. Check whether stopping the agent also stops delegated work and revokes its access. Monitoring should compare completed actions with the authorized task, not only record successful calls.
Turn the list into a review of your system
Start with one real workflow. Write down the user, the agent, each tool, the identity used for each call, the data reached, and the actions that can follow. Use the ten categories to ask questions at those boundaries.
For our reviews, a useful test records the account, configuration, input, and observed result. If a category does not apply, say why. If a boundary cannot be tested, record the gap. A category identifier helps organize the evidence; it does not establish that a deployment is secure.
Repeat the relevant checks after remediation and material changes to prompts, models, memory, permissions, or integrations. Keep the review tied to the system your team is running.
