Repository navigation
[FEATURE] : Enterprise MCP security policy: allowlist remote servers while allowing local MCP #54100
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Allow enterprise administrators to enforce an organization-wide MCP security policy that permits local MCP servers (stdio), while restricting remote MCP connections to an administrator-managed allowlist.
The policy should be enforced before establishing a remote MCP connection and should not be overridable by project-level or user-level configuration.
Proposed configuration example
{
"mcp": {
"local-filesystem": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "./workspace"]
},
"corporate-mcp": {
"type": "remote",
"url": "https://mcp.company.internal/mcp"
}
},
"mcpPolicy": {
"local": "allow",
"remote": "allowlist",
"allowedRemoteHosts": [
"mcp.company.internal"
]
}
}
Expected behavior:
- Local MCP servers using stdio are allowed.
- Remote MCP servers matching the corporate allowlist are allowed.
- All other remote MCP servers are rejected before connection establishment.
- The security policy is enforced through administrator-managed configuration and cannot be overridden by user or project configuration.
- Rejected connections produce a clear diagnostic message.
Security considerations:
- The allowlist must validate the actual connection destination, including redirects.
- Domain matching must be exact or follow explicitly defined wildcard rules.
- The policy must apply consistently to both OpenCode CLI and Desktop.
- An empty allowlist should deny all remote MCP connections.
Metadata
Metadata
Assignees
Labels
No labels
Activity
opencode-agent commentedon Oct 9, 2026
Thanks for the detailed request, @Morpheis83!
To restate it: you'd like an administrator-managed MCP policy that always allows local (stdio) MCP servers but limits remote MCP servers to an allowlist of hosts. It would be checked before connecting (including after redirects) and users or projects could not override it.
v2 already has policy statements, under
experimental.policiesor delivered by a connected OpenCode Console. For MCP they currently match only the server ID, e.g.{ "effect": "deny", "action": "integration.use", "resource": "mcp:*" }. They can't tell local from remote servers or match a URL host, which is the gap you describe. Maintainers will consider it.Related issues and PRs:
managed-settings.jsonauthoritative, so users can't add extra MCP servers next to managed onesMorpheis83 commentedon Oct 9, 2026
cc-bb-aa commentedon Oct 9, 2026
Default deny for remote servers with an explicit allowlist is the right enterprise shape. Two details matter: identity per server, so approvals name which server they cover, and logging every connection decision so a later audit can explain why a server was reachable. Local MCP staying frictionless is fine since it inherits the user's own trust.
Skeptomenos commentedon Oct 29, 2026
Could this policy also support the inverse: deny all local stdio MCP servers while allowing remote servers that match an administrator's host allowlist? A managed deployment may permit approved hosted connectors but block local subprocesses because they execute on the server under its account.
In v2.2.1,
integration.usematchesmcp:<server-name>(policy code), while local and remote are separate MCP config types (schema). The current matcher cannot distinguish those types. Supporting both directions would let administrators express the MCP server policy that fits their deployment.Hamza-Abili commentedon Nov 10, 2026
Disclosure: I maintain a community OpenCode plugin,
@hamzaabili/opencode-integrity.This does not implement the destination allowlist this issue asks for (host matching, redirects, local-vs-remote), so the native policy engine is still the right place for that. What it does today is the reviewed-server-set half:
opencode-integrity policy --deny-unlistedemits nativemcp.usedeny *plusallowstatements from a committed lockfile, so only the MCP servers a project has pinned remain usable. It is name-based and static, not host/redirect-aware, and it does not distinguish local from remote. If the policy engine gains a destination-aware action, the lockfile could feed it, but I don't want to pretend that solves this request.