Copied!
Blog

You’re installing MCP servers nobody has audited. Here’s how not to get burned

An MCP server runs with your permissions and feeds text straight into your AI. Seven mistakes that are easy to make, and the five-minute fix for each.

← Blog
A person using a laptop and a smartphone at a table
Photo on Unsplash

September 29, 2026

MCP security

Somewhere in your config right now is a line that downloads a stranger’s code and gives it access to your files, your tokens or your accounts. You pasted it from a README in ten seconds.

MCP is a wonderful idea and an underexamined attack surface. A server does two things that matter for security: it runs with whatever access you gave it, and everything it returns is text your AI will read and may obey. Most bad outcomes come from ordinary, avoidable mistakes, not exotic exploits.

Here are seven we’d fix first. None takes more than a few minutes.

Transparency: we operate an MCP server ourselves, which is exactly why we think about this. These are general practices, not a claim that any particular server is unsafe.

In this list
  1. Installing whatever the README says
  2. Giving it your real, full-power token
  3. Pointing the filesystem server at your whole drive
  4. Trusting whatever text comes back
  5. Never reading the tool list
  6. Running everything on auto-approve
  7. Letting the list grow forever

01 Installing whatever the README says

A one-line npx command downloads and runs code. Check who publishes the package, how widely it’s used and when it was last updated. A star count is not an audit.

02 Giving it your real, full-power token

If a server needs an API key, make a dedicated one with the fewest scopes possible. Read-only whenever the job allows. If it leaks, the damage stays small.

03 Pointing the filesystem server at your whole drive

Scope it to one project folder. “Home directory” is how a coding assistant ends up reading your SSH keys and your tax documents.

04 Trusting whatever text comes back

Web pages, emails and documents can contain instructions written for an AI, not for you. This is called prompt injection. When an assistant can both read untrusted content and take actions, treat any action that follows an unexpected read with suspicion.

05 Never reading the tool list

A server’s tool descriptions are instructions the model reads. Open the list, see what each tool can do, and be uneasy about anything that can send, delete or pay without asking you.

06 Running everything on auto-approve

Approval prompts are annoying and are also the last line of defense. Keep confirmations on for anything that writes, sends or spends. Auto-approve the safe reads and nothing else.

07 Letting the list grow forever

Every extra server is more surface area and more noise for the model to pick from. Audit your config monthly and delete what you haven’t used.

The five-minute checklist: dedicated token with minimum scopes, read-only where possible, scoped folders, confirmations on for writes, and a config you can read top to bottom. And prefer hosted servers with clear documentation about what they store; ours is here.