Why MCP Isn’t a Security Boundary: A Builder’s Guide to Scoping

If you are treating the Model Context Protocol (MCP) as a security boundary, you are already behind.

The most dangerous misconception in internal AI tooling right now is the belief that connecting an LLM to your internal data via MCP is a secure act by default. It is not. MCP is an open standard for communication, a pipe for data and instructions. It has no built-in authentication or authorization layer. By default, any LLM connected to an MCP server has access to everything that server can touch.

This isn’t a flaw in the protocol; it’s a feature of its design. MCP is designed to be simple. It is not designed to be a vault.

As operators building resilient pipelines, we need to stop looking for magic bullets in the protocol itself and start looking at the infrastructure around it. The success criterion for MCP security is boring, but it is the only one that matters: If a token leaks, can the attacker do anything other than what was explicitly intended?

If the answer is “yes, they can delete the database,” you have failed. If the answer is “no, they can only read a specific, non-sensitive log file,” you have succeeded.

Here is how we build that success without breaking our workflows.

The Pipe, Not the Vault

We need to accept a hard truth: MCP does not secure your data. It transports it.

When you spin up an MCP server, you are creating an endpoint. If that endpoint is reachable, and if the LLM client can authenticate to it, the LLM can invoke any tool exposed by that server. There is no implicit “safe mode.” There is no default “read-only” unless you explicitly code it.

This default state is where most internal tools fail. Engineers often expose broad capabilities to make the AI “useful.” They want the agent to be able to query the database, update records, and trigger deployments. Without strict scoping, you are giving the LLM the keys to the kingdom.

The risk here is not just theoretical. A “rogue prompt” or a simple hallucination can lead to destructive actions if the underlying tools are too permissive. If an agent is given a tool to DROP TABLE because it was granted broad write access, a single bad turn in the reasoning chain can cost you hours of recovery time.

We must shift our mindset from “how do I make this tool accessible?” to “how do I restrict this tool to the absolute minimum necessary?” This is the principle of least privilege, applied not just to users, but to the AI agents themselves.

Why ‘Deny by Default’ is Non-Negotiable

The only safe starting point for any internal MCP deployment is deny-by-default.

Start with no tools enabled. Then, selectively enable them based on the user’s role and the specific task at hand. This is not just a best practice; it is a requirement for any production-grade system.

Consider the example of Retool, which provides a concrete reference for how this looks in practice. In their implementation, tools are strictly gated by scopes. A tool like retool_list_apps requires the mcp:read scope. A tool like retool_create_resource requires mcp:write. Crucially, Retool enforces that users cannot be granted scopes that exceed their account permissions. This ensures that the MCP layer respects the underlying identity hierarchy.

This is the “boring” part of security that most builders skip. We want to ship fast. We want to give the AI broad access so it doesn’t get stuck. But broad access is a liability.

If you are building an internal tool for engineering, you might grant mcp:code.deploy to developers and mcp:report.read to managers. If you are building for HR, you might restrict access to mcp:employee.lookup only for HR admins. These scopes are not just labels; they are enforcement points.

The tradeoff here is friction. Restricting access means more configuration, more role definitions, and more potential for “access denied” errors when the AI tries to help. But that friction is the price of safety. If the AI can’t help because it lacks permission, that is a feature, not a bug. It is a signal that the tool is working as intended.

Implementing Scopes and Gatekeepers

So, how do we enforce these scopes? We need gatekeepers.

MCP itself does not provide the gate. You need to implement it at the gateway level, using virtual keys or scoped tokens. This is where the distinction between session-based and token-based authentication becomes critical.

As noted in Casdoor’s documentation, session-based authentication (like cookies) often bypasses scope checking for backward compatibility. This is a trap. If you rely on cookies, you are likely granting broad access based on the user’s session, not the specific task. Token-based authentication, on the other hand, enforces fine-grained authorization.

Casdoor provides a clear example of this mapping. You can map OAuth scopes like role:read or user:write directly to specific MCP tools. When the LLM client presents a token, the gateway checks the scopes attached to that token. If the token lacks user:write, the update_user tool is simply not available. The LLM doesn’t even know it exists.

This is the key to scalable security. You are not checking permissions for every single API call. You are checking them once, at the gateway, and then enforcing them by hiding the tools that don’t belong.

PropelAuth offers a similar approach, detailing the practical implementation of Role-Based Access Control (RBAC) for MCP. They explain how to define roles (e.g., Engineering, HR) and attach granular org scopes to them. They highlight that without a gatekeeper, an LLM has access to everything the server can touch. By using decorators to restrict tool access based on required scopes, they ensure that only the right tools are exposed to the right agents.

The implementation advice here is simple: use an IAM provider to manage roles and scopes before they hit the MCP server. Do not try to build your own authorization logic inside the MCP server. Let the IAM provider do the heavy lifting.

The Enterprise Reality: Identity Boundaries

For those of us operating in enterprise environments, the story doesn’t end at the MCP gateway.

MCP secures the entry point. It handles SSO and scopes. But it does not govern downstream identity propagation. Once the MCP server makes a call to your internal database, your CRM, or your deployment pipeline, the identity of the LLM is no longer the primary concern. The identity of the service account making the call is.

ScaleKit outlines five foundations for enterprise MCP: identity boundaries, method-level governance, observability, policy enforcement, and IdP integration. The critical insight here is that MCP is just the first step.

If your MCP server calls a downstream service, that service needs its own trusted way to evaluate identity and policy. You cannot assume that because the user had permission to invoke the MCP tool, they have permission to perform the downstream action. The downstream service must validate the request independently.

This is a common failure mode. We build a secure MCP layer, but then we expose a broad API endpoint to the MCP server, assuming the MCP layer is doing the work. It is not. The MCP layer is a filter. The downstream service is the vault. Both need to be secure.

The cost of ignoring this is high. If you rely on MCP for downstream security, you are creating a single point of failure. If the MCP layer is compromised, or if the scopes are misconfigured, the downstream service is exposed. You need a defense-in-depth strategy.

Practical Steps for Builders

If you are ready to build, here is the decision framework.

First, adopt short-lived tokens. Never use long-lived API keys for MCP clients. Tokens should expire quickly, limiting the window of opportunity for an attacker if a token is leaked. Resource-specific credentials are essential. Use tokens that are scoped to the specific resource and action, not broad access to the entire system.

Second, require explicit user consent for tool invocation. This creates an audit trail and gives the user control. When the LLM wants to execute a tool, pause and ask the user for confirmation. This is not just a security measure; it is a usability feature. It ensures that the AI is acting in alignment with the user’s intent.

Third, handle token refresh in the agent loop carefully. If your MCP client relies on OAuth tokens, you must implement a robust refresh mechanism that respects the original scopes. A common gotcha is that a refreshed token might lose its narrow scope if the refresh flow isn’t explicitly configured to preserve it. Ensure your IAM provider’s refresh logic maintains the mcp:read or mcp:write constraints.

Finally, remember that MCP is a communication pipe. It is not a security boundary. Your security strategy must be built around it, not inside it.

Sources and further reading

• MCP for Internal Tools: Permissions, Scopes, and Boring Success Criteria – RodyTech Blog
• Authentication and Authorization for Internal MCP Servers | PropelAuth
• Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work
• MCP authorization and scopes | Casdoor
• MCP tools | Retool Docs