MCP Security: Permissions and Access Control

Layered Security Architecture

MCP enforces security at three distinct layers: the host, the client, and the server. Each layer adds controls that limit what the AI model can do, creating defense in depth where no single layer's failure compromises the entire system.

The host layer decides which MCP servers to connect to. A host configured to connect to a filesystem server and a database server will not connect to any other server, regardless of what the model requests. The host also enforces user consent policies, requiring explicit approval before the model invokes certain tools. Claude Desktop, for example, prompts the user before executing tools that modify external systems.

The client layer manages the connection to each server and enforces protocol-level security. Each client maintains an isolated session with its assigned server, preventing cross-server information leakage. The client validates that tool call responses match expected formats and handles transport-level security (TLS for HTTP connections, process isolation for stdio).

The server layer defines which operations are available and with what constraints. A filesystem server can be configured to allow read access to one directory and deny everything else. A database server can be restricted to SELECT queries with no data modification capability. These server-level permissions are the final enforcement point, independent of what the model or client requests.

Authentication and Authorization

Local MCP servers using stdio transport rely on operating system process isolation for security. The server runs as a child process of the host with the host's user permissions. File system permissions, database credentials, and API keys provided through environment variables control what the server can access. No additional authentication mechanism is needed because all communication stays within the local machine.

Remote MCP servers using Streamable HTTP transport authenticate with OAuth 2.1, standardized in the June 2025 specification revision. The OAuth flow works like any standard web authentication: the client obtains an access token through an authorization server, includes the token with each request, and the server validates the token before processing the request. Token scoping allows fine-grained control over which operations each client can perform.

The OAuth 2.1 adoption brings MCP in line with established web security practices. It supports access token refresh for long-running sessions, scope-based permission control for limiting client capabilities, and standard token revocation for revoking access when needed. Organizations that already have OAuth infrastructure can integrate MCP authentication into their existing identity and access management systems.

Permission Scoping

Effective MCP security depends on configuring servers with the minimum permissions required for their intended use. General guidelines for common server types help establish appropriate permission boundaries.

Filesystem servers should be restricted to specific directory trees. Configure the allowed directories list to include only the directories the model needs to access. Exclude sensitive directories like home directories, system directories, and credential stores. Consider read-only access unless the model genuinely needs to create or modify files.

Database servers should use database credentials with the minimum required privileges. For query-only use cases, create a database user with SELECT permissions and no data modification rights. For write use cases, limit the user's permissions to specific tables and operations. Never give an MCP server database administrator credentials.

API servers should use scoped API keys or tokens. If the external API supports OAuth or scoped tokens, create credentials that only allow the specific operations the MCP server needs. Avoid using root or admin-level API keys for MCP server configurations.

Known Vulnerabilities and Risks

Security research has identified real vulnerabilities in the MCP ecosystem that merit attention. A study of community MCP servers found that approximately 43% of sampled servers contained command injection vulnerabilities. These vulnerabilities allow a malicious prompt or crafted input to execute arbitrary commands through the MCP server, potentially compromising the host system.

Prompt injection attacks are a concern specific to AI tool integration. A malicious website, document, or data source can contain hidden instructions that attempt to manipulate the AI model into invoking MCP tools in unintended ways. For example, a web page might contain invisible text instructing the model to use a filesystem tool to read sensitive files. Host applications with user consent flows mitigate this risk by requiring explicit user approval for tool invocations, but automated agent systems without human oversight are more vulnerable.

Over-permissioned servers create unnecessary risk surface. A filesystem server configured with access to the entire home directory exposes far more than necessary. A database server with admin credentials can do far more than needed. The gap between the permissions a server has and the permissions it actually needs represents exploitable attack surface.

Supply chain risks exist in the community server ecosystem. Installing an MCP server from npm or PyPI runs code on your machine with whatever permissions the server is configured to use. Malicious or compromised server packages could exfiltrate data, modify files, or establish persistent access. Reviewing server source code and checking maintainer reputation before installation is an important security practice.

Best Practices for Safe Deployment

Apply least privilege rigorously. Every server should have only the permissions it needs for its specific use case. If you are uncertain about what permissions are needed, start with the most restrictive configuration and expand only when specific operations require it.

Review community servers before deployment. Check the source code for obvious security issues like command injection, unrestricted file access, or credential logging. Look at the server's issue tracker for reported vulnerabilities. Prefer servers with recent maintenance activity, clear documentation, and known maintainers.

Use user consent flows when available. Host applications that require user approval before tool execution provide an important safety layer. The user can review what the model wants to do and deny requests that seem inappropriate. For automated systems without user oversight, implement programmatic approval policies that validate tool calls against allowed operations.

Monitor and audit tool invocations in production. Log every tool call with the tool name, arguments, result status, and timestamp. Review logs for unusual patterns like unexpected file access, database queries targeting sensitive tables, or high-frequency tool invocations. Set up alerts for operations that exceed normal usage patterns.

Isolate MCP servers from sensitive infrastructure. Run servers in containers or sandboxed environments when possible. Use network segmentation to prevent MCP servers from accessing systems they do not need. For high-security environments, run servers on dedicated hosts with firewall rules that restrict their network access to only the services they need.