)
Última actualización: 16 de octubre, 2026
¿Por qué importan los registros de servidores MCP para las empresas del Reino Unido cuando los agentes pueden añadir sus propias tools?
Un registro lista qué servidores del Model Context Protocol pueden descubrir tus agentes. Un gateway hace cumplir qué servidores y tools pueden llamar realmente. La propia documentación de GitHub dice que el modo registry-only de Copilot compara nombres e IDs de servidor, así que editar un archivo de configuración puede saltárselo. Esa brecha es la razón por la que un registro por sí solo es una recomendación, no un control.
TL;DR: puntos clave
- GitHub marca el modo "Registry only" de Copilot como public preview, indica que el bloqueo estricto de servidores fuera del registro aún no está disponible y que editar archivos de configuración puede saltarse la aplicación (GitHub Docs).
- En Visual Studio, la preview de noviembre de 2025 de GitHub ofrecía solo descubrimiento por registro, sin aplicación de la allowlist, así que todos los servidores podían ejecutarse con independencia de la política (GitHub Changelog).
- La guía de IA publicada por DEFRA limita MCP a proyectos piloto designados, lista seis servidores aprobados y exige aprobación por escrito para cualquier otro (DEFRA).
- El blog del NCSC del 15 de mayo de 2026 aconseja mínimo privilegio y una supervisión humana real para los agentes (NCSC).
- El CVE-2026-103572 (CVSS 8,8) permitió que un bypass de validación de rutas en Visual Studio Copilot escribiera en archivos protegidos, incluida la configuración MCP, y se corrigió el 13 de octubre de 2026 (ToolNavs).
De un vistazo: registros de servidores MCP frente a gateways
Respuesta rápida
¿Qué deben incluir los registros de servidores MCP para empresas del Reino Unido?
Un catálogo aprobado de servidores MCP con propietarios, versiones, permisos y fechas de revisión, más un punto de control en runtime que bloquee todo lo que no esté en la lista. Los registros responden a descubrimiento y aprobación. Los gateways responden a la aplicación. Planifica asumiendo que un ajuste de registro en el cliente puede esquivarse editando archivos, y no dejes que los agentes editen su propia configuración MCP.
| Aspecto | Registro MCP privado | Gateway MCP |
|---|---|---|
| Función principal | Descubrir y registrar servidores aprobados | Hacer cumplir qué servidores y tools se ejecutan |
| Propietarios habituales | Equipo de plataforma y comité de revisión | Seguridad y plataforma |
| Modo de fallo si se usa solo | Configuración local editada para saltarse el catálogo | El catálogo se desfasa y el gateway permite tools obsoletas |
| Punto de aplicación | Ajustes y política del cliente | Ruta de red entre agentes y tools |
)
Qué son los registros de servidores MCP
El ecosistema público de MCP tiene una especificación de registro para el descubrimiento de servidores. Las empresas necesitan un registro privado y aprobado: un subconjunto revisado que tus asistentes pueden usar. Según GitHub (2025), los administradores pueden subir la URL de un registro interno en las políticas de Copilot, alojado en Azure API Center o autoalojado según la especificación v0.1 del registro MCP.
La política tiene entonces dos ajustes. "Allow all" trata el registro como una lista de proveedores recomendados, y los desarrolladores aún pueden usar cualquier servidor. "Registry only" significa que solo pueden ejecutarse los servidores del registro, y los demás se bloquean con un mensaje de política. Los servidores remotos se comprueban por nombre y URL de instalación. Los servidores locales se comprueban solo por nombre.
Por qué un registro por sí solo no es aplicación
La documentación de GitHub es directa sobre los límites. Según GitHub Docs (2026), la aplicación se basa solo en coincidir nombres o IDs de servidor, así que editar archivos de configuración puede saltársela. El bloqueo estricto que impide instalar servidores fuera del registro aún no está disponible, y GitHub recomienda desactivar los servidores MCP en Copilot para la máxima seguridad hasta que lo esté. El ajuste Registry only está además marcado como public preview.
Eso no vuelve inútiles los registros. Aportan el registro de aprobación, los propietarios y el descubrimiento. Significa que la aplicación debe estar en un lugar que un agente o un desarrollador no pueda editar desde su portátil.
CVE-2026-103572 en un solo lugar
Según un informe de ToolNavs (2026) sobre la divulgación de Johann Rehberger, un bypass de validación de rutas en Copilot para Visual Studio y SQL Server Management Studio permitió que una indirect prompt injection escribiera en archivos protegidos. Esos archivos incluyen la configuración MCP y los ajustes de Visual Studio, lo que puede llevar a la ejecución de comandos arbitrarios. La puntuación CVSS es 8,8. Microsoft publicó las correcciones el 13 de octubre de 2026, y el informe indica que no hay explotación confirmada en la práctica.
La lección para los registros es acotada. Si un agente puede escribir en el archivo que define qué servidores se ejecutan, el registro es consultivo. Trátalo como una ilustración y consulta el aviso de Microsoft para los detalles autorizados.
Acceso MCP privilegiado fuera de cualquier registro
CloudSEK informó en octubre de 2026 de que un afiliado de la ransomware Gentlemen usó un servicio MCP en un puerto local, autenticado con un bearer token fijo, como canal de comandos durante intrusiones en curso (Daily Security Review). Es un caso criminal, no un fallo de registro, pero muestra lo que puede hacer un endpoint MCP con amplios derechos de ejecución y una credencial estática.
Cómo aborda la aprobación de MCP un organismo público del Reino Unido
DEFRA publica guía de IA para sus equipos de entrega. A 16 de octubre de 2026 dice que MCP está en revisión y que solo los proyectos piloto designados pueden usarlo. Nombra seis servidores aprobados: Azure, AWS, SonarQube, Atlassian, GitHub y Azure DevOps. Cualquier otro servidor necesita la aprobación por escrito del arquitecto del proyecto y del equipo central de IA.
La misma guía fija reglas prácticas: no aprobar nunca automáticamente acciones MCP, usar OAuth y no tokens de acceso personal, fijar versiones, usar permisos de mínimo privilegio y mantener MCP alejado de datos sensibles y personales. No describe un registro interno. Trátala como un ejemplo público de allowlist con aprobadores con nombre, no como una declaración de lo que el gobierno del Reino Unido espera de todas las organizaciones.
Cómo construir un flujo de aprobación de servidores MCP
| Paso | Criterios de revisión | Desencadenante de nueva revisión |
|---|---|---|
| Solicitud | Propietario de negocio, clases de datos, transporte | Nuevo propietario |
| Revisión de seguridad | Autenticación, permisos, salida de red, gestión de secretos | Cambio de versión |
| Fijar | Versión exacta o digest de imagen | Cualquier release upstream |
| Publicar | Entrada de registro y política de gateway | Cambio de permisos |
| Retirar | Quitar del registro y del gateway | CVE o uso indebido |
Pon Agent Gateway (TrustGate) entre los agentes y los servidores MCP para tener un único punto de política y logging, con permisos y límites por agente. Añade Agent Runtime Security (TrustGuard) para vigilar las tool calls mientras ocurren. Consulta también nuestras guías sobre AI gateways frente a MCP gateways y los mejores MCP gateways.
Cómo lo comparamos
Usamos la documentación y el changelog de GitHub para el comportamiento del registro, la guía publicada por DEFRA como ejemplo del sector público del Reino Unido y el NCSC para la orientación de mínimo privilegio. El informe de CloudSEK nos llega a través de un resumen de prensa especializada, y el CVE-2026-103572 a través de un informe secundario. Las distinciones entre registro y gateway siguen la práctica operativa, no una norma legal.
Cuándo involucrar a los equipos de red team
Cuando el modo registry-only esté activo en producción, pide a los equipos de red team que intenten instalar un servidor MCP malicioso a través de portátiles de desarrolladores, tokens de CI y clústeres de staging olvidados. Lleva los hallazgos a la lista de comprobación de aprobación. El registro es tan fuerte como la ruta más débil que aún pueda registrar o llamar a un servidor fuera de él. Repite el ejercicio cada año y tras cualquier cambio importante de IDE o de plataforma de CI.
Lenguaje de compras que evita la proliferación de MCP
Actualiza los cuestionarios a proveedores para preguntar si un producto incluye servidores MCP, si esos servidores están firmados y versionados y si el proveedor admite la distribución mediante un registro privado. Prefiere proveedores que publiquen un inventario de sus tools y acepten límites contractuales sobre qué tools pueden activarse en tu tenant. Rechaza los permisos genéricos permanentes para que los usuarios finales instalen tools en entornos regulados.
Para los equipos internos de plataforma, añade la publicación de servidores MCP a la misma vía de gestión de cambios que la publicación de APIs. Un servidor nuevo es una superficie de ataque nueva, no un ajuste de configuración casual.
Métricas que muestran que el programa funciona
Sigue cuatro cifras al mes: la proporción de conexiones MCP que se resuelven a través del registro privado, el tiempo mediano de aprobación, los endpoints en la sombra bloqueados y los incidentes con tools no aprobadas. Comparte la tendencia con el CISO y los responsables de plataforma. Un tiempo de aprobación al alza sin corregir el proceso significa que el registro se esquivará. Menos descubrimientos en la sombra tras la aplicación significa que el control funciona.
Acompaña las métricas con una narrativa breve para auditoría: quién es el propietario del registro, cada cuánto se hacen revisiones y dónde viven los logs. A los auditores les importa menos tener cero excepciones que un ciclo cerrado desde el descubrimiento hasta la decisión y la aplicación.
Despliegue del modo registry-only sin bloquear la entrega
Empieza con un piloto: un equipo de plataforma y dos equipos de aplicación. Lista los servidores MCP que ya usan, pásalos por la tabla de aprobación y publica el primer registro privado. Activa la aplicación registry-only en el piloto, observa qué se rompe y luego amplía. Limita en el tiempo las excepciones y exige controles compensatorios, como egress de red denegado por defecto más aprobación humana para añadir tools.
Documenta la relación entre el registro y el gateway en tu estándar de desarrollo seguro. El registro es la fuente de verdad del estado de aprobación. El gateway es el punto de aplicación. La detección de deriva debe alertar cuando una tool en runtime no esté en el registro o cuando una entrada del registro no tenga política de gateway.
Seguridad y gobernanza: riesgos empresariales del descubrimiento abierto de MCP
El descubrimiento abierto sin aplicación invita a la prompt injection en la elección de tools, a la fuga de datos por servidores con permisos excesivos y al uso indebido de tools cuando los agentes añaden sus propios comandos. La gobernanza necesita un comité de aprobación y un punto de control en runtime.
NeuralTrust aborda el control de MCP mediante la Runtime Security Mesh. TrustGate define permisos y límites por agente, incluye más de 200 servidores MCP preconfigurados y actúa como punto de política y logging entre agentes y tools. TrustLens inventaría agentes y conexiones MCP. TrustGuard monitoriza el uso de tools en runtime. TrustTest hace red teaming de las configuraciones antes de producción. NeuralTrust se despliega en tu propia infraestructura o on-premises, con un servicio gestionado alojado en la UE o en EE. UU. La plataforma suma cuatro reconocimientos en los Gartner Hype Cycle 2026, incluido AI Runtime Defense.
¿Cuál deberías elegir?
| Equipo | Primer paso | Capacidad |
|---|---|---|
| Equipos de desarrollo con asistentes de código | Ajustes de registro más una lista aprobada | Registro |
| Equipos de plataforma | Flujo de aprobación y fijado de versiones | Registro y gateway |
| Empresas reguladas | Denegar por política la instalación de tools y registrar cada llamada a servidor | Gateway y monitorización en runtime |
Conclusión
Los registros de servidores MCP para empresas del Reino Unido convierten la confianza ad hoc en plugins en una lista aprobada con propietarios y fechas de revisión. Combínalos con un gateway, porque la propia documentación de GitHub dice que la aplicación del registro en el cliente puede esquivarse editando la configuración. Toma las ideas de gobierno que encajen, como aprobadores con nombre y versiones fijadas, aplica en runtime y vuelve a revisar con cada cambio de versión. Así una allowlist se convierte en un control y no en una página de wiki.
Asegura las allowlists de MCP en producción con NeuralTrust
Aprueba servidores en un registro, contrólalos en el gateway y monitoriza cada tool call.
)
Comparativas relacionadas
- Top 5 MCP gateways para empresas del Reino Unido 2026
- Los 6 mejores MCP gateways para empresa (2026)
- AI Gateway frente a MCP Gateway: diferencias clave
- Directrices del NCSC sobre IA para empresas del Reino Unido 2026
Preguntas frecuentes sobre registros de servidores MCP
1. ¿Qué es un registro MCP?
Un catálogo de servidores del Model Context Protocol que los clientes pueden descubrir y, opcionalmente, tratar como una allowlist. Los registros públicos ayudan al descubrimiento del ecosistema. Las empresas deberían operar un registro privado aprobado para que los asistentes solo vean servidores que tu equipo de plataforma ha revisado en cuanto a permisos, gestión de secretos y responsabilidad del propietario.
2. ¿En qué se diferencia un registro de un gateway?
Los registros anotan qué está aprobado y quién es su propietario. Los gateways hacen cumplir qué puede ejecutarse, incluidas las decisiones de permitir y denegar a nivel de tool. Necesitas ambos: un catálogo sin aplicación es consultivo, y un gateway sin catálogo deriva hacia excepciones sin documentar.
3. ¿Puede GitHub Copilot hacer cumplir un registro privado?
En parte. El modo Registry only de GitHub bloquea los servidores que no están en el registro, pero la aplicación se basa en coincidir nombres o IDs de servidor, el bloqueo estricto aún no está disponible y la función está en public preview. Visual Studio ofrecía descubrimiento sin aplicación en la preview de noviembre de 2025. Consulta la documentación actual para tu tenant antes de prometer el modo registry-only a un auditor.
4. ¿Es obligatorio el enfoque de DEFRA para las empresas del Reino Unido?
No. La guía de DEFRA es un ejemplo del sector público de una lista aprobada con aprobadores con nombre y excepciones por escrito. No es un estándar para empresas privadas. Las empresas reguladas pueden aplicar la misma lógica de mínimo privilegio que describe el NCSC en su guía de IA agéntica.
5. ¿Qué cambió con el CVE-2026-103572?
Ilustró que un agente capaz de escribir en archivos de configuración protegidos puede influir en qué comandos ejecuta un IDE, incluida la configuración MCP. Microsoft publicó correcciones el 13 de octubre de 2026. La lección de gobierno es impedir que los agentes editen su propia configuración MCP y aplicar la política fuera del cliente.
6. ¿Cada cuánto debemos revisar los servidores?
Revisa con cada cambio de versión, de permisos o ante un CVE relevante, y con una cadencia fija de calendario para las tools de alto riesgo. Sigue cada mes el tiempo mediano de aprobación y los descubrimientos de MCP en la sombra para que el proceso siga siendo más rápido que los atajos informales en portátiles de desarrolladores y runners de CI.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
- GitHub Docs, MCP allowlist enforcement, consultado el 16 de octubre de 2026.
- GitHub Docs, Restrict MCP access to registry servers, consultado el 16 de octubre de 2026.
- GitHub Changelog, MCP registry and allowlist controls for VS Code Stable in public preview, 18 de noviembre de 2025.
- DEFRA, MCP guidance in the AI SDLC, consultado el 16 de octubre de 2026.
- NCSC, Thinking carefully before adopting agentic AI, 15 de mayo de 2026.
- ToolNavs, Copilot flaw CVE-2026-103572: one trailing dot bypasses validation, octubre de 2026.
- Daily Security Review, Gentlemen ransomware affiliate used MCP as command channel, 7 de octubre de 2026.