DEV Community: Walden Wu

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

Walden Wu — Thu, 17 Sep 2026 11:49:18 +0000

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

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.
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

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.

I scanned my own laptop: 6 AI agents, 14 MCP servers, 12 unpinned, 5 plaintext keys

Walden Wu — Thu, 17 Sep 2026 06:51:07 +0000

I have six AI agents installed on one laptop: Claude Code, Cursor, Codex, OpenCode, OpenClaw and DeepSeek Harness. Between them they run 14 MCP servers.

I wrote a read-only scanner to answer a question none of them could answer on their own: what can all of my agents touch, together?

It finished in 0.19 seconds. This is what came back.

Finding 1: 12 of the 14 MCP servers are unpinned

context7   -> npx @upstash/context7-mcp                (unpinned)
playwright -> npx @playwright/mcp@latest               (@latest)
github     -> npx @modelcontextprotocol/server-github  (unpinned)
... 12 in total

Every npx -y <package> is a supply-chain decision. @latest means the code that runs at startup is whatever was published to npm most recently — not the version you tested. My GitHub MCP server holds a personal access token and pulls @latest on every start.

This is not theoretical. 2025 already had real malicious MCP packages on npm harvesting .env files.

Finding 2: five API keys sit in plaintext in agent config files

Location	What
`~/.dsh/mcp-manager.json`	GitHub token x2
`~/.codex/config.toml`	OpenAI key
`~/.cursor/mcp.json`	GitHub token
`~/.config/opencode/opencode.json`	OpenAI key

The scanner masks values and never prints them. But the values are there, in plaintext, on disk.

Any process — or any agent — that can read those files has my GitHub and OpenAI accounts. This is close to the default configuration on most developer machines right now.

Finding 3: six agents, no inventory

Cursor knows its own permissions. OpenClaw knows its own. Nothing answers "what can all of my agents do together?" That is the shadow-agent problem, and it is why the scan report matters more than any single finding in it.

What I changed

Pin versions. npx -y pkg@1.2.3, never @latest.
Move secrets to a keychain. Tokens out of agent config files and into a system keychain or secret manager.
Put a gate in front of tool calls. A policy layer that denies sensitive paths, blocks secret output, and hash-chains every call for audit.

Run the scan yourself

Read-only, offline, nothing uploaded, secrets masked in the report:

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

Apache-2.0. Local-first.

Repo: https://gitee.com/suhuisoftwares/pod (mirror: https://github.com/suhui-organization/pod)
Site: https://podsec.vercel.app

The numbers come from a real scan of the author's machine (first scan 2026-09-01, re-confirmed 2026-09-12). No key values are published — run pod scan to get your own.

I scanned 14 MCP servers on my laptop, then compiled a least-privilege policy from what my agent actually did

Walden Wu — Thu, 17 Sep 2026 02:55:37 +0000

I run six agent platforms on one laptop. Between them they have 14 MCP servers configured, 12 of them unpinned (npx -y pkg@latest), and five plaintext API keys sitting in config files. I only knew that after writing a read-only scanner.

That scanner turned into pod. The piece I care about is the middle step that most existing tooling skips:

record    run your agent through pod in record-only mode for a few days
compile   pod policy draft  -> least-privilege rules from real observed calls
enforce   pod serve         -> deny > approve > allow, fail-closed
prove     pod verify-audit  -> SHA-256 hash chain you can hand to someone else

Gateways give you a place to enforce rules you write by hand. Scanners tell you what is exposed. pod writes the rules from behavior — read_file gets denied because it touched .env exactly once out of 214 calls, and tools that never appeared in the corpus are simply not granted.

Two things that make it different in practice:

The evidence is independently verifiable. Every call goes into a hash chain; pod export-evidence produces a bundle anyone can verify without trusting me or the host. Sensitive content is stored as hashes only.
You own the rules. Thresholds, regexes, severities and trusted sources live in ~/.pod/rules.json. Invalid rules fail closed instead of silently falling back to defaults.

There is also a control-plane side most tools ignore: lifecycle hooks, frozen config, agent identities, delegation chains, memory-file drift. All of it lands in the same audit chain.

Install (macOS/Linux, builds from source)

curl -fsSL https://gitee.com/suhuisoftwares/pod/raw/v0.3.2/scripts/install.sh | sh
pod scan        # read-only, no network

Apache-2.0. Local-first: policies, audits and secrets stay on your machine; the optional cloud control plane is in the same repo.

Honest boundaries

The threat model is explicit: no sandboxing, no A2A/mTLS protocol implementation, and no behavioral-drift-as-primary-defense. If you need those, this is not the tool.

Repo: https://gitee.com/suhuisoftwares/pod (mirror: https://github.com/suhui-organization/pod)

Website: https://podsec.vercel.app

I would especially like feedback on the compile step: whether the observed-behavior-to-policy mapping is too coarse for real workflows, and where it produces obviously wrong rules.