SKILL: Plugin-Only Agent Surface Gating

Domain: permission-gating Trigger: Apply this when an agent tries to extend its MCP surface while the session enforces plugin-only MCP access. Source Pattern: Distilled from reviewed agent trust-boundary and plugin-only surface-gating implementations.

Core Method

Before connecting any agent-specific MCP servers, check whether the session is locked to plugin-only extension mode. If it is, allow the extra MCP connections only for trusted agent definitions such as built-ins or approved plugins. Untrusted or user-controlled agent definitions should continue without creating new clients, while logging the gating decision clearly. This prevents policy bypasses without breaking trusted packaged agents.

Key Rules

• Check the plugin-only policy before any MCP initialization begins.
• Treat approved built-in or packaged agents as trusted, so their declared MCP integrations remain honored.
• Log a warning when skipping servers so telemetry captures the change in behavior.
• Always return the parent clients and an empty cleanup callback when gating is active to avoid downstream failures.

Example Application

When running in a highly regulated environment, reuse this heuristic before initializing agent MCP servers so only pre-approved agents can expand the MCP surface and user scripts cannot sneak new servers in.

Anti-Patterns (What NOT to do)

• Don’t let user-specified agents create external MCP connections while plugin-only mode is enabled; that defeats the security setting.
• Don’t apply the gate uniformly without checking admin trust; built-in agents still need their MCP servers even when plugin-only is true.