"Covered" is the most abused word in security marketing. When a vendor says they cover a threat framework, it can mean almost anything: that they have a system prompt asking the model to behave, that a checklist has a green tick next to a row, or that there is a control that actually fires when the threat happens. The OWASP Top 10 for Agentic Applications 2026 (ASI01 through ASI10) is new enough that a lot of the coverage claims being made against it are the first kind. This post is about what we mean when we say we cover it, and the rows where we deliberately stop short of the word.
Two places a control can live
An agentic threat can be answered in one of two places. You can answer it at the prompt layer, by telling the model what not to do, or you can answer it at the action layer, by governing what the agent is actually allowed to do once it has decided. These sound similar and they are not. A prompt-level guard defends from inside the context an attacker is trying to poison. An action-level control sits underneath the reasoning, watching the syscalls, the tool calls, and the process tree, none of which can be talked out of a decision they have already committed to.
We have argued this at length before: the reason enforcement has to live below the model is that the model's refusal is a prediction, and predictions can be steered. Denied is denied makes the case that the operating system's Operation not permitted is a different species of no than the model's. The OWASP mapping is where that principle gets spent across ten specific risks.
What the mapping actually is
Our coverage matrix lists every ASI category next to the control that answers it and a label saying how far that control goes. The everyday work is done by screening: every command, argument, and tool response the agent proposes runs through prompt-injection detection and the agent threat rules before it is allowed to proceed. That is what catches Agent Goal Hijack (ASI01), and it is where the credential-read and privilege signals for Identity & Privilege Abuse (ASI03) surface, as detection rather than identity management.
The strongest rows are enforced in the kernel, not just detected: Unexpected Code Execution (ASI05) and the host actions of Rogue Agents (ASI10), with the execution side of Tool Misuse & Exploitation (ASI02) refused there too. For these the Linux Execution Gate, an eBPF LSM program, refuses an unauthorized exec before a single instruction runs. A jailbroken agent can decide to launch a reverse shell or a miner; it cannot make the kernel carry out the launch. Per-pod containment sits on top of per-tenant attribution read from the cgroup, which the agent cannot spoof because it never touches it, limiting how far one compromised agent can reach.
The reason chain: why a deny knows what it caught
The part that makes this a mapping rather than a coincidence is the reason chain. When a verdict is produced, the agent-security-incident logic (in asi.rs) traces the decision path and tags the outcome with the OWASP Agentic ids it corresponds to. So a deny does not just say no, it returns something like ["ASI05"] for a reverse shell alongside the decision. Your security team sees the block in the framework they already evaluate against, and the evidence trail shows which risk class fired and why, not a bare boolean. A signal with no honest ASI home returns none rather than being force-fitted to a row.
Where we stop short of the word
Honesty is the whole point, so here is the caveat we print on the page itself: four rows are architectural rather than runtime, and a host guardrail only goes so far on them. Agentic Supply Chain Vulnerabilities (ASI04) is a place we mitigate impact, not validate provenance: we ship no SBOM, no signature checking, no registry control, so if a compromised component tries to run a payload the Execution Gate stops it, and that is all we claim. Memory & Context Poisoning (ASI06) is limited and indirect: we do not detect poisoned RAG or memory stores. Insecure Inter-Agent Communication (ASI07) is supporting containment, not message authentication. Human-Agent Trust Exploitation (ASI09) only counts when the approval carries independent evidence and an audit trail, not a bare "approve?" A green row that overstates what runs is worse than an amber row that tells the truth, because the first one fails silently on the day you needed it.
The other line worth drawing: kernel enforcement is Linux-only. The Execution Gate that makes the execution rows unbypassable is an eBPF LSM program, and eBPF LSM is a Linux facility. Screening, redaction, the circuit breaker, and the reason chain all work cross-platform, but the kernel refusal does not exist on Windows or macOS today, and we do not pretend otherwise. On those platforms an agent that respects the verdict is guarded; the deepest layer, the one an uncooperative agent cannot argue with, is the Linux one.
Observed and enforceable, with evidence
So when we say a category is covered, we mean the risk is observed at the action layer and, for the enforcement-critical ones, enforceable there too, with a logged decision that names the risk class it belongs to. That is a narrower and stronger claim than a prompt-level promise. A promise asks the model to cooperate. An action-layer control does not need the model's cooperation, because it sits where the cooperation is no longer required.
Be measured about the difference between proven and designed. The kernel refusal is proven: there is a real, unedited recording of the Execution Gate refusing a live attack on the proof page, same binary, runs fine on the host, refused inside the agent's scope. The full coverage matrix, with every row and how far its control goes, lives on the OWASP Agentic Top 10 page. Read it as a claim you can check, because that is the only kind worth making.
This is an independent mapping to the OWASP Top 10 for Agentic Applications 2026. InnerWarden is not endorsed or certified by OWASP.