[FEATURE]: Apply integration policies to client-attached MCP servers #60253

Activity

1. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   Contributor

   More actions

   Thanks for the detailed write-up, @Skeptomenos! You're asking for integration.use policies to apply to MCP servers that a client attaches through the engine, not only to configured ones. That would mean checking the policy before an attachment is registered or its tools are called, and revoking existing attachments when the policy changes.

   As you point out, attached connections are tracked separately from configured servers. The policy plugin only filters configured servers through ctx.mcp.transform, and the plugin API currently has no hook on attachments, so this can't be added as a plugin today. Maintainers will consider it.

   Related issues:

   • feat(core): add MCP transport over incoming client sockets #57502: added the transport for attaching client-hosted MCP servers
   • feat(client): add connectClientMcp helper for client-hosted MCP tools #57504: the client helper for attaching MCP tools
   • refactor(browser): serve the in-app browser's tools from the desktop over client MCP #59477: moves the desktop browser tools to client MCP, so this gap will matter more
   • [FEATURE] : Enterprise MCP security policy: allowlist remote servers while allowing local MCP #54100: enterprise MCP allowlist policy
   • feat(core): enforce managed integration and tool policies #53775: where managed integration and tool policies were first enforced
2. Paraphern commented on Oct 29, 2026

   

   Paraphern

   on Oct 29, 2026

   More actions

   The gap is real and the fix direction (policy at attachment registration and per-call, not only at config load) is right. Two notes from the enforcement-boundary side of this problem:

   1. A policy checked at registration goes stale by the next tools/list. An attachment approved once can serve a different surface later in the session (new tools, widened params) - the policy decided about a surface it saw once, and the decision key in policy.ts is mcp:${name}, so a surface change under the same name never re-asks. Re-check when the tool list changes, or key the verdict to a hash of the surface it approved (any pin over {name, description, inputSchema} works; a mismatch is a new policy question, not a cached yes).
   2. The attached path and the configured path should converge on one choke point. Two gates drift apart silently - the exact bug here. One integration.use call site covering both entry paths, with the attachment just another registration source, is the structural fix; the same surface-hash key then works for both. (The bot's own framing - "revoking existing attachments when the policy changes" - is the same logic one level up: policy changes and surface changes both deserve re-evaluation.)

   We build the pin/diff half standalone (rugsnare, Apache-2.0 - graded surface drift, exit 1, and an enforce proxy that quarantines a changed tool mid-session, which is what a per-call policy wants to key on). Happy to sketch the choke-point shape if useful.