Servidores MCP gestionados en Claude Code: auditoría de despliegue empresarial

Claude Code 2.1.259 incorpora un ajuste administrado llamado managedMcpServers. Según Anthropic, una organización puede usarlo para proporcionar a todos sus usuarios entradas de servidores MCP con transporte HTTP o SSE. La estructura de cada entrada es la misma que en .mcp.json. Si una entrada indica un comando que debe ejecutarse, Claude Code la omite en esta configuración gestionada.

La misma versión añade --permission-prompts none para hosts headless sin supervisión. Cuando una operación habría requerido una pregunta de permisos, se deniega automáticamente; el modo de permisos activo sigue resolviendo las decisiones que puede tomar sin esa pregunta. También se incorpora salida JSON a claude plugin validate y se corrige un problema por el que sesiones concurrentes podían revertir cambios mutuos en ~/.claude.json.

Anthropic documenta además correcciones para ampliar la cobertura de reglas de denegación al acceder a archivos mediante distintas formas de comandos Bash. No afirma que estos cambios certifiquen un servidor MCP, garanticen decisiones correctas, eliminen todos los riesgos del shell o produzcan mejoras de rendimiento. Tampoco especifica precio, residencia de datos, disponibilidad contractual ni resultados empresariales garantizados.

La interpretación operativa de CreatikLab es concreta: la gestión central puede reducir configuraciones divergentes; la validación legible por máquinas puede reforzar la evidencia de una entrega; y la denegación automática evita depender de una respuesta humana inexistente. Ninguna de esas ventajas reemplaza la aprobación del propósito, los datos, la identidad, los permisos y las consecuencias del flujo.

El error habitual consiste en empezar por una lista de servidores y terminar preguntando para qué se necesitan. Conviene invertir el orden. Define la tarea empresarial, el sistema afectado, la información mínima necesaria y el resultado permitido. Consultar documentación interna en modo lectura no tiene la misma exposición que modificar un repositorio, cerrar una incidencia o alterar datos de clientes.

La distribución central tampoco convierte un uso legítimo en legítimo para todos los equipos. Una integración puede ser adecuada para ingeniería y excesiva para marketing; o apropiada en pruebas y no en producción. Estas distinciones forman parte del método de implantación de CreatikLab, no son clasificaciones automáticas atribuidas a Claude Code.

• Propósito: tarea autorizada y usos expresamente excluidos.
• Datos: repositorios, sistemas, campos y secretos accesibles.
• Ejecución: equipo interactivo, proceso controlado o host desatendido.
• Decisión: acciones autónomas y acciones que requieren aprobación humana.
• Evidencia: registros, validaciones y cambios conservados para auditoría.

La siguiente matriz es un marco original de decisión. Parte de las funciones confirmadas por Anthropic, pero las categorías y acciones son criterios operativos que debe aprobar cada organización.

• Lectura de datos no sensibles y bajo impacto — Evidencia: métodos documentados y respuestas de prueba. Acción: piloto limitado. Responsable: administrador de herramientas.
• Lectura sensible sin escritura — Evidencia: identidad, restricciones por campo y logs de acceso. Acción: aislar credenciales y obtener revisión de seguridad. Responsables: propietario del sistema y seguridad.
• Escritura reversible — Evidencia: sandbox, prueba de repetición y procedimiento de reversión. Acción: mantener aprobación humana durante el aprendizaje. Responsable: dueño del flujo.
• Acción irreversible o con efecto externo — Evidencia: autorización explícita, control independiente y plan de incidente. Acción: no usar el reparto central ni la ausencia de prompts como autorización. Responsable: dirección del proceso.
• Capacidad desconocida o ruta de datos sin documentar — Evidencia: insuficiente. Acción: excluir del catálogo hasta cerrar la brecha. Responsable: patrocinador de la integración.

