Applicable plans: Enterprise
Use cases
- Allow members to connect to and use only MCP servers approved by the organization.
- Apply the same access rules to MCP servers added by members and those deployed centrally by the organization.
- Block all non-built-in MCP servers across the organization when necessary.
Scope
Qoder clients enforce access control at MCP connection and usage entry points they can identify and block.
| Entry point | Typical scenarios |
|---|
| Configuration | Reading or applying MCP configurations, including configurations distributed by the organization |
| Installation and activation | Adding, installing, enabling, or loading an MCP server |
| Startup and connection | Starting a local process, or establishing or restoring a remote connection |
| Use | Displaying or registering MCP tools, or making an MCP call |
Note: MCP Access Control governs access at entry points. It is not a runtime security sandbox for MCP servers.
Access modes
Administrators can select one of the following access modes:
| Access mode | Behavior |
|---|
| Allow all | Allows all non-built-in MCP servers in the organization. Existing allowlist rules are retained but cannot be edited. |
| Rule-based access | Allows only non-built-in MCP servers that match an allowlist rule. Administrators can create, edit, and delete rules. MCP servers that do not match a rule are unavailable. |
| Block all | Blocks access to and use of all non-built-in MCP servers. Existing allowlist rules are retained but cannot be edited. |
- In the organization admin console, go to Extensions & Marketplace > MCP Access Control.
- Change the access mode to Rule-based access.
- If there are no allowlist rules, follow the on-screen guidance to create the first rule.
- Enter a rule name, select a match target, enter an expression, and review the rule.
- Confirm the combined action to create the first rule and enable Rule-based access.
If allowlist rules already exist, you can confirm the switch immediately after selecting Rule-based access. After the mode changes, you can continue to create, edit, or delete rules in the rule list.
If you cancel the initial setup or the submission fails, no rule is created and the current access mode remains unchanged.
Allowlist rules support the following match targets:
| Match target | Exact-match example | Wildcard example |
|---|
| MCP endpoint URL | https://mcp.example.com/v1 | https://*.example.com/* |
| Launch command | npx -y @modelcontextprotocol/server-sqlite | npx -y @company/mcp-* |
- MCP endpoint URL:
*. at the left edge of a domain, or * at the end of a path. For example, *.example.com matches its subdomains but not the bare domain example.com.
- Launch command:
* at the end of an argument. The executable must match exactly. * cannot be used by itself or span multiple arguments.
Wildcards in other positions, full glob patterns, and regular expressions are not supported. Broader wildcards allow more MCP servers. Before saving a rule, make sure its scope matches your intent.
Processing before matching
Clients identify and match configurations as follows:
- MCP endpoint URL: Only absolute
https URLs are supported. A URL containing user information, query parameters, or a fragment is treated as invalid rather than having those components removed before matching.
- Launch command: The executable and arguments are matched one by one in order. The argument count and order must be identical. The client does not interpret shell syntax or quoting, search
PATH, or expand environment variables.
If an MCP configuration contains neither a valid URL nor a valid launch command, the client treats it as invalid and blocks its use.
Unavailable states in clients
Clients retain the configuration or deployment entry for an unavailable MCP server and display a status that explains why it is unavailable. Actions such as connecting, enabling, and invoking the server are disabled.
| Status | Description |
|---|
| Disabled by organization | An administrator has set the access mode to Block all. |
| Not approved | Rule-based access is active, and this MCP server does not match an allowlist rule. |
| Invalid configuration | The client cannot identify a valid MCP endpoint URL or launch command. |
| Policy unavailable | The client is temporarily unable to retrieve the enterprise MCP policy. |
Client version requirements
Only clients that meet the minimum supported version enforce MCP access modes and allowlist rules.
| Client | Minimum supported version |
|---|
| Qoder IDE | 1.15.0 |
| Qoder JetBrains Plugin | 2026.724.1 |
| Qoder CLI | 1.1.18 |
FAQ
Are MCP servers deployed centrally by the organization allowed automatically?
No. MCP Access Control takes precedence over centrally managed deployment. Under Rule-based access, an MCP server deployed centrally by the organization must still match an allowlist rule. Under Block all, the MCP server cannot be loaded or invoked.
Does this feature block network requests made by an MCP server?
No. This feature enforces access control only at MCP connection and usage entry points that the client can identify. After an MCP server passes the check, its scripts, file access, process calls, and network requests are outside the scope of this control.
Clients cache enterprise policies. Changes to the access mode or allowlist rules usually take about five minutes to apply.
