Why Your Internal MCP Server is a Security Liability (And How to Fix It)

The Pipe, Not the Vault

We need to stop treating the Model Context Protocol (MCP) as a security boundary. It isn’t. It is a communication pipe.

When we integrate MCP into our internal tooling, the default assumption is often that the protocol itself provides the necessary guardrails. This is a dangerous misconception. By design, MCP is an open standard for communication, not security. It lacks a built-in authentication or authorization layer. If you rely on the protocol to keep your data safe, you are relying on a pipe, not a vault.

The operational reality is stark: by default, any connected LLM has access to everything the MCP server can touch. There is no implicit trust boundary. If your MCP server can read a database, the LLM connected to it can read that database, provided it has the token. If your server can write to an API, the LLM can write, provided it constructs the right prompt.

This distinction is not academic; it is the difference between a resilient pipeline and a data breach. We must shift our mental model from “securing the connection” to “containing the blast radius.” The protocol handles the transport; we handle the trust.

The Boring Success Criterion

In the rush to adopt LLM agents, we often get lost in the complexity of prompt engineering and model selection. We ignore the boring, critical question of authorization. I propose a simple, unglamorous success criterion for any internal MCP deployment:

If a token leaks, can the attacker do anything other than what was explicitly intended?

If the answer is “yes, they can do everything,” you have failed. This criterion shifts the focus from abstract security postures to concrete containment. It forces us to ask: What is the minimum set of actions this token must perform?

Consider the failure mode of over-permissive tokens. If an attacker intercepts a token with broad scopes, they don’t just read data; they might trigger workflows, modify configurations, or exfiltrate sensitive records. The “boring” success criterion demands that we design our systems so that even in the event of a leak, the attacker’s capabilities are strictly bounded by the principle of least privilege.

This means rejecting the idea that “good enough” security is acceptable for internal tools. Internal tools are often the weakest link because they are built quickly and secured loosely. But in the context of MCP, where LLMs can dynamically invoke tools, the risk surface expands exponentially. A token that allows “read-only” access to a CRM might still allow an LLM to infer sensitive customer relationships through pattern matching. The success criterion forces us to define “read-only” not just as a permission flag, but as a functional constraint on what the LLM can actually achieve with that data.

Identity Boundaries and SSO

MCP governs the first interaction, but it does not define how identity propagates to downstream services. This is a critical gap that many implementations overlook.

When an enterprise deploys MCP, it typically treats it as a new access surface requiring Single Sign-On (SSO), Role-Based Access Control (RBAC), and compliance integration. The MCP server secures the entry point by verifying the user’s identity via SSO. However, once that identity is established, the protocol does not dictate how that identity is passed to the tools the LLM invokes.

This creates a propagation problem. If an MCP method triggers downstream behavior—such as querying a database or calling an internal API—the next service needs its own trusted way to evaluate identity. If the MCP server simply passes the user’s session token downstream without transformation or validation, you are exposing your downstream services to the same risks as the MCP layer.

Enterprises must evaluate MCP not just as a tool interface, but as a component of their broader identity infrastructure. This requires tight integration with enterprise Identity Providers (IdPs). The MCP server should not be the source of truth for permissions; it should be a consumer of them.

For example, if a user authenticates via SSO, the MCP server should validate that the user has the necessary roles to access specific tools. But that validation must be explicit. The MCP server should not assume that because the user is logged in, they have permission to use every available tool. Instead, it should enforce method-level governance at the gateway level. This ensures that the identity established at the entry point is correctly mapped to the permissions required for each specific tool invocation.

Practical Scoping Strategies

To implement the boring success criterion, we need concrete scoping strategies. The goal is to minimize the impact of any single token or prompt injection.

Deny by Default

Start with no tools enabled. This is the most effective way to prevent accidental exposure. Only enable tools based on explicit role requirements. If a user does not need a specific tool, they should not have access to it. This reduces the attack surface significantly.

Scoped Tokens and Virtual Keys

Use virtual keys or scoped tokens that enforce permissions at the gateway level. These tokens should be short-lived and specific to the task at hand. For example, a token for a data analysis tool should not have write access to the production database. It should only have read access to the specific tables required for the analysis.

Role-Based Scoping

PropelAuth recommends defining roles (e.g., Engineering, HR) and attaching granular scopes to each role for internal servers. This allows you to map organizational departments to specific MCP scopes. For instance, an Engineering role might have access to deployment tools, while an HR role has access to employee records. This ensures that users only see the tools and data relevant to their job function.

Minimum Scope Requests

The Supabase community has highlighted the friction of over-permissive OAuth flows in MCP. They argue for dynamic scope calculation where the client requests only the minimum scopes required by the active tools. This approach reduces the risk of credential leakage and simplifies the user experience by avoiding the need for broad, static permissions that are often unnecessary for specific tool interactions.

Enforcing Permission Limits

Retool enforces that users cannot be granted scopes exceeding their existing account permissions. For example, only organization administrators can select the mcp:admin scope. This ensures that the MCP layer respects the existing hierarchy and permissions of the underlying system. It also highlights the importance of object-level visibility, ensuring users only see apps and resources they are permitted to access.

Mitigating Prompt Injection and Credential Leaks

Even with strict scoping, prompt injection remains a significant risk. An attacker might craft a prompt that tricks the LLM into invoking a tool it shouldn’t. To mitigate this, we need to treat the MCP server as the security boundary.

Short-Lived Tokens

Use short-lived tokens and resource-specific credentials to reduce exposure windows. If a token is stolen, it should expire quickly, limiting the time an attacker has to exploit it. This is particularly important for tools that interact with sensitive data or critical infrastructure.

Explicit User Consent

Implement explicit user consent for tool invocation to create an audit trail. This not only provides transparency but also allows users to review and approve actions before they are executed. This is especially important for high-risk operations, such as deleting data or modifying configurations. However, for high-frequency internal tooling, explicit consent can become a friction point. In those cases, rely on strict scoping and gateway-level validation rather than user intervention.

Treating the Server as a Critical Component

The MCP server runs with the privileges of its host process, making it a critical security boundary. Any compromise of confidentiality or integrity in the MCP server is in scope. This means we must apply the same security rigor to the MCP server as we do to any other critical service.

Static Analysis

Use static analysis tools like CodeQL to help identify vulnerable patterns in MCP server code. This can help catch issues early in the development process, before they reach production. It also ensures that the code adheres to security best practices and does not introduce new vulnerabilities.

Conclusion: Building for Boring Success

MCP is moving from local experiments to real enterprise workflows. As we integrate it into our pipelines, we must prioritize security not as an afterthought, but as a foundational element of the design.

Security is not a feature of the protocol; it is a feature of the implementation. We must focus on least privilege, short-lived tokens, and clear identity boundaries. We must reject the idea that convenience should come at the cost of security.

If your success criteria are boring, you’re probably doing it right. The goal is not to build a system that is impossible to hack, but one that is resilient to failure. By containing the blast radius and enforcing strict permissions, we can build pipelines that are both powerful and secure.

Sources and further reading

• MCP for Internal Tools: Permissions, Scopes, and Boring Success Criteria – RodyTech Blog
• Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work
• Authentication and Authorization for Internal MCP Servers | PropelAuth
• MCP tools | Retool Docs
• MCP should request minimum OAuth scopes based on active tools instead of requiring full account access · Issue #239 · supabase/mcp
• MCP-in-SoS: Risk assessment framework for open-source MCP servers