MCP no es un plugin: gobernar la capa de integración de agentes como API empresarial

Durante los últimos dos años, el problema práctico de trabajar con agentes fue la integración. Cada modelo tenía su forma de invocar herramientas, cada herramienta requería una adaptación específica, y conectar un agente con los sistemas internos de una organización significaba escribir pegamento que había que rehacer cada vez que cambiaba algo.

El Model Context Protocol —MCP— surgió como respuesta a ese problema: un estándar abierto para conectar aplicaciones de inteligencia artificial con fuentes de datos, herramientas y flujos de trabajo. La analogía habitual es la de un conector universal: en vez de N integraciones por M sistemas, un protocolo común.

La estandarización es genuinamente valiosa. El riesgo aparece en cómo las organizaciones la están adoptando: como si un servidor MCP fuera un plugin que se instala y ya. No lo es. Un servidor MCP es una puerta a tus sistemas, y toda puerta a tus sistemas es una superficie de riesgo que requiere gobierno.

Qué es realmente un servidor MCP desde el punto de vista de riesgo

Despojado del vocabulario técnico, un servidor MCP hace tres cosas: expone datos que un agente puede leer, expone herramientas que un agente puede invocar y define el contexto que el agente recibe.

Cualquiera de esas tres cosas, mal configurada, produce consecuencias serias. Un servidor que expone datos sin filtro entrega a un modelo información que la organización clasifica como restringida. Un servidor que expone herramientas de escritura permite a un agente modificar sistemas reales. Un servidor que inyecta contexto sin control puede alterar el comportamiento del agente de forma no auditada.

Dicho de otra forma: un servidor MCP tiene el mismo perfil de riesgo que una API empresarial con acceso a datos internos. Y las organizaciones ya saben gobernar APIs empresariales. El problema no es que falte el conocimiento. Es que MCP llegó por un camino distinto —el del experimento técnico, la instalación rápida, el piloto de un equipo— y por ese camino los controles habituales no se aplicaron.

Los controles que corresponden

La lista no es exótica. Es exactamente la que se aplicaría a cualquier integración empresarial:

Gestión de identidad y acceso. Cada servidor MCP debe autenticar quién lo invoca y autorizar qué puede hacer. Un servidor accesible sin autenticación dentro de la red interna es un servidor accesible para cualquier proceso comprometido dentro de la red interna.

Listas de permitidos explícitas. Qué agentes pueden conectarse, qué herramientas expone cada servidor, qué operaciones están habilitadas. Definido por enumeración, no por exclusión.

Auditoría. Registro de cada invocación: quién, qué herramienta, con qué parámetros, con qué resultado. Sin ese registro, un incidente es irreconstruible.

Gestión de secretos. Las credenciales que el servidor MCP usa para acceder a sistemas subyacentes deben vivir en un almacén de secretos, no en variables de entorno de un contenedor que alguien levantó a mano. Y deben ser rotables sin reconstruir el servidor.

Límites de tasa. Un agente en un ciclo defectuoso puede generar miles de llamadas en minutos. El límite protege tanto al sistema subyacente como al presupuesto.

Segregación de ambientes. El servidor MCP que un equipo usa para experimentar no debe apuntar a los mismos sistemas que el de producción. Esta separación se rompe constantemente porque el servidor de pruebas “necesitaba datos reales para probar bien”.

El problema de la proliferación silenciosa

Hay un riesgo específico de MCP que no comparte con las APIs tradicionales: la facilidad de instalación.

Levantar un servidor MCP es tan sencillo que cualquier persona con acceso a una terminal puede hacerlo en minutos, conectarlo a su asistente y empezar a trabajar. Eso es exactamente lo que hace al protocolo útil, y es también lo que hace que la organización pierda visibilidad.

El resultado predecible es un inventario en la sombra: servidores corriendo en máquinas de desarrollo, conectados a sistemas internos, con credenciales de las personas que los levantaron, sin registro, sin dueño formal y sin nadie monitoreando qué datos salen por ahí. No es una hipótesis alarmista: es el estado por defecto de cualquier tecnología que combine utilidad alta con barrera de instalación baja.

