Benjamin Tanner

Every MCP server you add to your coding agent runs with your permissions, and its tool descriptions go straight into the model's context. Easy to forget when you just want a tool to work. A simple checklist before adding one: - read the tool descriptions, not just the README - check what it can touch: files, shell, network - start with read-only tools, add write access only when you need it I'm starting this account to share how I lock down my own AI coding setup. Practical, defensive, no hype. What's the first thing you check before adding an MCP server?

Your coding agent writes code that works. That doesn't mean it's safe. The risky bugs usually aren't exotic. They're the boring ones: a missing auth check on an endpoint, a secret in a config file, user input going straight into a query. Agents tend to optimize for "it runs". Nobody asked them about the unhappy path. One habit that helps: when a feature is done, open a fresh session and ask the agent to review the diff like an attacker would and list every input it shouldn't trust. Then check that list yourself. I'm here to share what I find while securing my own AI-built code. Practical, defensive, no panic.

A sandbox only protects you from what runs inside it. A recent Claude Code advisory shows where that line gets thin. CVE-2026-88968: on macOS, code running in Claude Code's Bash sandbox could swap a workspace folder for a symlink right after the Edit tool checked the path. The Edit tool runs outside the sandbox, so it could end up overwriting a user-writable file outside your workspace. The catch: an attacker first needs code running in the sandbox, for example through a malicious repo or a dependency script. Fixed in 2.1.251. If you're on auto-update, you already have it. If you update manually, run claude --version. The bigger lesson: opening an untrusted repo with an agent is close to running its scripts. Treat it that way.

A GitHub issue was enough to start a chain that could have reached OpenAI's official Codex npm package. Depi published the write-up this week. The entry point wasn't exotic: an issue-labeling workflow passed the issue title and body straight into a Codex prompt, with allow-users set to "*". Anyone who could open an issue could talk to the agent. OpenAI has fixed it. The lesson applies to any repo running an AI agent in CI: - treat issue, PR and comment text as untrusted input, never as instructions - don't let just anyone trigger the agent: limit allow-users to maintainers - give the job the smallest token permissions it needs, and keep secrets out of jobs that read untrusted text If your agent can read it, assume an attacker can write it.