Scope MCP Access to Least Privilege

A security discipline for MCP: grant each connected server the narrowest access that its job actually requires — read-only when you won't be writing, scoped to specific directories or datasets, no destructive capabilities it doesn't need. The connection's permissions should match the task, not the maximum the server can offer.

An MCP server gives Claude real power over real systems — files, databases, APIs. That power is exactly what makes it useful and exactly what makes over-broad access risky: a misread instruction, a confused tool call, or a compromised server operates with whatever access you granted. Least privilege shrinks the blast radius of any mistake to something you can live with. Read-only access can't corrupt data; a directory-scoped server can't touch what's outside it. You keep the capability you need while removing the capability to do harm you never intended.

Every time you connect an MCP server, especially to anything with real data or side effects: production databases, filesystems, deployment tools, anything that can write, delete, or send. Default to the least access, then widen only if a task genuinely needs it.

There isn't really a 'skip this' case — but be pragmatic on throwaway local sandboxes with no sensitive data, where tight scoping is lower stakes. Never treat production or shared systems that way.

I'm connecting this MCP server: <what it does>. The tasks I actually need Claude to do with it are: <list>. What is the minimum access that covers exactly those tasks — read vs write, which scopes/paths/tables — and what capabilities should I explicitly withhold? Flag anything about the default setup that grants more than I need.

You connect a database server so Claude can help analyse data. Rather than handing over a read-write admin connection, you give it a read-only role scoped to the analytics schema. Claude can explore and summarise freely, but a garbled query can't drop a table or mutate a row — the capability that would let it do damage simply isn't there.

Separate concerns across connections: a read-only server for exploration and a tightly-scoped, human-confirmed path for the rare writes you do need, rather than one broad read-write connection for everything. Pair this with tools that require confirmation for destructive actions, so the dangerous operations are both narrowly scoped and explicitly gated.

• Granting read-write admin access because it's the default, when the task only ever reads.
• Connecting a server to production data 'to test it' without scoping — the test is where accidents happen.
• Trusting a third-party MCP server with broad access without vetting what it actually does with it.