DEV Community: Walden Wu

I counted what my AI agents can actually touch: 16 MCP servers, 164 tools, 15 denials

Walden Wu — Sat, 19 Sep 2026 13:12:41 +0000

Every AI project eventually hits the same question, and it never comes from engineering:

"What can your agent actually touch?"

Usually it is a client, an auditor, or whoever signs the risk acceptance. And the honest answer is often "let me get back to you", because the answer is spread across a dozen config files and a tool list nobody ever wrote down.

I run several agent harnesses on one laptop. So I measured it, on my own machine, and I am writing down the procedure — including the parts that did not work.

1. Enumerate, don't describe

The install instructions are the source of truth, and almost all of them say npx -y <name>.

On my machine: 16 MCP servers, of which 12 are launched through a package manager, and all 12 are unpinned.

The split matters:

4 say @latest outright — chrome-devtools-mcp@latest, @playwright/mcp@latest, @upstash/context7-mcp@latest, superpowers-mcp@latest
8 have no version string at all — firecrawl-mcp, mcp-server-kubernetes, gitee-mcp-server, @edjl/docker-mcp, and so on

The second group surprised me more. @latest at least reads like a moving target. A bare package name reads like a stable dependency, and it resolves exactly the same way: whatever landed on the registry this morning.

2. Ask the servers what they expose

Listing tools is a separate step, because it starts processes. That distinction matters: a config parse executes nothing, an enumeration executes the servers.

That step produced 164 tools across 12 servers. The distribution was not what I expected: chrome-devtools 29, firecrawl 25, playwright 25, kubernetes 23, gitee 20, filesystem 14, docker 10, memory 9.

Kubernetes and Docker are what made the number real for me. A browser automation tool with 25 tools is one thing. kubectl verbs are another.

3. Compile a policy, with reasons

I compiled the inventory into a three-state policy: allow 43, approve 106, deny 15, plus 24 that came back as "the capability cannot be inferred" — those get flagged for a human instead of decided.

The 15 denials are the obvious ones: kubectl_delete, uninstall_helm_chart, docker_remove, three delete_* tools in the memory server, node_repl js, js_reset, playwright browser_drop.

The part that makes this worth writing about: the classifier is a keyword matcher, so it is wrong in both directions. It denied resolve-library-id because its description matched the word "format". It denied sequentialthinking because the description contained "clear".

Both stay visible in the output. Every verdict prints the phrase it matched. A policy that hides its reasons cannot be corrected — including by the person who wrote it.

4. Hand over something someone else can check

The last step is the one people skip, because it feels like extra work: shipping a delivery that the recipient verifies without trusting the sender.

Hashes are recomputed on the reader's side — in a browser, or with a standard-library script. Not because I expect to be distrusted, but because "trust me" does not survive being asked a second time by someone who does not know you.

What I am not claiming

Unpinned is not the same as compromised. The point is narrower: you cannot tell the difference after the fact, because the artifact you approved is not the artifact that runs next time.
Name and description matching says nothing about implementation. It ranks what to review; it does not review it.
Four of my 16 servers could not be enumerated at all (one exits on initialize, three are remote and time out). I still do not know what they expose. Unknown is not safe, and nothing in my setup was telling me the difference.

Do it on your own machine

Two numbers are enough to start: how many servers, how many pinned. If the second one is zero, you are in the same place I was this morning.

I wrote the tool I used for this — read-only, and it executes nothing until you explicitly ask it to enumerate: https://podcloud.dlszjr.com

Agent forensics in five minutes: what it did, and proof the log wasn't edited

Walden Wu — Fri, 18 Sep 2026 02:42:40 +0000

An agent incident ends one of two ways.

Without an audit trail, you guess: what it did, when, with which arguments, under which policy, approved by whom. With a hash-chained audit, five minutes gets you a full timeline — and a way to show the timeline itself hasn't been edited since.

I run agents on my own laptop (Claude Code, Cursor, OpenClaw, DSH), so I've had this happen. Here is the whole runbook, on real output.

The script: 01:40, an agent tries to delete a file

A real call from my machine — the policy stopped it:

$ pod timeline --since 2h --tool delete_file

2026-09-01 01:40:08  [deny   ] delete_file        filesystem   agent=openclaw-main  args=cb1533f3… pol=0.1.0  reason=tool "delete_file" is denied on "filesystem"  blocked
~~~

Three seconds to read three things: **who** (openclaw-main), **what it wanted to do** (delete_file), **why it didn't happen** (policy deny, with the policy version in force at that moment — 0.1.0).

## Step 1 — replay the timeline (2 minutes)

~~~bash
pod timeline --since 2h                       # everything, last two hours
pod timeline --since 24h --tool write_file    # only writes
pod timeline --agent openclaw-main            # only one agent
~~~

Every row carries: time / tool / server / agent / **argument hash** / decision / outcome / approver / **the policy version in force**. Arguments are stored as hashes only — during an incident that means you don't leak more than you have to, while still being able to prove the call happened.

## Step 2 — prove the log wasn't touched (1 minute)

~~~plaintext
$ pod verify-audit

## openclaw-main/filesystem.jsonl
- status: hash chain intact
- entries: 8
- head hash: f7a56fb90350…
- tail hash: 06f31666c4e8…

conclusion: every record verifiable, none modified
~~~

Each record locks in the hash of the one before it. Edit any historical entry and verification fails immediately. That's a stronger claim than "the log shows it": it's "the log itself wasn't edited after the fact".

## Step 3 — package the evidence (2 minutes)

~~~console
$ pod export-evidence
evidence bundle: ~/.pod/evidence/pod-evidence-2026-09-01.json
  audit files: 1 | policy snapshots: 1
  top-level hash: 9f9e6ed35ed1c0b9…
  one-page report: ~/.pod/evidence/pod-evidence-2026-09-01.json.md

$ pod verify-evidence --out ~/.pod/evidence/pod-evidence-2026-09-01.json
✅ evidence bundle valid (top-level hash matches, nothing modified)
~~~

One file to hand over: the audit, **the policy snapshot that was in force**, the self-check result, and a top-level hash. Whoever receives it can verify the bundle themselves — no need to trust your machine.

## Optional: cross-agent evidence in the cloud

~~~bash
pod sync
~~~

The control plane lives in the same Apache-2.0 repo (`bash deploy/install.sh`). The data direction is one-way: only SHA-256 hashes go up, the audit text stays on your machine, and the cloud being down doesn't affect local enforcement.

## Why a hash chain instead of plain logs

| | Plain log | pod hash-chained audit |
|---|---|---|
| Records the call | yes | yes |
| Records raw arguments | yes (that's the leak surface) | no — hash only |
| Records the policy version in force | no | yes |
| Provable that nobody edited it | no — anyone can edit a log | yes — one edit breaks the chain |
| Portable, verifiable evidence bundle | no | yes |

Not every agent behaves. The audit's job is narrower and more useful: what it did, it can't deny.

Install (v0.3.2):

~~~bash
curl -fsSL https://gitee.com/suhuisoftwares/pod/raw/v0.3.2/scripts/install.sh | sh
pod init --template baseline
pod serve --agent <name> --server <name> --policy ~/.pod/policies/baseline.json --command <cmd>
~~~

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.