← Volver al listado de tecnologías ← Índice de Claude Partner Badge: Claude Code

Capítulo 20 — Gobernanza de servidores aprobados y la allowlist MCP

10 de octubre de 2026 Por: Artiko

claude-codeanthropicpartner-badgemcpgobernanzaallowlist

Gobernanza de servidores aprobados y la allowlist MCP

Módulo 5 · Extensibilidad · Lección 2 de 8

Los desarrolladores lo preguntarán. Necesitas una respuesta defendible.

Al terminar esta lección podrás configurar la allowlist de servidores MCP, explicar el flujo de aprobación al equipo de seguridad de un cliente y manejar la objeción más común.

Defensa en profundidad

La gobernanza de MCP se ubica dentro de un modelo de seguridad por capas

El marco de defensa en profundidad de Anthropic tiene cinco capas. La allowlist de MCP se ubica en la capa 02, la de plataforma y runtime. No es una política de MCP independiente: forma parte de cómo Claude Enterprise gestiona todo el acceso a conectores.

Capa	Qué incluye
01 · Identidad y entorno	SSO, aprovisionamiento SCIM, RBAC y controles de acceso de red. Es el perímetro empresarial que ya presentas a los clientes: quién obtiene acceso y en qué nivel. Lo administra la propia infraestructura del cliente.
02 · Plataforma y runtime ← esta lección	Dónde se ejecuta realmente una solicitud: superficies, sandboxes, egress y consentimiento de conectores. Aquí vive la allowlist de MCP. Es una responsabilidad compartida: Anthropic controla la plataforma y tu organización controla la configuración de políticas.
03 · Seguridad en runtime	Clasificadores ejecutados por Anthropic, system prompts por superficie y aplicación de la política de uso alrededor de cada llamada al modelo. Detecta jailbreaks y patrones de abuso nuevos sin necesidad de reentrenar el modelo.
04 · Seguridad del modelo	Propiedades de seguridad entrenadas directamente en los pesos: Constitutional AI, RLHF y rechazo entrenado. Es la capa que ningún system prompt puede deshacer. La controla íntegramente Anthropic.
05 · Observabilidad y auditoría	Audit logs, Compliance API, OpenTelemetry y analítica que atraviesan todas las demás capas. Alimenta el SIEM, el legal hold y el stack de cumplimiento del cliente. Se cubre en el módulo 7 (Administración y medición).

flowchart TD
    l1["01 · Identidad y entorno: SSO, SCIM, RBAC, controles de red"]
    l2["02 · Plataforma y runtime: allowlist de MCP y dominios de egress"]
    l3["03 · Seguridad en runtime: clasificadores de Anthropic"]
    l4["04 · Seguridad del modelo: entrenada en los pesos"]
    l5["05 · Observabilidad y auditoría: audit logs, Compliance API, OpenTelemetry"]
    l1 --> l2 --> l3 --> l4 --> l5
    style l2 fill:#fde68a,stroke:#b45309

Esta lección se centra en la capa 02. Los controles concretos que configuras, la allowlist de servidores MCP y las restricciones de dominios de egress, viven en la capa de plataforma y runtime, entre el perímetro de identidad que el cliente ya posee y la pila de seguridad gestionada por Anthropic que queda debajo. Ese encuadre importa en la conversación de seguridad: no le pides al cliente que confíe en Claude con acceso no gobernado a conectores. Le muestras exactamente dónde están sus palancas de política dentro de una pila en la que otras cuatro capas funcionan de forma independiente a lo que pueda instalar cualquier desarrollador.

Dos planos de control

Los servidores instalados por el usuario y los desplegados por la organización se gobiernan de forma distinta

Dentro de la capa 02 hay dos mecanismos distintos para llevar un servidor MCP al entorno de un desarrollador, y se gobiernan de forma diferente. Entender esta división es esencial para la conversación de seguridad. La mayoría de los clientes confunde ambos, y por eso la pregunta del CISO («¿pueden los desarrolladores instalar cualquier cosa?») tiene una respuesta matizada.

