DEV Community

Walden Wu
Walden Wu

Posted on

The OWASP Agentic AI Top 10, read as someone who actually runs agents on his laptop

OWASP published a Top 10 for Agentic Applications in December 2025 — ten risks, numbered ASI01 through ASI10.

Most write-ups I found target platform teams. I don't have one. I have a laptop, six agents (Claude Code, Cursor, OpenClaw, DSH and a couple of my own scripts), 14 MCP servers — and a habit of giving them shell access. So here is each item translated into what I actually changed.

ASI01 — Agent Goal Hijack

Prompt injection, but the version that matters in practice is indirect: the instruction sits in a file, a web page or an issue your agent reads on the way to doing its job. The gate goes on the tool call, not the text: unauthorized tools rejected, reads of ~/.ssh and .env denied, and a list of injection signal phrases that land in the audit log.

ASI02 — Tool Misuse

The tool is fine; the arguments aren't. A delete that resolved to a root path, a write that landed on production. Judge by capability, not by tool name: the same filesystem tool is fine reading a project and not fine writing to /etc.

ASI03 — Identity & Privilege Abuse

Every agent sharing one token means that when something happens, you can't say which agent did it. Each agent gets its own keypair, and delegations narrow hop by hop: a downstream agent only ever gets a subset of what the upstream one had.

ASI04 — Agentic Supply Chain

This is the one that actually bit me. 12 of my 14 MCP servers were running unpinned — npx -y pkg@latest means the next launch runs whatever someone uploaded last. Pin versions, check MCP server origins against an allowlist at startup, and audit lifecycle hooks: a plugin "update" is a great place to hang a command that runs on every session.

ASI05 — Unexpected Code Execution

Anything that can execute code will eventually execute something you didn't intend. Mark exec capabilities separately, require approval, snapshot before execution so there is something to roll back to.

ASI06 — Memory & Context Poisoning

Content written into CLAUDE.md, AGENTS.md or a memory directory doesn't affect this session — it affects every future one. Treat memory as untrusted input. The minimum bar is noticing when it changes, which means a baseline and drift detection.

ASI07 — Insecure Inter-Agent Communication

The hard one. Cross-org A2A identity is a protocol problem and I don't pretend to solve it. What I can pin down locally: signed delegation chains, capability narrowing, one keypair per agent, so "who authorized whom" has an answer. I'd rather a security tool say plainly what it does not cover than quietly imply it covers everything.

ASI08 — Cascading Failures

One poisoned agent talks to five downstream agents, and each of them trusts the message because it came from inside. Circuit breakers that take effect on the next call, plus anomaly detection for delegation bursts.

ASI09 — Human-Agent Trust Exploitation

The agent writes a confident, plausible explanation for a destructive action and you click approve. "Read more carefully" is not a fix. Approval prompts should show the concrete action and its parameters, not the agent's own narrative; approvals should record who approved and why; a timeout should fail closed.

ASI10 — Rogue Agents

You cannot detect intent. Put the boundary on actions instead: what runs, what needs approval, what gets snapshotted — and keep records you can verify later, so "what was allowed at the time" is answerable.

Two things I took away

  1. Nearly every item reduces to the same move: put the gate at the action, not at the prompt. You can't filter text well enough; you can decide whether a specific tool call with specific arguments runs.
  2. The other half is evidence. If you can't reconstruct what the agent did and which policy was in force, you're guessing.

I've been building pod around those two ideas: pod scan (read-only, finds unpinned servers and plaintext keys), pod policy draft (compiles a least-privilege policy from what your agent actually did), pod serve (enforces it), pod verify-audit (tamper-evident evidence).

curl -fsSL https://gitee.com/suhuisoftwares/pod/raw/v0.3.2/scripts/install.sh | sh
pod scan
Enter fullscreen mode Exit fullscreen mode

The boundary, since it's a security tool: not a sandbox, doesn't see what your agents say to each other, won't stop someone who already has your shell. It sits in front of tool calls and keeps receipts.

Top comments (0)