Least-Privilege Scoping for MCPs: How to Grant the Smallest Useful Permission
If you do only one thing to secure your MCP installs, scope the credentials narrowly. A read-only single-repo GitHub token is dramatically less dangerous than a full-org personal access token, regardless of how well-sandboxed the MCP is. This guide is the per-category playbook for cutting MCP credentials down to the smallest set of permissions that still let the workflow work.
Why this is the highest-leverage move
Most MCP security advice is defense in depth — sandbox the process, confirm destructive calls, audit the tool log. Those all help. But the single move with the largest impact on the blast radius of a compromise is making the credential less powerful. A leaked credential that can only read one repo is an annoying notification; a leaked credential that can write the whole org is an incident.
Least-privilege scoping is also the easiest defense to adopt. It does not require new infrastructure, a new tool, or a new process — it requires choosing a tighter set of permissions when you mint the credential. The friction is "one extra checkbox at issue time" and the payoff lasts as long as the credential does.
The scoping playbook by MCP category
Filesystem & storage
Default mistake: No allowlist (full user home) — too broad.
Tight scope: Pass only the project directory or directories the workflow needs as positional arguments. Use the OS's read-only mount during prototyping. Reject symlinks. The official Filesystem MCP enforces all three.
Databases
Default mistake: Reusing an admin connection string with full read-write to every table.
Tight scope: Dedicated database user with read-only access to the specific tables the workflow needs. Statement timeout to prevent runaway queries. Row-level security if available. For Supabase: project-scoped access token against a non-production project.
Git & GitHub
Default mistake: Classic personal access token with full repo and full workflow scope.
Tight scope: Fine-grained personal access token scoped to specific repos with the minimum needed permissions (read-only for PR review; write contents for staging commits; never include workflow scope unless the agent will actually edit CI).
SaaS (Slack, Stripe, HubSpot, Notion)
Default mistake: OAuth all-scopes token or workspace admin token.
Tight scope: Service-specific scoped tokens. Slack: bot token with only the channels and methods used. Stripe: restricted key (not the secret key) with the smallest permission set. Notion: integration scoped to a specific page tree.
Code execution & browser automation
Default mistake: Local process with full network access and host filesystem mounted.
Tight scope: Sandbox runtime (E2B for code; Playwright in a container for browsers) with no host filesystem mounts and an explicit network egress allowlist. Combine with credential scoping for any service the sandbox reaches.
A scope-design heuristic
When you mint a credential, ask three questions:
- What is the smallest action this MCP needs to take on its happy path? Start from the floor, not the ceiling.
- What is the worst thing this MCP could do if the credential is abused? If "delete every repo in the org" is on that list and the MCP only needs to read PRs, the scope is wrong.
- If this credential leaks tomorrow, what is the blast radius? If the answer is "rotate the token and move on," you scoped correctly. If the answer is "incident response," tighten further.
When tight scoping is hard
Some services make scoping easy (GitHub fine-grained tokens, Stripe restricted keys, AWS IAM). Some make it hard — coarse token scopes, no per-resource permissions, no easy way to issue a non-admin credential. For those services, your options are: (1) accept the coarse scope and compensate with sandboxing, audit, and routine rotation; (2) put a proxy in front that enforces narrower scope; or (3) push the upstream vendor to ship finer-grained tokens.
For most teams in 2026, option 1 is the realistic default — but flag the coarse-scope MCPs in your inventory so an incident response knows which credentials are the worst ones to lose.
The one rule
Never grant an MCP a credential you would be uncomfortable pasting into a public Gist for a day. If that thought experiment makes you nervous, the scope is too broad.
Frequently asked questions
What does "least privilege" actually mean for an MCP?
It means the MCP server gets the smallest set of permissions that still lets the workflow succeed. For a GitHub MCP that only reads PRs, that is a read-only token scoped to one repo — not a full-org personal access token. For a Filesystem MCP that edits source files in one project, that is the project directory — not the whole home directory. Least privilege is the difference between "an exposed credential is a problem" and "an exposed credential is a catastrophe."
How is least privilege different from sandboxing?
Sandboxing limits what the MCP host can do. Least privilege limits what the credential can do upstream. A perfectly sandboxed GitHub MCP with a full-org token is still a full-org compromise waiting to happen. A perfectly scoped read-only single-repo token in an unsandboxed MCP is much less dangerous. Do both, but if you have to pick one, scope the credential — credentials are reusable across hosts; host access is one-shot.
What does least-privilege look like for a Filesystem MCP?
Pass only the directories the workflow needs as command-line arguments — never your home directory, never your whole disk. Use the OS's read-only mount option during prototyping. Reject symlinks to prevent path traversal. The official Filesystem MCP supports all three.
What does least-privilege look like for a database MCP?
Issue the MCP a dedicated database user with read-only access to the specific tables it needs. Use row-level security if your engine supports it. Set a statement timeout so a SELECT * on a billion-row table cannot bring the database down. The Postgres MCP is read-only by design; for Supabase, scope the access token to a non-production project for any agent-driven conversation.
What does least-privilege look like for a SaaS MCP (Slack, Stripe, GitHub)?
Use the upstream service's scoped tokens. Slack bot tokens with only the channels and methods the workflow needs. Stripe restricted keys (not the secret key) with the smallest set of permissions. GitHub fine-grained personal access tokens scoped to specific repos with specific permissions — not classic tokens with full repo scope.
How often should I review MCP scopes?
When you add an MCP, audit the scope before you trust it. Every quarter, audit your installed MCPs and ask "does this still need this scope, or has the workflow changed?" Scopes drift over time — workflows shift, but tokens keep their original (often overbroad) scope until someone notices.
Related: MCP Security overview · Sandboxing MCP servers
More guides
Fundamentals
What Is MCP? A Plain-English Guide to Model Context Protocol
6 min read
Setup Guide
Best MCPs for Cursor in 2026 (Ranked + Setup)
8 min read
Setup Guide
Best MCPs for Claude Desktop in 2026 (Ranked + Setup)
9 min read
Setup Guide
Best MCPs for Claude Code in 2026 (Ranked + Setup)
8 min read
Setup Guide
Best MCPs for Windsurf in 2026 (Cascade-Ready Setup)
8 min read
Setup Guide
Best MCPs for VS Code in 2026 (Agent Mode + .vscode/mcp.json)
8 min read
Strategy
MCP Registry vs Curated Directory: Which Should You Use?
5 min read
Setup Guide
Best MCPs for ChatGPT: The Apps and Connectors Worth Installing
9 min read
Tutorial
How to Add an MCP Server to ChatGPT (Developer Mode + Apps Directory)
7 min read
Security
MCP Security: What to Know Before You Install
9 min read
Role Guide
Best MCPs for Marketers in 2026 (SEO, Email, Analytics)
8 min read
Strategy
Remote vs Local MCP Servers: When to Use Each
7 min read
Fundamentals
MCP vs Function Calling: What’s the Difference?
6 min read
Comparison
MCP Directories Compared: Top MCPs vs mcp.so vs PulseMCP vs mcp.directory
8 min read
Security
MCP Prompt Injection: How Tool-Calling Agents Get Hijacked
8 min read
Security
OAuth 2.1 for MCP: What the Spec Standardised and What You Need to Know
8 min read
Security
Sandboxing MCP Servers: Containers, Least Privilege, and Process Isolation
9 min read
Security
Rotating MCP Credentials: A Practical Guide for Leaks, Expiry, and Routine Hygiene
7 min read
Setup Guide
Best MCP Servers for Databases in 2026 (Ranked + Setup)
10 min read
Setup Guide
Best MCP Servers for Research in 2026 (Search, Scrape, Synthesize)
9 min read
Setup Guide
Best MCP Servers for Design-to-Code in 2026 (Figma → React)
9 min read
Setup Guide
Best MCP Servers for Domains in 2026 (Registrars + DNS)
9 min read
Tutorial
How to Buy a Domain From Claude (Cloudflare MCP, Step by Step)
6 min read
Tutorial
How to Search for Domains With an AI Agent (Cross-Registrar Workflow)
7 min read