Gobernar el acceso

Conectar servidores es fácil; gobernar quién puede conectar qué es lo que diferencia un uso personal de uno de equipo seguro. Esta lección es la capa de control sobre MCP — la versión "a escala" de la higiene de seguridad que ya conoces.

El riesgo, recordado

Un servidor MCP trae contenido externo (issues, páginas, datos) al contexto del agente. Ese contenido puede contener inyección de prompt: instrucciones hostiles escondidas que intenten que Claude haga algo que no pediste. No es teórico; es la razón por la que MCP se gobierna, no solo se conecta.

El principio de siempre, aplicado a MCP: mínimo privilegio. Conecta los servidores que necesitas, con los permisos que necesitan, y nada más.

Restringir con permisos y scopes

Tienes tres palancas, todas ya conocidas:

1. Reglas de permisos sobre las tools (mcp__servidor__* en allow/deny) — del curso de permisos.
2. Scopes — un servidor local no se filtra a otros proyectos; uno project lo ve el equipo.
3. Aprobación de .mcp.json — Claude Code pide tu OK antes de usar servidores que vienen del repo.

Managed MCP: control centralizado

Esto es para administradores de una organización. Si no gestionas una flota de máquinas, no necesitas tocar nada de esta sección: salta a Acotar los scopes de OAuth, que sí controlas tú desde tu .mcp.json. Lo dejamos aquí para que reconozcas qué pasa cuando tu empresa te aplica una política.

Para organizaciones, un administrador puede fijar qué servidores se permiten, al margen de lo que cada dev configure. Hay dos mecanismos distintos (no los confundas):

1. managed-mcp.json — el set fijo de servidores

Si despliegas este fichero, Claude Code carga solo los servidores que define; el dev no puede añadir, modificar ni usar ningún otro (ni los de plugins). Usa el mismo formato que un .mcp.json de proyecto — un mapa mcpServers:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "company-internal": {
      "type": "stdio",
      "command": "/usr/local/bin/company-mcp-server",
      "args": ["--config", "/etc/company/mcp-config.json"]
    }
  }
}

Es un fichero independiente (no son los managed settings), así que se coloca en una ruta de sistema con privilegios de administrador, distinta en cada plataforma:

No metas API keys ni credenciales en los bloques env: cualquier usuario de la máquina puede leer este fichero. Usa expansión ${VAR}, OAuth o headers por usuario para que cada dev se autentique como él mismo. Un { "mcpServers": {} } vacío desactiva MCP por completo.

2. allowedMcpServers / deniedMcpServers — el filtro

Estas dos claves no van en managed-mcp.json: van en un fichero de managed settings (los mismos que viste en permisos). Son una lista blanca y una lista negra que filtran qué servidores configurados pueden cargar — cada entrada identifica un servidor por su URL, su comando o su nombre:

{
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] }
  ],
  "deniedMcpServers": [
    { "serverName": "dangerous-server" },
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

• allowedMcpServers — lista blanca: si está puesta, solo cargan los servidores que casen una entrada (* admite comodín en las URLs). Si no se pone, todos pasan.
• deniedMcpServers — lista negra: lo que case aquí queda bloqueado, y nada lo anula (la denylist gana siempre).

Una entrada serverName no es un control de seguridad: el dev elige el nombre que le da al servidor, así que cualquiera puede llamar github a otra cosa. Para forzar qué se ejecuta, usa serverCommand o serverUrl.

Es el equivalente, para MCP, de los managed settings que viste en permisos: política de empresa que el dev no puede ablandar.

Cómo lo ve el dev cuando algo está bloqueado

No hay un badge de "bloqueado por política" dentro de la sesión. Las señales reales son:

• Al intentar claude mcp add con managed-mcp.json activo: Cannot add MCP server: enterprise MCP configuration is active and has exclusive control over MCP servers.
• Al añadir un servidor de la denylist: ... server is explicitly blocked by enterprise policy. Y si no está en la allowlist: ... not allowed by enterprise policy.
• Un servidor que ya tenías configurado y que ahora bloquea la política simplemente desaparece de /mcp y de claude mcp list sin aviso. No verás un mensaje que diga que la causa es la política:

 MCP Servers

 ● github      connected    · 14 tools
 ● postgres    connected    ·  6 tools

 ↑/↓ moverse · Enter ver tools / autenticar · r reconectar · q salir

Aquí sentry, que antes salía, ya no aparece: la política lo retiró. Como no hay señal en el panel, avisa a tu equipo de qué servidores bloqueas al desplegar una restricción.

Acotar los scopes de OAuth

Cuando un servidor pide OAuth, a veces ofrece más permisos de los que quieres conceder. Puedes fijar los scopes que Claude Code solicita, en el oauth del servidor en .mcp.json:

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": { "scopes": "channels:read chat:write search:read" }
    }
  }
}

Así limitas un servidor al subconjunto aprobado, en vez de aceptar todo lo que ofrece.

Si falla

• Desplegaste managed-mcp.json pero el dev sigue viendo sus propios servidores → el fichero no se está leyendo. Verifica la ruta exacta de la plataforma (tabla de arriba) y los permisos. Para confirmarlo: claude mcp list debe mostrar solo los servidores del fichero.
• Pusiste allowedMcpServers y aun así un dev carga otro servidor → las allowlists de todas las fuentes se fusionan, incluida la del propio usuario. Para que la allowlist sea autoritativa, ponla con allowManagedMcpServersOnly: true en los managed settings.
• Un servidor desaparece y nadie sabe por qué → recuerda que un bloqueo por política no avisa en /mcp. Revisa si está en una denylist (que gana siempre) o si quedó fuera de la allowlist.

Qué exponer (y qué no)

• Da preferencia a servidores de solo lectura cuando la tarea no necesita escribir (un db-reader con un usuario read-only de la DB).
• No conectes con credenciales de admin "por si acaso": conecta con el mínimo.
• Revisa el .mcp.json de un repo antes de confiar en él, igual que revisas sus skills y hooks.

Qué llevas hasta aquí

• Un servidor MCP trae contenido externo: inyección de prompt es el riesgo a gobernar.
• Controlas con permisos (mcp__servidor__*), scopes y la aprobación de .mcp.json.
• Managed MCP fija política de empresa con dos piezas distintas: managed-mcp.json (set fijo de servidores, en ruta de sistema) y allowedMcpServers/deniedMcpServers (allow/denylist en managed settings). Un bloqueo no avisa: el servidor desaparece de /mcp. oauth.scopes acota lo que se concede.

En la última lección, cuándo dejar de conectar servicios ajenos y escribir el tuyo.

Fuente oficial: Managed MCP configuration · Security