MCP for Internal Tools: Permissions, Scopes, and Boring Success Criteria

We are past the phase of treating Model Context Protocol (MCP) as a novelty. It is now the standard plumbing for connecting LLMs to internal data. But there is a dangerous assumption in the current wave of adoption: that if the connection works, the security works. It does not.

MCP is the “USB-C of AI.” It is a universal standard for connecting LLMs to tools, data, and services. It defines a secure, consistent, and interoperable way for AI models and agents to communicate with external systems. But crucially, MCP itself does not include authentication or authorization. It assumes the underlying transport handles security.

For internal tools, this assumption is a liability. Without explicit, granular authorization layers, an MCP server acts as an all-or-nothing gateway. If an LLM can connect, it has access to everything the server can touch. This creates a “rogue prompt” risk for sensitive data like payroll, employee directories, and production databases. We need to stop treating permissions as an afterthought and start treating them as a first-class citizen in our architecture.

The Problem: MCP is a Pipe, Not a Vault

The core issue with deploying MCP for internal tools is the gap between protocol capability and security reality. MCP provides the mechanism for communication, but it lacks a built-in authentication or authorization layer by default. This is not a bug; it is a design choice that leaves the security burden entirely on the implementation layer.

When we build internal AI tools, we are often dealing with high-stakes data. We are connecting agents to HR systems, database management systems, and onboarding workflows. If we rely on default MCP configurations, we are effectively giving every authenticated user full administrative access to these systems. This violates the principle of least privilege and creates significant friction for IT admins who must justify broad permissions.

Consider the typical OAuth flow. Default configurations often request broad scopes, forcing users to grant full account access even for simple tasks. This is a failure of user experience and security. A documentation reader tool should not require database write access. Yet, without granular scope definitions, we are forced to couple these capabilities, creating unnecessary attack surfaces.

The risk is not theoretical. Internal tools built with MCP often handle sensitive data. If an agent is compromised or a user is tricked into executing a malicious prompt, the lack of granular controls means the blast radius is total. We need to move away from this binary model of access.

Why ‘All-or-Nothing’ Access Fails in Enterprise

Enterprise environments are not monolithic. They are composed of distinct departments with distinct needs. Engineering needs to query production logs. HR needs to access employee records. Finance needs to view payroll data. These roles should not have overlapping access rights.

The current state of MCP authorization often ignores this reality. Without external authorization, the MCP server cannot distinguish between a user who needs to read a document and a user who needs to modify a database. This all-or-nothing access model is incompatible with modern identity management practices.

We see this friction in the user experience. Users are asked to consent to broad permissions that they do not understand and do not need. This leads to “consent fatigue,” where users blindly approve requests, undermining the security model entirely. Furthermore, IT admins are forced to manage complex, static role mappings that do not adapt to the dynamic nature of AI tool usage.

The solution is not to abandon MCP. It is to implement granular authorization that aligns with our existing identity infrastructure. We need to define one scope per tool or tool group. This allows us to enable granular authorization and prevent broad account-level access.

Implementing Granular Scopes: The Boring Success Criteria

To secure MCP for internal tools, we must adopt OAuth 2.1 resource server patterns. In this model, the MCP server acts as a resource server that enforces permissions in the access token. This is not a new concept; it is a proven pattern that we can apply to AI tooling.

The success criteria for this implementation are boring, predictable, and measurable:

1. Define one scope per tool or logical group. For example, use mcp:invoice.create for creating invoices and mcp:invoice.read for viewing them. This granularity allows us to limit access to only what is necessary.
2. Use policy-based access control. IT admins should define which scopes are available to which roles in the console. For example, Engineering might have access to mcp:db.query, while HR has access to mcp:hr.employee.read.
3. Implement tool-level checks. The MCP server must reject requests if the required scope is missing from the token. This is a hard fail, not a soft warning.
4. Minimize scope requests. Tools that do not interact with sensitive APIs, such as documentation readers, should require zero permissions and bypass the authentication step entirely. This reduces friction and improves the user experience.

This approach aligns with the recommendations from Descope, which describes MCP authorization following OAuth 2.1, where the server acts as a resource server. By defining one scope per tool, we enable granular authorization and prevent the all-or-nothing access that plagues many early implementations.

Practical Architecture for Internal MCP Servers

Building a secure MCP architecture requires layering an Identity Provider (IdP) in front of the MCP server. Tools like Descope or PropelAuth provide the necessary infrastructure for RBAC and scope management.

The architecture should look like this:

1. Identity Provider: The IdP handles user authentication and issues access tokens with specific scopes. It maps internal user roles to these scopes.
2. MCP Server: The server validates the access token and enforces the scopes. It acts as the gatekeeper, ensuring that only authorized tools are accessible.
3. MCP Client: The client calculates minimum scopes based on active tools. It should bypass auth for public tools where possible and request only the scopes necessary for the task.

This architecture supports multi-user isolation. As noted in the LibreChat documentation, handling MCP in multi-user environments requires user-specific connections and OAuth authentication detection. By fine-tuning agent capabilities and enabling or disabling individual tools after adding an MCP server, we can ensure that agents only access data relevant to their assigned scope.

We must also consider the user consent flow. Policies and user consent operate at two levels: IT admins define policies in the console to limit what scopes are available, and end users provide consent only for those permitted scopes. This two-level approach ensures that users are not overwhelmed by broad permission requests and that IT admins maintain control over the security posture.

Conclusion: Security as a Feature, Not an Afterthought

Secure MCP implementation is not about complex cryptography. It is about clear scope definitions and role mapping. By treating permissions as a first-class citizen, we can safely deploy AI agents to internal tools without risking data leakage.

The goal is boring, predictable access control that scales with our organization’s structure. We need to reject the notion that AI tools should have broad access. We need to embrace the granularity that OAuth 2.1 provides. And we need to build architectures that prioritize least privilege from the start.

This is not just a security requirement. It is a business requirement. If we cannot control access to our internal tools, we cannot trust the AI agents that use them. And if we cannot trust them, we cannot deploy them.

Let us build resilient pipelines. Let us build secure tools. Let us build boring, predictable, and effective AI infrastructure.

Sources and further reading

• Authentication and Authorization for Internal MCP Servers | PropelAuth
• MCP Authorization | Descope Documentation
• MCP should request minimum OAuth scopes based on active tools instead of requiring full account access | GitHub
• MCP | LibreChat Documentation