You added an MCP server to your AI assistant. Did you check what it can touch?

MCP servers give your AI assistant new abilities: read your filesystem, query your database, call an API, run a shell command. That is the whole point of them. It is also the whole point of the risk.

The permission question nobody asks

When you install a normal browser extension, you at least see a permission prompt. When you add an MCP server to your AI coding assistant, you usually do not. You add a config entry, restart, and the assistant now has whatever access that server exposes. Most people never read the server's source to see what that actually is.

This matters more with AI-built or AI-suggested MCP servers specifically. If the assistant wrote the server for you, or you copied one from a repo you have not read closely, you have no independent confirmation of what it does versus what its description says it does.

What tends to go wrong

Three patterns show up repeatedly:

1. A server meant to read files ends up with write access too, because the broader permission was easier to implement and nobody scoped it down.
2. A server that talks to an external API embeds a credential directly in its config or source, so anyone who can read the server's files can read the key.
3. A server built for local development gets pointed at a production database or production credentials once it "works," without a second look at what commands it now accepts.

None of this requires anyone to be careless in an obvious way. It is the same gap as any fast-shipped code: the server works, so it ships, and the access-scoping step that would normally happen in review gets skipped because there was no review.

A practical check before you trust an MCP server

Before you add an MCP server to a live setup, or before you point an existing one at anything real:

1. Read what the server can actually do, not just its stated purpose. Check the tool definitions it exposes, not the README.
2. Check where its credentials live. A server that needs a database password should not have that password sitting in plaintext in its own repo.
3. Scope permissions to the minimum the task needs. A read-only use case does not need write access, even if write access was easier to build.
4. Treat any MCP server you did not write yourself the same way you would treat a new dependency: know what it can reach before you grant it that reach.

If you want a second check on what a repo, including one holding an MCP server, actually exposes in its history and current config, RepoFortify scans for exactly this kind of overlooked access. Free to try, no install required.

The convenience of an assistant that can just do things is real. So is the fact that "can just do things" is a permission grant, whether or not anyone treated it like one.

Comments

[Mads Hansen]

The distinction between advertised tools and effective reach is crucial. A read-only tool schema is not a security boundary if every handler runs in one process that holds a production write credential, a writable filesystem mount, and unrestricted egress.

A useful review artifact is a per-tool capability matrix with four columns: declared operation, credential/role used, reachable resources, and observable side effects. Then test it from the outside: run the server in a deny-by-default container, allow only the expected paths and hosts, invoke every tool with hostile inputs, and verify that denied filesystem, network, and database operations actually fail. This catches shared helper code and subprocess behavior that the tool definition cannot reveal.

Where possible, mint short-lived credentials per invocation or per capability rather than giving the whole server one ambient secret. That makes least privilege enforceable at execution time, not just descriptive in the README.