Plano	Cómo funciona
Instalado por el usuario (controlado por el desarrollador mediante `.mcp.json` local)	Puede añadir un servidor en su `~/.claude.json` o en el `.mcp.json` del proyecto. Esto afecta solo a sus propias sesiones, y la responsabilidad es del desarrollador. Para restringir por completo las instalaciones de usuario, el administrador pone la política de override en `deny` en `managed-settings.json`.
Desplegado por la organización (dos mecanismos: filtrado por allowlist y despliegue gestionado)	Véase el detalle a continuación.

Despliegue: managed-mcp.json envía servidores fijos a todos los usuarios de forma automática, sin acción del usuario.
Filtrado: allowedMcpServers en managed-settings.json controla qué servidores los desarrolladores tienen permitido añadir por sí mismos. Con allowManagedMcpServersOnly: true se aplica el filtro. Son controles separados: configura ambos en el Día 0.

El siguiente diagrama resume la lógica que describe esta sección: con el flag activado solo entran los servidores de la lista; sin el flag, la lista es orientativa.

flowchart TD
    add["El desarrollador agrega un servidor MCP"] --> flag{"allowManagedMcpServersOnly: true?"}
    flag -->|"Sí"| inlist{"¿Está en allowedMcpServers?"}
    flag -->|"No: la lista es solo orientativa"| ok1["Instalación permitida por defecto"]
    inlist -->|"Sí"| ok2["Instalación permitida"]
    inlist -->|"No"| blocked["Instalación bloqueada: fuera de la lista aprobada"]

Configuración del Día 0

La allowlist se carga en managed-settings.json antes del kickoff

El Plan de activación de 30 días (30-Day Activation Plan) incluye la configuración de la allowlist de MCP como prerrequisito mínimo a nivel de organización para el Día 0, junto con SSO/SCIM y el reporte de gasto. No es opcional. Sin una política MCP aplicada, los desarrolladores podrían conectarse a servidores MCP no aprobados, lo que crea la exposición de seguridad que el cliente quiere evitar.

Trabaja con el equipo de plataforma o de seguridad del cliente para definir la lista inicial de servidores aprobados. El inventario MCP previo al kickoff (qué servidores usa ya el equipo) alimenta directamente esta lista. Un conjunto inicial práctico para la mayoría de las activaciones centradas en código:

// managed-settings.json: sección de allowlist de MCP
// Las entradas de allowedMcpServers deben ser objetos, no cadenas simples
{
"allowManagedMcpServersOnly": true, // impide instalaciones no aprobadas
"allowedMcpServers": [
{ "serverUrl": "https://api.github.com/*" }, // contexto de código, operaciones de PR
{ "serverUrl": "https://linear.app/mcp/*" }, // ticketing y contexto de issues
{ "serverCommand": ["npx", "-y", "@playwright/mcp@latest"] }, // automatización de navegador y pruebas
{ "serverUrl": "https://*.client-internal.com/*" } // sistemas internos
]
}

El flag allowManagedMcpServersOnly: true es la respuesta a la pregunta del CISO. Con él activado, los desarrolladores no pueden instalar servidores fuera de la lista aprobada. Sin él, la lista es orientativa, no aplicada.

Ritmo de la activación

La revisión de nuevos servidores necesita un proceso permanente, no ad hoc

La allowlist inicial no cubrirá todo lo que el equipo necesite para la Semana 3. Construye el proceso de revisión en la Semana 1 para que las solicitudes no frenen el proyecto.

Pre-kickoff: inventariar lo que ya existe. El consultor y el líder del CoE catalogan los servidores MCP que el equipo usa hoy. Estos pasan directamente a la lista aprobada, sin evaluación nueva. Los servidores no vetados se marcan para revisión.
Día 0: definir la allowlist inicial con el equipo de seguridad. Trabaja con TI o con el equipo de plataforma para cargar la lista de servidores aprobados en managed-settings.json. Confirma los dominios de egress. Define la política de instalación de usuarios. Comparte el inventario pre-kickoff con 48 horas de antelación, para que el equipo llegue listo para confirmar, no para revisar por primera vez. Debería llevar menos de una hora.
Semanal: el touchpoint del CoE incluye aprobaciones de conectores. La reunión semanal del CoE cubre la gobernanza, y las nuevas solicitudes de conectores llegan ahí. El líder del CoE toma la decisión; el equipo de seguridad revisa el dominio de egress de cualquier caso no estándar. El plazo de respuesta debe ser de la misma semana, no del mismo mes.

