MCP No es un conector: es su superficie de gobernanza para la era de los agentes

El problema del encuadre: "conector" subestima la decisión que realmente estás tomando

Cuando Anthropic presentó el Protocolo de Contexto de Modelos (MCP) en noviembre de 2024 como un estándar abierto para conectar sistemas de IA con fuentes de datos y herramientas empresariales, la industria hizo lo que suele hacer con una nueva especificación de integración: archivó MCP bajo la categoría de "infraestructura". Adaptadores, protocolos de transporte, una forma ordenada de dejar de escribir código de conexión único para cada modelo y cada herramienta. Todo true, y todo irrelevante para quien ocupe el puesto de CIO, CTO o CISO.

Aquí radica la clave para una empresa. En el momento en que un agente puede acceder a una herramienta que lee los datos de sus clientes o escribe en sus sistemas de registro, se crea un nuevo punto de control, independientemente de si se le ha asignado un nombre o no. MCP es el lugar donde se puede definir explícitamente ese punto de control. No se trata simplemente de cómo el agente accede a sus herramientas; se trata de dónde se decide quién realiza la llamada, con qué identidad, qué herramientas son visibles, cómo se registra cada llamada y cuál es el costo permitido para cada una. Estas son cuestiones de gobernanza, no de conectividad.

Si se trata a MCP como una función de conectividad, se optimizará lo incorrecto: cobertura, número de integraciones, tiempo hasta la primera llamada. Si se trata como una superficie de gobernanza, se optimizará lo que realmente determina si los agentes pueden implementarse de forma segura a gran escala: una interfaz única, estandarizada y auditable donde la política se aplica una sola vez y se observa en todas partes.

Por qué las "numerosas integraciones personalizadas" recrean silenciosamente la gobernanza N veces

La mayoría de las empresas no llegan a la era de los agentes con un historial limpio. Llegan con una cartera de integraciones puntuales: un conector a medida por aquí, una cuenta de servicio por allá, un envoltorio API que un equipo creó hace dos trimestres y que nadie recuerda del todo. Cada una de estas fue una decisión local razonable. En conjunto, representan un problema de gobernanza, ya que cada una reimplementa la identidad, la autorización, el registro y el control de tarifas/costos a su manera, o bien omite algunos de estos aspectos por completo.

Como era de esperar, siguen tres modos de falla. Primero, cambios de identidad: una integración se ejecuta como una cuenta de servicio compartido, otra se hace pasar por el usuario final, una tercera usa una clave de larga duración creada por alguien que desde entonces cambió de equipo, entonces "¿quién hizo esto?" tiene N respuestas diferentes, ninguna completa. En segundo lugar, los fragmentos de autorización, porque las reglas sobre lo que puede hacer una herramienta residen en N bases de código con N cadencias de revisión; un control que apretaste en un lugar permanece silenciosamente flojo en otro. En tercer lugar, lo que las finanzas y la auditoría consideran primero, los números varían, ya que la misma pregunta respondida a través de dos vías de integración arroja dos respuestas. Una vez que las partes interesadas dejan de confiar en los números, el programa de agentes deja de importar.

La alternativa estandarizada no es ni mágica ni gratuita, pero transforma la forma de trabajar. En lugar de gestionar N integraciones N veces, se gestiona una interfaz una sola vez y se exponen las herramientas a través de ella de forma deliberada. La identidad se establece en un único lugar. La autorización es una propiedad de la interfaz, no una práctica de cada conector. El registro es uniforme, por lo que el registro de auditoría es realmente un registro. Y los números dejan de variar porque existe una única ruta para calcularlos.

Identidad y contexto del inquilino: se decide al inicio, no en la herramienta

La primera pregunta que debe responder una superficie de gobernanza es a quién pertenece la autoridad de una llamada. En un contexto SaaS multiusuario, esto es complejo, ya que intervienen dos factores distintos: la identidad de quien realiza la llamada (qué agente actúa para qué usuario o servicio) y el contexto del usuario en el que se desarrolla la llamada (qué datos y permisos de cliente se aplican). Si se confunden, se produce el clásico error de agente confuso, donde un agente legítimamente autenticado para un propósito determinado termina actuando con privilegios que nunca debería haber heredado.

La práctica que vale la pena adoptar consiste en derivar el contexto del inquilino del enlace del inquilino en el servidor, no de lo que la sesión del usuario indique. En nuestra implementación, el nivel de cliente que controla el acceso a las funciones se resuelve a partir del contexto del inquilino, nunca se lee de la sesión del usuario, precisamente para que este no pueda ampliar su alcance presentando una sesión con información más detallada. La identidad indica quién pregunta; el contexto del inquilino indica dentro de qué universo de datos y derechos debe calcularse la respuesta. Ambos se deciden al inicio, antes de que se ejecute cualquier herramienta.