Regla práctica: una entrada solo debe pasar al catálogo gestionado cuando su finalidad, identidad, límite de datos y mecanismo de revocación estén tan claros como la comodidad que aporta distribuirla. Si falta uno de esos elementos, mantén un experimento restringido.

Empieza inventariando los archivos .mcp.json existentes. Separa las conexiones HTTP o SSE de las entradas que ejecutan comandos locales. Anthropic indica que estas últimas se omiten en managedMcpServers; por tanto, una migración no debe declararse completa sin comparar qué configuraciones llegaron realmente a los usuarios.

Crea después un registro con nombre del servidor, endpoint aprobado, transporte, finalidad, clasificación de datos, propietario de credenciales, entornos permitidos y contacto de revocación. Prueba la configuración en un ámbito no productivo y limitado. Comprueba que los usuarios previstos la reciben, que otros flujos no obtienen acceso y que una credencial ausente o revocada provoca un fallo visible y seguro.

Ejecuta la validación de plugins y conserva la salida JSON que Anthropic ha incorporado. Ese archivo demuestra el resultado de una validación, no la corrección del proceso empresarial. Añade pruebas positivas, pruebas negativas y una inspección de logs. Solo entonces amplía el despliegue mediante una decisión firmada por los responsables.

1. Inventariar y clasificar el transporte de cada entrada.
2. Aprobar endpoint, identidad, propósito y datos.
3. Diseñar pruebas permitidas, prohibidas y de revocación.
4. Validar plugins y archivar el informe JSON.
5. Ejecutar un piloto con usuarios y repositorios identificados.
6. Revisar fallos, denegaciones y solicitudes inesperadas.
7. Ampliar o revertir mediante una decisión registrada.

--permission-prompts none resuelve un problema específico: no hay una persona disponible para contestar. Anthropic afirma que aquello que hubiese generado una solicitud se deniega, mientras el modo de permisos activo sigue tomando el resto de decisiones. No significa permiso general ni elimina la necesidad de configurar ese modo con cuidado.

Para cada acción importante, modela tres resultados: permitida por una regla explícita, prohibida por una regla explícita o denegada porque habría requerido interacción. El flujo debe registrar la causa, detener la parte afectada y avisar a un responsable. No debe ampliar permisos, repetir indefinidamente ni presentar una ejecución incompleta como éxito.

CreatikLab recomienda usar identidades separadas para automatización y desarrollo, restringir cada flujo a sistemas concretos y probar credenciales caducadas, endpoints inaccesibles y archivos prohibidos. La corrección de Anthropic sobre reglas deny cubre más formas de suministrar archivos a comandos, pero no debe interpretarse como garantía sobre cualquier composición futura del shell o cualquier herramienta externa.

• Definir cómo aparece una denegación en logs y alertas.
• Limitar reintentos de red y no reintentar una denegación de permisos.
• Asignar escalado humano a las acciones empresariales bloqueadas.
• Impedir que el flujo cambie su propio modo de permisos.
• Revocar credenciales y terminar sesiones durante la reversión.

Una auditoría útil termina con artefactos inspeccionables. No basta con afirmar que la configuración es corporativa. Cada control debe tener una prueba, una corrección posible y una persona responsable.

• Catálogo gestionado — Evidencia: archivo managedMcpServers versionado. Acción: cotejar endpoints con el registro aprobado. Responsable: plataforma.
• Entradas omitidas — Evidencia: comparación de migración. Acción: retirar, sustituir o controlar localmente cada comando. Responsable: integración.
• Autenticación — Evidencia: mapa de credenciales y prueba de revocación. Acción: eliminar secretos compartidos. Responsable: seguridad.
• Plugins — Evidencia: informe JSON de validación. Acción: bloquear la entrega si quedan fallos. Responsable: release.
• Permisos — Evidencia: transcripción de casos permitidos y denegados. Acción: reconciliar resultados con la política. Responsable: propietario del flujo.
• Concurrencia — Evidencia: prueba con varias sesiones y versión instalada. Acción: verificar que no se pierde estado. Responsable: operaciones de ingeniería.
• Archivos protegidos — Evidencia: pruebas negativas con formas relevantes de comando. Acción: investigar cualquier lectura inesperada. Responsable: pruebas de seguridad.
• Reversión — Evidencia: simulacro cronometrado. Acción: quitar configuración, revocar credenciales y confirmar el cierre. Responsable: incidentes.