flowchart LR
    pre["Pre-kickoff: inventario de servidores existentes"] --> d0["Día 0: allowlist inicial con el equipo de seguridad"]
    d0 --> sem["Semanal: aprobaciones de conectores en el CoE"]

Comprueba tu comprensión

Verdadero o falso

Marca cada afirmación como verdadera o falsa antes de ver la explicación.

Con la configuración predeterminada, un desarrollador puede instalar cualquier servidor MCP añadiéndolo a su .mcp.json local, sin importar lo que diga la allowlist de la organización.

Verdadero / Falso

Ver respuesta

Falso. Configurar allowManagedMcpServersOnly: true en managed-settings.json bloquea las instalaciones de usuario fuera de la lista aprobada. Por defecto (sin este flag), las instalaciones locales están permitidas. El flag es lo que convierte la allowlist de orientativa en aplicada.

Nota de la adaptación: la clave del material original marca esta afirmación como Falsa, aunque su propia explicación describe que, sin el flag, las instalaciones locales están permitidas. Lo que hay que retener es el mecanismo: sin allowManagedMcpServersOnly: true la allowlist es solo orientativa.

Las allowlists de dominios de egress pueden bloquear llamadas salientes a hosts no aprobados, incluso si un desarrollador instala con éxito un servidor MCP no aprobado.

Verdadero / Falso

Ver respuesta

Verdadero. Los controles de egress son una capa separada de la allowlist de servidores. Un servidor puede instalarse, pero si el dominio al que llama no está en la lista de egress, la llamada de red falla. Defensa en profundidad: las capas funcionan de forma independiente.

La allowlist de MCP es una tarea de la Semana 4. Es más seguro dejar que el equipo experimente libremente al principio y bloquear todo al final de la activación.

Verdadero / Falso

Ver respuesta

Falso. El Plan de activación de 30 días (30-Day Activation Plan) incluye explícitamente la configuración de la allowlist de MCP como prerrequisito del Día 0, junto con SSO/SCIM y el reporte de gasto. «Experimentar libremente primero» crea exactamente la exposición de seguridad que el cliente quiere evitar. Además, añadir la gobernanza a posteriori, cuando los desarrolladores ya han formado hábitos, es más difícil que configurarla de forma limpia al inicio.

Una conexión MCP con alcance OAuth significa que Claude solo puede acceder a los recursos y datos que el desarrollador autenticado ya está autorizado a alcanzar.

Verdadero / Falso

Ver respuesta

Verdadero. El alcance OAuth es la respuesta clave a «¿qué puede ver Claude?». Claude hereda los permisos del desarrollador; no obtiene acceso nuevo. Si un desarrollador no puede leer un repositorio privado, Claude tampoco podrá hacerlo a través de MCP. En una revisión de seguridad, este es el detalle que cierra la pregunta «¿qué puede ver Claude?».

La gobernanza de MCP funciona con dos capas independientes: qué se puede instalar (la allowlist de servidores) y dónde puede conectarse (los controles de dominios de egress). Configurar ambas es una tarea del Día 0, no del Día 30. La respuesta a «¿pueden los desarrolladores instalar cualquier cosa?» es una decisión de política que toma el administrador: es un flag en managed-settings.json, no una conversación sobre confianza.

Aplica el marco: el ritmo de la activación en tres situaciones

Diriges una activación de 30 días en servicios financieros. El cliente tiene una allowlist de MCP activa y una reunión de gobernanza del CoE cada jueves. Tres momentos de la activación:

Situación 1 · Pre-kickoff. Antes de lanzar la activación, un desarrollador te dice que usa a diario un servidor MCP de Confluence. ¿Qué debería haber pasado con esa información?

A · Anotarlo como preferencia del desarrollador. Puede instalarlo localmente el Día 1 con su configuración personal.
B · Esperar a que el desarrollador lo plantee en el CoE. Deja que el proceso de gobernanza de la Semana 1 lo gestione.
C · Añadirlo al inventario MCP previo al kickoff. Márcalo para la allowlist del Día 0, para que quede aprobado sin una evaluación de seguridad aparte.

