The short answer
OWASP published its Top 10 for Agentic Applications for 2026 in December 2025.1 The ten risks are ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents.1
A gate that sits between agents and the tools they call, deciding each call by rule, helps most with tool misuse, privilege abuse and cascading failures, because those risks end in a tool call. It helps partly with six more. It does little or nothing for memory poisoning or for the model being fooled in the first place. We build such a gate, so the map below lists our misses as plainly as our coverage.
Deedglass
What the AI said, and what really changed
The AI said
1 row
“1 row updated”
What really changed
301 rows
From the database’s own log
The ten risks in plain words
Each line paraphrases OWASP’s own description.1
| ID | Risk | In plain words |
|---|---|---|
| ASI01 | Agent Goal Hijack | Content the agent reads changes what it’s trying to do |
| ASI02 | Tool Misuse and Exploitation | The agent uses a tool it’s allowed to use, in a harmful way |
| ASI03 | Identity and Privilege Abuse | Inherited or delegated credentials reach further than they should |
| ASI04 | Agentic Supply Chain Vulnerabilities | Third-party tools, servers, models or agents are malicious or tampered with |
| ASI05 | Unexpected Code Execution | Agent-generated code runs and escalates |
| ASI06 | Memory and Context Poisoning | Stored memory or retrieved context is seeded with bad data |
| ASI07 | Insecure Inter-Agent Communication | Messages between agents are spoofed, altered or unauthenticated |
| ASI08 | Cascading Failures | One fault spreads across agents into system-wide harm |
| ASI09 | Human-Agent Trust Exploitation | People approve what the agent proposes without checking it |
| ASI10 | Rogue Agents | An agent drifts from its intended function or scope |
Two framings from the document are worth keeping in mind. ASI01 states that agents cannot reliably distinguish instructions from related content.1 And ASI02 covers an agent applying a legitimate tool unsafely within its authorized privileges, relating it to LLM06:2025, Excessive Agency.1 LLM06 names the root causes as excessive functionality, excessive permissions or excessive autonomy.2
Where a gate sits, and why that decides coverage
A tool-call gate sees one thing: the call the agent is about to make, with its arguments, and the result. It doesn’t see the prompt, the model’s reasoning, or what the agent remembers. So a simple rule tells you what it can help with: a risk is covered to the degree it ends in a tool call the gate can see.
That rule explains the whole map. Goal hijack (ASI01) starts in the model, out of reach, but it usually ends in a tool call, which the gate can refuse. Memory poisoning (ASI06) happens in a store the gate never sees. Supply chain (ASI04) is partly visible: a tool definition passes through the gate, the code behind it doesn’t.
The map
“Helps” means the gate can stop or hold the harmful step. “Partly” means it covers one path and not others. “No” means don’t count on it.
| Risk | A gate | What it can do | What it can’t |
|---|---|---|---|
| ASI01 Goal hijack | Partly | Refuse or hold the harmful call that follows | Stop the model being steered |
| ASI02 Tool misuse | Helps | Rules on arguments; approval for risky calls | Judge intent behind an allowed call |
| ASI03 Privilege abuse | Helps | One identity per agent; the gate holds the credentials | Credentials the agent got elsewhere |
| ASI04 Supply chain | Partly | Hide tools whose definition changed or carries hidden instructions | Malicious code inside a server |
| ASI05 Code execution | Partly | Refuse code-running tools, or hold them for approval | Code the agent runs locally, outside the gate |
| ASI06 Memory poisoning | No | Nothing; memory isn’t a tool call it sees | Anything in the memory store |
| ASI07 Inter-agent comms | Partly | Put agent-to-agent calls under policy and record the chain | Check what the other agent actually did |
| ASI08 Cascading failures | Helps | Stop one agent or all agents everywhere; budgets | Undo effects outside its reach |
| ASI09 Human trust | Partly | Show approvers the exact call, not the agent’s summary | Make people read it |
| ASI10 Rogue agents | Partly | Hold writes after a failed check; record every action | Detect drift that stays within rules |
Some specifics from our own implementation, where they apply:
- ASI04. Our MCP wrapper hides a tool whose definition changed after it was first listed, or whose description carries instructions aimed at the model or characters people can’t see. It’s a heuristic: a reworded instruction can pass.3 And through an MCP server, only tool calls meet the rules; resources and prompts pass through.3
- ASI07. Our A2A proxy forwards message and task calls to a remote agent only when the policy allows them.6 The remote agent’s answer is recorded as what the peer reported, not what it did.6
- ASI08. Stop refuses every call from one agent or from all agents, honoured on every instance within 2 seconds; it doesn’t kill processes or roll anything back.4
- ASI10. In lockdown, after an action ends as “can’t check”, that agent’s writes are refused until a person acknowledges it; reads still run.5 Turning lockdown off takes two different owners or admins.5
The risks a gate doesn’t touch
Being clear about the “No” and “Partly” rows matters more than the “Helps” rows, because those are where teams over-trust a tool.
ASI06, memory and context poisoning. If an agent’s long-term memory or retrieval store is seeded with false data, every later decision starts from it. A gate sees the calls that result, and a rule might refuse one, but it has no view of the memory. Protect the stores themselves: who can write to them, and review of what goes in.
ASI01 at the model level. The gate can refuse the bad call. It can’t make the model less steerable. Our own attack suite says this explicitly: it assumes the model has already been manipulated and doesn’t measure how often a model falls for an injection.7
ASI05 outside the gate. A coding agent that runs a shell on your laptop doesn’t send that command through a network gate. That needs a hook in the agent itself, or a sandbox. Our Claude Code hook post covers one approach.
ASI09, at its root. A gate can make approvals precise and rare. It can’t make a tired person read carefully.
Least-Agency: the idea under the list
The document’s leaders introduce a principle they call Least-Agency: avoid unnecessary autonomy, because agentic behaviour where it isn’t needed expands the attack surface without adding value. They also call strong observability non-negotiable.1
That is the most useful sentence in the whole list for anyone deploying agents. Before mapping controls to ten risks, remove what the agent doesn’t need: tools, permissions, the ability to act without a person. Every row in the map gets easier when the agent can reach less. The blast radius entry turns that into a practical exercise.
How to use this map
- List each agent’s tools and credentials. Most risks start there.
- Mark each OWASP risk as covered, partly covered or open for your setup, using the “can’t” column above honestly.
- Cover the open ones with something else: memory store controls, sandboxes, per-agent credentials, training for approvers.
- Test it. Write cases that assume the model is fooled, as in our attack suite.
A tool-call policy is the mechanism behind most “Helps” rows, and tool poisoning shows ASI04 in practice. To see a gate’s refusals and checks on a real database in your browser, try the playground; to grade what an agent can reach on your machine, run npx deedglass scan (the grade, explained).
Written with AI assistance and checked against our claims register.