How do we implement OAuth scopes for MCP access?

Define fine-grained scopes in your OAuth configuration (for example, read:orders vs. write:orders), request only the scopes a given tool needs, and validate scope on every call — not just at connection time. MCP has standardized OAuth flows in its spec since the 2025-03 revision, so MCP clients can implement this consistently.

Should we worry about an agent accessing our .env files?

Yes. Coding agents can read local files, including credential files, if nothing stops them. Never put long-lived credentials in .env files or code repositories. Use a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or an OS keychain for personal use) and inject credentials at runtime — configure agent tools to ignore sensitive paths as an added layer, not the only one.

Is exposing every tool to every agent a real security problem, or just a UX one?

Both. Exposing 150 tools to every agent means broader blast radius if any single credential or session is compromised, in addition to worse tool-selection accuracy. Scoping tools by business function shrinks both problems at once.

Guide

Fine-Grained Access Control for MCP Servers

MCP servers need least-privilege scoping, not one key for everything. Patterns for scoping tools by function, short-lived credentials, real CVE lessons.

Don’t give the keys to the kingdom

The instinct with a new MCP server is to expose everything behind one set of credentials. That’s the wrong default. Fine-grained access control for MCP means the same discipline you already apply to API authorization: identity-tied, scoped access — who or what gets access to which agent capabilities, enforced per tool and per user, not granted wholesale at the server level.

Scope by business function, not by convenience

Instead of one MCP server exposing 150 tools to every agent, group tools into function-scoped servers — sometimes called virtual MCP servers, or V-MCPs. Per MintMCP’s whitepaper, this means an engineering-scoped server (source control, CI/CD, monitoring, docs), a marketing-scoped server (analytics, CMS, social), and a finance-scoped server (read-only ERP, reporting, compliance) — each exposing only the 10-15 tools relevant to that function instead of the full catalog.

This does two things at once. It’s least privilege by design — an agent acting on behalf of a finance user simply can’t see engineering’s destructive tools. And it improves the agent’s own decision quality, since it’s choosing from 15 relevant tools instead of hunting through 150.

Credential patterns that hold up

Don’t put long-lived secrets in the agent itself. The pattern that works:

OAuth on behalf of a user, with short-lived access tokens and refresh tokens held by the host application — never embedded in a prompt or stored in agent memory.
Client credentials for machine-to-machine calls, scoped and rotating, issued by an auth server.
Secrets in a vault, injected at runtime, never committed to a repo or left in a .env file.
Per-tool, per-user scoping enforced at the gateway or MCP server — “agent X acting for user Y can call tool Z,” checked on every call, not just at connection time.

MCP standardized OAuth flows in its spec as of the 2025-03-26 revision, and the current specification (2025-11-25) carries that forward — so this is no longer a build-it-yourself problem for most teams. The same governance logic applies to the broader Agent Access Stack.

The CVE reality check

MCP security concerns aren’t hypothetical. A handful of real, named vulnerabilities make the case: CVE-2025-32711 (“EchoLeak”) let hidden prompts in documents exfiltrate data without the user noticing. CVE-2025-6514, rated 9.6 on the CVSS scale, allowed remote code execution via the mcp-remote package connecting to a malicious server. CVE-2025-36852 involved malicious @nx packages scraping tokens and SSH keys through a postinstall script. A widely-installed unofficial Postmark MCP server was found silently bcc’ing all outgoing email to an attacker’s address before it was caught.

That adoption number is per a vendor whitepaper (Knostic, Jul 2025): a July 2025 scan found 1,862 MCP servers exposed to the internet — none with authentication enabled by default. Treat that adoption number as directional, since it comes from a vendor’s own paper, but the underlying pattern — MCP servers shipped without auth as a default — matches the CVE history above.

Broken Object Level Authorization (BOLA) remains the #1 item on the OWASP API Top 10 (OWASP API Security Top 10 (2023)), and it applies to MCP tool calls exactly the way it applies to REST endpoints: verify the caller has permission for the specific resource, every time, not just that they’re authenticated. That puts MCP security inside ordinary API governance, not outside it.

What’s coming next

A newer identity model for agents, called AAuth, is circulating as an individual IETF draft — not an adopted standard, and not something to build production auth on yet. It’s worth watching because it tackles a real gap (agents having their own cryptographic identity, rather than borrowing a shared client secret), but today’s production pattern is still OAuth 2.1 with scoped, short-lived tokens, enforced per tool and per user. For adjacent policy design, see governing AI gateway sprawl.

Next step

Where to take this next

Working through this with your team? Team training — a private program that gets product, platform, and engineering aligned on what to ship for agents. Learning on your own? Compare the courses.

FAQ

How do we implement OAuth scopes for MCP access?: Define fine-grained scopes in your OAuth configuration (for example, read:orders vs. write:orders), request only the scopes a given tool needs, and validate scope on every call — not just at connection time. MCP has standardized OAuth flows in its spec since the 2025-03 revision, so MCP clients can implement this consistently.
Should we worry about an agent accessing our .env files?: Yes. Coding agents can read local files, including credential files, if nothing stops them. Never put long-lived credentials in .env files or code repositories. Use a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or an OS keychain for personal use) and inject credentials at runtime — configure agent tools to ignore sensitive paths as an added layer, not the only one.
Is exposing every tool to every agent a real security problem, or just a UX one?: Both. Exposing 150 tools to every agent means broader blast radius if any single credential or session is compromised, in addition to worse tool-selection accuracy. Scoping tools by business function shrinks both problems at once.