Ver respuesta

C es correcta. Los servidores que el equipo ya usa pasan directamente a la lista aprobada, sin una nueva evaluación de seguridad. Para eso existe el inventario previo al kickoff. La allowlist del Día 0 debe confirmar herramientas conocidas, no ser una sesión de descubrimiento. Las herramientas que se planteen por primera vez en el CoE de la Semana 1 crean una brecha: el desarrollador trabaja sin contexto de MCP o instala fuera de la política.

Situación 2 · Día 0. El líder de TI dice que el equipo de seguridad necesita dos semanas más para evaluar Playwright antes de aprobarlo. La cohorte de desarrolladores se incorpora mañana. ¿Qué haces?

A · Lanzar con los servidores aprobados y registrar Playwright como pendiente. Añade Playwright a la siguiente agenda del CoE cuando TI lo autorice. La cohorte se incorpora según lo previsto.
B · Retrasar la cohorte hasta que Playwright esté aprobado. Un solo servidor no aprobado es motivo suficiente para detener el lanzamiento.
C · Añadir Playwright a la allowlist sin aprobación. Las herramientas de pruebas suponen un riesgo mínimo. La evaluación puede hacerse después del lanzamiento.

Ver respuesta

A es correcta. El Día 0 necesita una allowlist segura, no una completa. Lanza con lo que está aprobado, registra Playwright como pendiente y añádelo a la siguiente agenda del CoE en cuanto TI lo firme. Retrasar la cohorte entrega la primera impresión de tu activación a un calendario de evaluación que no controlas. Añadir un servidor no aprobado se salta el proceso que el equipo de seguridad del cliente acaba de respaldar.

Situación 3 · Semana 2. Un desarrollador necesita un servidor MCP de Figma para un hito de handoff de diseño con entrega el viernes. La reunión del CoE es el jueves. ¿Qué haces?

A · Instalación local ahora y aprobación retroactiva en el CoE del jueves. El desarrollador instala hoy. Tú lo planteas en el CoE para la aprobación formal.
B · Contactar directamente con el equipo de seguridad para una aprobación el mismo día. Saltarse el CoE para una revisión urgente, dada la presión de la fecha.
C · Agenda del CoE el jueves; instalar si se aprueba antes del viernes. Ponlo en la agenda del jueves. La aprobación en la misma semana permite al desarrollador cumplir el hito.

Ver respuesta

C es correcta. Aprobación el jueves, uso el viernes: el plazo de la misma semana es el objetivo que fija el Plan de activación de 30 días, y el CoE existe justamente para esta situación. Una instalación local antes de la aprobación socava en silencio la política que firmó el CISO del cliente. Saltarse el CoE con una vía de seguridad directa crea un proceso paralelo que, con el tiempo, entra en conflicto con la estructura de gobernanza que tú construiste.

El ritmo de gobernanza ya tiene sus piezas, pero el marco lo sostiene la configuración que fijas aquí: las entradas de la allowlist, los controles de egress y el alcance OAuth definen los límites que aplica el plugin, y estos ajustes viajan con él cuando se distribuye al equipo.

Ideas clave

La allowlist ya está definida. Ahora, los sistemas que aún no son alcanzables. La gobernanza de MCP no es una conversación de confianza, es configuración. La allowlist controla qué se puede instalar, los controles de egress limitan a dónde puede llamar, y el alcance OAuth hace que Claude solo llegue a lo que el desarrollador ya tiene permiso de acceder.

Con allowManagedMcpServersOnly: true, la allowlist se aplica; sin el flag, es orientativa.
Las instalaciones de usuario y los despliegues de la organización se gobiernan con controles distintos (.mcp.json y managed-mcp.json, respectivamente).
La allowlist y los controles de egress son una tarea del Día 0, no del Día 30.
Pre-kickoff, Día 0 y la reunión semanal del CoE forman el ritmo de gobernanza: inventario, allowlist inicial y aprobaciones de conectores.

Algunos sistemas internos están en la allowlist pero no son alcanzables desde el portátil del desarrollador. El relay MCP remoto es el puente. Su configuración lleva unos diez minutos.

Siguiente: MCP tunnel: puente con el desarrollo local