Aquí también es donde usted decide que los agentes no son usuarios. Un humano en una consola tiene ojos, dudas y un administrador. Un agente tiene un bucle. La identidad y el contexto que le otorgue deben reflejar que puede actuar más rápido y de manera más literal que cualquier persona que haya proporcionado.

Autorización por herramienta: la exposición es una decisión, no una configuración predeterminada

El valor predeterminado más común y más peligroso en las primeras implementaciones de agentes es la exposición de todo o nada: conectar el agente a la plataforma y dejar que alcance todo lo que puedan alcanzar las credenciales subyacentes. Conveniente en una demostración, indefendible en producción. Una superficie de gobernanza trata la visibilidad y el permiso de cada herramienta como una decisión deliberada y revisable.

En concreto, la autorización debería ser multiaxial en lugar de un único interruptor de encendido/apagado. Usamos un modelo de tres ejes (alcance y nivel, con el nivel proveniente del contexto del inquilino como se describió anteriormente) para que una herramienta determinada se exponga solo cuando el alcance de la persona que llama lo permite y el nivel del inquilino la incluye. El punto del segundo eje es que la capacidad no es sólo una función de quién la solicita sino de qué derechos de cliente están vigentes. Esto mantiene la superficie de exposición honesta: agregar una nueva herramienta al catálogo no hace que sea accesible para todos los agentes de cada inquilino.

El modelo mental que se debe presentar a los arquitectos es un catálogo, no una centralita. Cada herramienta del catálogo se ganó su lugar mediante una decisión sobre quién puede usarla y bajo qué condiciones de uso. Las herramientas que ningún agente necesita actualmente simplemente no están en el catálogo. La economía del "todo o nada" es una economía false; la "selección deliberada de herramientas" es la única postura que sobrevive al contacto con una auditoría real.

Escribe sobre el fallo cerrado: la asimetría entre la lectura y la acción

Las lecturas y escrituras no son moralmente equivalentes, y tu sistema de gobernanza no debería pretender que lo sean. Una lectura errónea devuelve datos obsoletos o vacíos, recuperables y a menudo invisibles. Un error de escritura altera un sistema de registro, envía un mensaje a un cliente real o transfiere dinero. El costo de equivocarse es asimétrico, por lo que la postura predeterminada también debe serlo.

La regla que mantenemos es que las herramientas de escritura fallan al cerrarse. Si la autorización es ambigua, si el contexto del inquilino no se puede resolver limpiamente, si no se puede evaluar un guardia, la escritura no se produce. Esto es lo opuesto al valor predeterminado impulsado por la conveniencia que heredan muchas integraciones, donde una verificación no evaluada resuelve "permitir" para que el camino feliz se mantenga fluido. La apertura fallida es la forma en que descubres, semanas después, que un agente estaba escribiendo en condiciones que nadie aprobó nunca. Para cualquier cosa que cambie de estado o afecte a un cliente, el valor predeterminado seguro es el rechazo, y la carga de la prueba recae en el llamado a demostrar que está permitido.

Aquí hay una dimensión cultural. Los ingenieros optimizan para que las cosas funcionen; la seguridad optimiza para que las cosas no fallen de la peor manera. Una superficie de gobernanza es donde se codifica que la peor manera —una escritura no autorizada ejecutada silenciosamente— es inaceptable, incluso a costa de rechazar ocasionalmente una escritura que habría sido aceptable.

Libros de presupuesto y el interruptor de emergencia: la gestión de costes como control de primera clase.

Los agentes introducen una categoría de riesgo que las integraciones tradicionales en su mayoría no presentaban: el gasto autónomo. Un bucle que llama a herramientas puede, a través de un error o un mensaje adverso, llamarlas mucho más de lo que nadie pretendía: quemar API presupuesto, generar cargos posteriores o inundar a los clientes. Por lo tanto, el control de costos pertenece a la superficie de gobernanza, no a ser agregado posteriormente como una alerta de facturación que se activa una vez que el daño está hecho.

El mecanismo que utilizamos es un registro de presupuesto que se evalúa antes de cualquier gasto, con límites por ejecución, por día y rotativos de 30 días, además de un interruptor de seguridad que se verifica antes de la ejecución. Nótese el orden: el presupuesto y el interruptor de emergencia se evalúan antes del gasto, no se concilian después. Una alerta que indica un gasto excesivo es un análisis posterior al gasto; un registro que rechaza la solicitud de sobrecoste es un control. Los tres horizontes temporales son importantes porque los modos de fallo tienen diferentes características: un bucle descontrolado supera el límite por ejecución, una programación mal configurada supera el límite diario y el aumento gradual solo se manifiesta en el plazo de 30 días.

