Tag
#mcp
10 posts
-
Official-looking isn't official: how to verify who published an MCP server named after a real vendor
The first malicious MCP server in the wild, postmark-mcp, was a copy of a real vendor's code under an unrelated npm account. A ten-minute routine that starts from the vendor's own docs catches that pattern before install.
-
Skills inherit everything your agent can touch: scoping credentials and shell access per skill and MCP server
A skill or local MCP server runs with the agent's environment, files and network. The working least-privilege unit is the credential and command surface each one can reach, set in sandbox, permission and server config, not in the prompt.
-
The MCP spec's own security MUSTs, read by a buyer: five requirements to make any MCP vendor prove
The MCP spec already sets security obligations: no token passthrough, per-client consent, verified requests, exact-command consent, safe URL handling. Ask vendors to prove each, in the spec's own words.
-
Approved last month, malicious today: a re-verification cadence for MCP servers and skills
Install-time vetting decays the moment a server or skill changes. Tie every approval to an immutable version or hash, re-check on every change, and sweep on a schedule. Cadence by artifact type inside.
-
Allowlist, denylist or both? Designing MCP server policy after GitHub's enterprise allowlists
An allowlist stops servers nobody approved. A denylist stops approved servers that later turn bad. MCP policy needs both, matched on URL or command, never on name alone.
-
Lethal trifecta audit: a worksheet to find agent setups that mix private data, untrusted content and egress
Exfiltration risk comes from a combination: private data, untrusted content and a way to send data out, in one agent session. This worksheet audits each configuration for all three and shows which leg is cheapest to break.
-
Known bad, no known bad, unknown: a three-state policy model for agent artifacts
Most agent artifacts have never been checked by anyone. Splitting verdicts into known bad, checked with nothing found, and never checked lets policy block, log or ask a person without calling unreviewed code safe.
-
Do coding agents call optional security tools on their own? What the docs guarantee, and a 50-task test to run
Nothing in the MCP spec or Claude Code's docs makes an agent call a security-check tool before it installs something. The model decides. Here is why, and a pre-registered 50-task protocol to measure it on your own setup.
-
Why agent-security statistics disagree: a source-lineage audit of the MCP and skills numbers vendors quote
We traced ten widely quoted MCP and skills statistics to their origins. Most measure different things on different populations; two have no traceable source. A register with a safe-to-cite verdict for each.
-
Your agent installed a known-bad package: the first hour, including the credentials you forgot it could reach
Isolate the machine, preserve the agent's logs and configs, rotate every secret the agent could read from a clean device, check memory files and persistence, then scope. A minute-by-minute runbook.
