OWASP Top 10 for Agentic Applications: A Working Checklist

OWASP published a Top 10 for Agentic Applications because the existing lists did not fit. An agent is not a web app: it plans, it acts, it holds credentials, and it takes instructions from content it fetched. The classic categories have no row for "the input was a lie and the program believed it."

This page is the list in plain language, with the question worth asking about your own setup for each one. At the end, our own graded answers, including where we are weak.

The ten, and what to ask

ASI01 · Agent Goal Hijack. Content the agent fetched contains instructions, and the agent follows them. This is the root threat: a model has no reliable boundary between data it was given and instructions it was given. Ask: is anything inspecting what comes back from a tool, or only what goes in?

ASI02 · Tool Misuse. The agent uses a tool it legitimately has in a way you did not intend. Not a forbidden tool. An allowed one, pointed somewhere else. Ask: does your policy understand the structure of a call, or match its text? If it matches text, the attacker writes the text.

ASI03 · Identity and Privilege Abuse. The agent acts with your identity and your credentials, and nothing downstream can tell the difference between you and it. Ask: can you attribute any single action to an agent, a person, and a machine? If your audit log says the action came from your username, you cannot.

ASI04 · Supply Chain Vulnerabilities. The agent's own configuration is the supply chain: MCP servers, hooks, skills, instruction files. All committed, all executable, none reviewed the way code is reviewed. Ask: has anyone read your .claude/settings.json and .mcp.json as carefully as they read a dependency bump?

ASI05 · Unexpected Code Execution. The agent runs something you did not intend, through an eval, an inline execution, or a script fetched at runtime. Ask: does your gate read the command the agent ran, or the contents of the script that command executes? Almost every tool reads only the first.

ASI06 · Memory and Context Poisoning. Something hostile lands in memory or in a long-lived context and influences the agent later, long after the moment it arrived. Ask: does anything persist across sessions, and did anyone check it?

ASI07 · Insecure Inter-Agent Communication. Agents that call other agents inherit each other's trust, and the second agent has no way to know the first one was compromised. Ask: does an instruction from another agent get the same scrutiny as one from a web page? It should.

ASI08 · Cascading Failures. One bad decision multiplies: a loop, a fan-out, a retry storm. Sometimes the damage is money rather than data. Ask: what stops an agent that is burning budget at 3am, and does anyone find out before the invoice?

ASI09 · Human and Agent Trust Exploitation. The agent asks for approval in a way that makes yes the obvious answer, or the approval channel itself is the weak point. Ask: does an approval prompt tell you what will actually happen, and can the agent influence what the prompt says?

ASI10 · Rogue Agents. An agent running that nobody sanctioned, or a sanctioned one that has slipped its policy. Ask: can you list every agent running across your machines right now? Most teams cannot.

Why a self-assessment is worth more than a vendor claim

Every tool in this space will tell you it covers the Top 10. The list is broad enough that almost anything can claim a row.

The useful exercise is the opposite one: go down the ten, and for each write strong, moderate, partial, or not covered, with the evidence next to it. The rows you cannot fill are the answer. A tool that reports ten out of ten has told you nothing about itself and something about its marketing.

Our own answers

We did that exercise on node9 and published it, including the weak rows.

4 strong      ASI02, ASI03, ASI09, ASI10
4 moderate    ASI04, ASI05, ASI06, ASI08
2 partial     ASI01, ASI07
0 out of scope

The two partial rows are the honest ones, so they belong here rather than in a footnote.

ASI01 is partial because the injection detector ships inactive, and warns rather than blocks when you enable it. Prompt scanning is real on Claude Code, Codex, Copilot CLI, OpenCode and Pi, and response scanning runs on the return path, but the specific control this threat needs is off by default.

ASI07 is partial because inter-agent traffic is the newest surface and our coverage of it is genuinely thinner than the rest.

Two of the moderate rows have gaps worth naming too. Under ASI05, node9 reads the call the agent made; it does not read the contents of a script that call runs, nor the subprocesses that script spawns. Under ASI04, the script a hook points at is not read, and skills and subagents are not pulled in.

Where we are strong is narrow and specific rather than broad: every tool call is parsed into its structure before it runs, so policy can allow one form of a command and refuse another; credential files are refused with nothing configured; and the cloud metadata address is unreachable on every door, verified on both the shell and WebFetch, with a refusal that says the address cannot be allowlisted at all.

The full per-threat breakdown with the evidence for each grade is at Agentic Threat Coverage.

Where to start

If you do one thing from this page, do ASI03 and ASI10 first, because they are the cheapest and they tell you the most:

npx node9-ai posture     # what this machine exposes, about 60 seconds
npx node9-ai scan        # which agents ran here, and what they did

You cannot threat-model agents you cannot list. Most teams discover an agent they forgot about in the first minute, and that single fact reorders the rest of the list.