Separa la salud del control del resultado comercial. Entre las métricas operativas pueden figurar el porcentaje de entradas con responsable aprobado, estado de validación por versión, denegaciones inesperadas, fallos en pruebas de acciones prohibidas, resultado de las revocaciones y divergencia de configuración. Son métricas propuestas por CreatikLab; Anthropic no fija objetivos numéricos en la nota de versión.

Si la automatización participa en marketing o ventas, vincula cada ejecución a un registro trazable. Define un lead cualificado mediante criterios acordados: mercado atendido, encaje con el servicio, datos de contacto legítimos y aceptación comercial, por ejemplo. Una fila enriquecida, un formulario o una tarea creada por un agente no son por sí solos una oportunidad cualificada.

La especificación mínima de medición debería incluir evento, momento, versión del flujo, identidad del servidor, resultado de permisos, registro de origen, disposición final y responsable. Distingue finalización válida, acción bloqueada, escalado humano, salida inválida y aceptación posterior. Así se puede evaluar la contribución del sistema sin prometer más leads ni ocultar errores.

No supongas que una configuración gestionada autoriza cualquier uso, que HTTP o SSE demuestra la confianza del endpoint o que un plugin válido toma decisiones válidas. Tampoco supongas que eliminar prompts permite la operación: Anthropic describe una denegación automática. Las entradas que nombran un comando no se distribuyen mediante este ajuste porque se omiten.

Revisa también el alcance excesivo, credenciales compartidas, cambios no aprobados en el servidor, registros incompletos, dependencias ocultas y procesos que confunden una denegación con un éxito. La nota oficial no detalla retención, certificación de endpoints, residencia de datos, disponibilidad del servicio remoto ni prestaciones. Cada punto necesita revisión técnica o contractual independiente.

CreatikLab puede entregar una auditoría de control para automatización empresarial con IA: registro MCP gestionado, modelo de permisos, pruebas de fallo en hosts desatendidos, informes de validación, límites de credenciales, especificación de logs y simulacro de reversión. Consulta el alcance en nuestro servicio de automatización con IA. Para continuar el diagnóstico con contexto, explica a Lia qué servidores, datos, procesos y entornos quieres conectar; la recomendación debe adaptarse a esa situación.

¿Qué hace managedMcpServers en Claude Code?

Anthropic indica que permite proporcionar a todos los usuarios entradas gestionadas para servidores MCP HTTP o SSE con la estructura de .mcp.json. Las entradas que nombran un comando se omiten.

¿La configuración central garantiza que el servidor sea seguro?

No. Anthropic no formula esa garantía. La organización debe revisar la confianza del endpoint, la identidad, los datos accesibles, las acciones, los logs y la revocación.

¿Qué ocurre con --permission-prompts none?

En un host headless sin supervisión, se deniega automáticamente una operación que habría requerido una pregunta. El modo de permisos activo sigue decidiendo las demás operaciones.

¿Se pueden distribuir servidores MCP basados en comandos?

No mediante este ajuste tal como lo describe Anthropic: las entradas que indican un comando se omiten. Debe documentarse su retirada, sustitución o control local separado.

¿Es suficiente la validación JSON para producción?

No. El informe sirve como evidencia de release, pero debe acompañarse de pruebas funcionales, negativas, de permisos, revocación y reversión.

¿Qué debería entregar un proveedor de implantación?

Un registro de servidores, límites de identidad y datos, pruebas de permisos, informes de validación archivados, especificación de logs y métricas, responsables y una reversión demostrada.