El interruptor de emergencia merece su propia línea en el diseño. Es el control al que se recurre cuando aún no se comprende lo que está sucediendo y se necesita detener la actividad de inmediato. Evaluado antes de la ejecución, es un disyuntor, no una herramienta de limpieza. Cada programa agente debería poder responder instantáneamente a una pregunta: ¿cómo lo detenemos? Si la solución implica contactar a tres equipos y revocar claves manualmente, no tienes un interruptor de emergencia, solo una esperanza.

Auditoría y edición: alcance definido, plazos limitados y observables

La gobernanza que no se puede observar no es gobernanza; es intención. La capa final de la superficie es la que hace que todo lo que está por encima sea demostrable a posteriori. Las claves de agente deben limitarse a las herramientas que realmente necesitan y tener un plazo de validez determinado para que el impacto de una credencial se reduzca a cero según un cronograma, en lugar de permanecer indefinidamente. Una clave que puede hacer cualquier cosa indefinidamente es el artefacto más común que se encuentra entre los restos de una revisión de incidentes.

Asimismo, el registro de auditoría debe respetar la confidencialidad de los datos que registra. Aplicamos un proceso de anonimización por llamada para que el registro capture lo sucedido (qué herramienta, bajo qué identidad y contexto de inquilino, y con qué resultado) sin convertirse en una copia secundaria de los datos confidenciales que los controles están diseñados para proteger. Un registro de auditoría que acumula silenciosamente registros de clientes en texto plano no es un control; es un nuevo riesgo con un nombre más amigable.

En conjunto, estas propiedades (claves con ámbito, límites de tiempo, anonimización por llamada, auditoría uniforme) permiten a un CISO responder a las preguntas que realmente se plantean tras un incidente: ¿qué podía hacer esta credencial?, ¿durante cuánto tiempo podía hacerlo?, ¿qué hizo realmente?, ¿podemos demostrarlo sin filtrar más información durante el proceso de demostración?

Vincularlo al riesgo continuo y ser honestos sobre lo que queda

Nada de esto requiere una configuración única. El Marco de Gestión de Riesgos de IA del NIST (AI RMF 1.0) establece claramente que la gestión de riesgos de IA es un proceso continuo, no una lista de verificación que se completa y se archiva. Una plataforma de gobernanza es valiosa precisamente porque proporciona a ese proceso continuo un único lugar para actuar: cuando surge un nuevo riesgo, se ajustan la autorización, los presupuestos, la exposición o la auditoría en una sola interfaz, en lugar de tener que gestionar el cambio a través de múltiples integraciones. La estandarización es lo que hace que la gobernanza continua sea viable en lugar de una aspiración. También es la razón por la que una decisión bien pensada sobre la exposición resulta doblemente rentable: una vez al tomarla y otra cada vez que haya que revisarla.

Sea honesto sobre el riesgo residual, porque su junta directiva lo será. Una superficie de gobernanza reduce la superficie de ataque y permite auditar la actividad; no hace que los agentes sean infalibles. La inyección inmediata aún puede intentar dirigir a un agente legítimamente autorizado hacia un uso indebido que parezca legítimo. Una herramienta expuesta deliberadamente aún puede usarse indebidamente dentro de sus permisos. Los presupuestos limitan los costos, pero no el criterio. El estudio de Deloitte "Estado de la IA en la empresa" ha demostrado repetidamente la brecha entre la ambición de la IA y la madurez operativa para gobernarla, y es precisamente en esa brecha donde residen estos riesgos residuales. La respuesta correcta no es afirmar que la brecha está cerrada, sino reducirla, hacerla observable y gestionarla continuamente.

Nuestra plataforma se basa en esta convicción. SocialHub.AI expone herramientas de la capa semántica sobre MCP mediante transporte HTTP en tiempo real, accesible desde agentes como Claude, GitHub Copilot y Microsoft 365 Copilot. Los controles descritos aquí se aplican en la interfaz en lugar de estar dispersos en conectores: autorización de tres ejes con nivel según el contexto del inquilino, escrituras con tolerancia a fallos, un registro de presupuesto por ejecución/por día/30 días con un interruptor de apagado previo a la ejecución y claves de agente con ámbito y límite de tiempo, con censura y auditoría por llamada. Se trata de la misma disciplina de gobernanza que sustenta el programa de fidelización, donde contribuimos a aumentar la contribución del GMV de los miembros de McDonald's China de aproximadamente un 5 % a un 85 %. Los resultados a esta escala solo se mantienen cuando la interfaz de datos es fiable por diseño.

Si está decidiendo cómo los agentes interactuarán con sus sistemas de registro, la pregunta que debe plantear a su equipo no es «qué conector», sino «dónde se deciden la identidad, la autorización, el registro y el coste, y si se trata de un único lugar o de varios». Si desea ver cómo funciona en la práctica una interfaz MCP centrada en la gobernanza, solicite una demostración o lea más sobre nuestro enfoque en /platform/ai-frontier.