La respuesta no es prohibir. Prohibir produce el mismo inventario en la sombra, solo que además sin colaboración. La respuesta es ofrecer un camino oficial que sea más fácil que el informal: un conjunto de servidores MCP provistos por la organización, ya autenticados, ya auditados, ya conectados a los sistemas correctos con los permisos correctos.

Si el camino gobernado es más lento y más burocrático que levantarlo por cuenta propia, la gente lo va a levantar por cuenta propia. Ese es el criterio de diseño real.

Preguntas para evaluar un servidor MCP antes de habilitarlo

Antes de habilitar un servidor MCP para uso general, hay seis preguntas que conviene responder por escrito:

1. ¿A qué sistemas accede y con qué credencial?
2. ¿Qué herramientas expone y cuáles son de escritura?
3. ¿Quién es el dueño designado y quién aprueba cambios?
4. ¿Dónde queda el registro de invocaciones y cuánto tiempo se conserva?
5. ¿Qué pasa si falla o si hay que apagarlo de urgencia?
6. ¿Cómo se separa el ambiente de pruebas del de producción?

Ninguna de esas preguntas es sofisticada. Todas se responden en una página. La diferencia entre una organización que gobierna su capa de integración de agentes y una que no, muchas veces es exactamente esa página.

Los riesgos específicos del protocolo

Además de los riesgos que comparte con cualquier API, hay tres que son propios de esta capa y conviene tratarlos explícitamente.

Composición de herramientas. Un agente con acceso a varios servidores MCP puede combinar herramientas de formas que ninguno de los servidores anticipó por separado. Leer datos de un sistema y escribirlos en otro es una operación que quizá nadie autorizó como tal, aunque ambos permisos existan individualmente. El análisis de riesgo tiene que hacerse sobre el conjunto de herramientas disponibles para un agente, no servidor por servidor.

Contenido que instruye. Un agente que lee un documento, un ticket o un correo está procesando texto que puede contener instrucciones dirigidas a él. Si ese contenido proviene de fuera de la organización, alguien externo puede intentar influir en el comportamiento del agente a través del material que le llega. La mitigación es de diseño: separar claramente los datos que el agente lee de las instrucciones que sigue, y no otorgar a un agente que procesa contenido externo herramientas de escritura sobre sistemas sensibles.

Descripciones de herramientas como superficie de confianza. Un agente elige qué herramienta usar a partir de su descripción. Esas descripciones, cuando provienen de un servidor de terceros, son texto que la organización no escribió y que influye en el comportamiento del sistema. Un servidor MCP de origen externo debería revisarse con el mismo criterio con el que se revisa una dependencia de software: qué hace, quién lo mantiene, qué versión se está usando y si se fijó esa versión.

Ese último punto conecta con una práctica que conviene establecer desde el principio: fijar versiones. Un servidor MCP que se actualiza automáticamente puede cambiar el comportamiento de un agente sin que ningún cambio se haya hecho del lado de la organización. Es exactamente el escenario que hace imposible investigar una degradación: nada cambió, y sin embargo el sistema se comporta distinto.

Ninguno de estos tres riesgos es exótico ni requiere herramientas especiales. Los tres se mitigan con las mismas decisiones que se aplican a cualquier integración: enumerar lo permitido, fijar versiones, separar ambientes y revisar el conjunto en vez de las partes.

El punto de fondo

MCP es una buena noticia para las organizaciones. Un estándar abierto reduce el acoplamiento con proveedores, simplifica la arquitectura y baja el costo de conectar agentes con el trabajo real.

Pero un estándar de integración no viene con gobierno incluido. El gobierno lo pone la organización, o no lo pone nadie. Y el momento de ponerlo es cuando hay tres servidores y todos caben en una conversación, no cuando hay treinta y nadie sabe cuáles siguen vivos.