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

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:

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

Comments

[Jo Do]

Observed behavior is a strong starting point, but absence from the corpus can mean either unnecessary authority or an untested recovery path. I would compile three buckets: observed-and-allowed, observed-but-sensitive, and unobserved. The last bucket should deny by default while preserving a review route tied to the exact call. Also test policy generation with deliberately rare failure scenarios, or the first real outage may reveal that the agent lacks the one tool it needs to recover.