Gobernar agentes con MCP: identidad, permisos y registro

Hasta hace poco, conectar un agente de IA a un sistema exigía una integración a medida para cada combinación de modelo y herramienta. El Model Context Protocol (MCP) define una forma estándar para que una aplicación de IA descubra herramientas, conozca sus parámetros y las invoque. Así, una misma herramienta (consultar un ticket, leer métricas, abrir un cambio) sirve a varios agentes sin reescribirla.

También obliga a ordenar el gobierno. Cuanto más fácil es conectar herramientas, más fácil es que un agente termine con acceso a sistemas que nadie revisó. MCP resuelve el "cómo se conecta"; el "quién puede usar qué, en nombre de quién y con qué evidencia" sigue siendo responsabilidad de la organización. Aquí proponemos los controles mínimos para llevar agentes con MCP a producción.

Qué resuelve MCP y qué deja a tu cargo

La especificación de MCP (revisión 2025-06-18) distingue tres piezas: el host, que es la aplicación de IA; el cliente, que es el conector dentro del host; y el servidor, que expone herramientas, recursos y plantillas de instrucciones. Los mensajes viajan en formato JSON-RPC, por transporte local (stdio) o por HTTP.

La especificación es explícita sobre seguridad en varios puntos útiles para el gobierno:

• Recomienda que siempre haya una persona en el circuito con capacidad de rechazar invocaciones de herramientas, y que el cliente pida confirmación en operaciones sensibles.
• Exige que los servidores validen las entradas, apliquen controles de acceso y limiten la frecuencia de invocaciones.
• Recomienda que los clientes registren el uso de herramientas con fines de auditoría.
• Advierte que las anotaciones que describen el comportamiento de una herramienta (por ejemplo, si es de solo lectura) deben tratarse como no confiables, salvo que vengan de un servidor confiable.

El protocolo, sin embargo, no puede hacer cumplir esos principios por sí mismo; la propia especificación delega en quienes implementan los flujos de consentimiento, los controles de acceso y la protección de datos. Por eso recomendamos no conectar los agentes directamente a cualquier servidor, sino a través de un punto de control (un gateway o proxy de MCP, o la capa equivalente de tu plataforma) donde se resuelven identidad, política y registro de forma centralizada.

Identidad: en nombre de quién actúa el agente

La primera pregunta de gobierno: cuando el agente llama a una herramienta, ¿quién está actuando? Hay dos modelos, y conviene elegir uno de forma consciente para cada caso de uso.

• Delegación de un usuario. El agente actúa en nombre de una persona concreta y con, como máximo, los permisos de esa persona. Es el modelo natural para asistentes que trabajan junto a un analista.
• Identidad propia del agente. El agente actúa como una cuenta de servicio dedicada, con permisos definidos para su función. Es el modelo habitual para agentes que operan sin una persona al frente, como un agente de monitoreo o de triaje.

En ambos casos, el registro guarda las dos identidades cuando existan: la del agente y la del usuario que originó la tarea. Sin eso, una auditoría no distingue lo que decidió una persona de lo que decidió el modelo.

Para transportes HTTP, la especificación de autorización de MCP se basa en el borrador de OAuth 2.1 y en estándares relacionados. Los puntos que más importan para el gobierno son estos:

• La autorización es opcional en el protocolo. Sobre HTTP se recomienda seguir la especificación; en transporte local (stdio), las credenciales se obtienen del entorno. Un servidor sin autorización es una decisión que tu política debe permitir o prohibir de forma expresa.
• El servidor MCP actúa como servidor de recursos de OAuth y debe publicar sus metadatos según el RFC 9728 (OAuth 2.0 Protected Resource Metadata), que indican qué servidor de autorización lo protege. Así la emisión de tokens se conecta con tu proveedor de identidad corporativo.
• El cliente debe indicar para qué servidor pide el token (indicadores de recurso, RFC 8707), y el servidor debe rechazar los tokens que no fueron emitidos para él.
• El servidor no debe reenviar el token que recibió (token passthrough). Si necesita llamar a una API, usa un token distinto, emitido para esa API. La especificación lo prohíbe porque rompe la trazabilidad y permite saltarse controles.
• El cliente debe usar PKCE en el flujo de autorización, y se recomienda emitir tokens de acceso de corta duración.

Traducido a criterio: cada servidor MCP es un recurso protegido con su propia audiencia, y cada salto entre sistemas lleva su propia credencial. Si un servidor acepta "cualquier token válido de la organización", el control de acceso queda en manos del agente.

Permisos: alcance mínimo por herramienta

El OWASP Top 10 for LLM Applications 2025 describe el riesgo de agencia excesiva (Excessive Agency) y lo atribuye a tres causas: funcionalidad excesiva, permisos excesivos y autonomía excesiva. MCP facilita las tres si no se gobierna, porque un servidor suele exponer muchas herramientas y es tentador conectar el servidor completo.

Las mitigaciones de OWASP se trasladan bien a MCP: exponer solo las herramientas necesarias, preferir herramientas granulares a herramientas abiertas (una que "ejecuta cualquier comando"), conceder permisos mínimos en los sistemas de destino y hacer cumplir la autorización en esos sistemas, no en el criterio del modelo.

Por eso la unidad de gobierno no es el servidor MCP, sino la herramienta. Estos son los controles que recomendamos definir para cada una antes de habilitarla.

Control	Qué definir	Ejemplo ilustrativo
Dueño	Área responsable de la herramienta y del sistema que toca	Equipo de plataforma para "reiniciar_pod"
Tipo de efecto	Solo lectura, escritura reversible o escritura irreversible	"consultar_incidente": solo lectura
Identidad	Delegada del usuario o cuenta propia del agente	Agente de triaje con cuenta de servicio dedicada
Alcance	Permisos y recursos concretos en el sistema de destino	Solo el grupo de recursos de un servicio
Aprobación	Cuándo exige confirmación humana y de quién	Cambios en producción: aprobación del responsable de turno
Límites	Frecuencia, volumen y horario permitidos	Máximo de invocaciones por hora fijado por el dueño
Datos	Qué datos puede devolver al modelo y cuáles se enmascaran	Sin datos personales de clientes en la respuesta
Registro	Qué campos se guardan y dónde	Parámetros, resultado y ticket asociado

Las anotaciones de MCP que declaran si una herramienta es de solo lectura o destructiva son descriptivas, no un control. El tipo de efecto lo determina tu revisión, y lo hacen cumplir los permisos del sistema de destino.

Consentimiento y aprobación humana

La especificación de MCP establece que el usuario debe consentir y entender el acceso a datos y las operaciones, y que el host debe obtener consentimiento explícito antes de invocar herramientas. En un asistente de escritorio eso es una ventana de confirmación; en un agente de operaciones en segundo plano, hay que diseñarlo.

Recomendamos ligar la aprobación al nivel de autonomía de cada caso de uso: las herramientas de solo lectura se autorizan al habilitarlas; las de escritura reversible pueden requerir aprobación por ejecución hasta acumular historial; las irreversibles requieren siempre aprobación de una persona autorizada, distinta de quien originó la tarea, registrada junto con la llamada. Lo desarrollamos en barreras de seguridad para agentes de IA.

Merece atención especial el servidor MCP que actúa como intermediario hacia una API de terceros. La especificación describe el problema del "adjunto confundido" (confused deputy): si el servidor usa un identificador de cliente fijo ante el tercero, un atacante puede obtener acceso sin consentimiento real del usuario. Por eso exige obtener el consentimiento del usuario para cada cliente registrado dinámicamente antes de reenviar la solicitud al tercero.

Registro y auditoría de cada llamada

Un agente que usa diez herramientas en una tarea produce diez acciones que alguien podría tener que explicar ante una auditoría. Para reconstruir la cadena, recomendamos guardar en cada llamada:

• Identidad del agente, identidad del usuario (si la hay) y sesión o tarea de origen.
• Servidor y herramienta invocados, con su versión.
• Parámetros enviados y resultado devuelto, con los datos sensibles enmascarados según tu política.
• Decisión de política aplicada (permitida, denegada, pendiente de aprobación) y, si hubo aprobación, quién aprobó.
• Identificador de correlación que vincule la llamada con el ticket de incidente o de cambio.

El registro se almacena fuera del alcance de escritura del agente, con la misma retención que el resto de los registros operativos. Con un punto de control único, sale de forma natural; si cada servidor registra por su cuenta, correlacionar se vuelve mucho más difícil. El triaje de incidentes con agentes muestra qué evidencia conviene conservar en cada paso.

Inventario de servidores aprobados y servidores de terceros

Instalar un servidor MCP suele ser trivial, así que el inventario debe ser la condición para conectar, no un trámite posterior. Recomendamos un catálogo de servidores aprobados con dueño, origen (interno, proveedor o comunidad), versión, herramientas habilitadas, sistemas que toca, tipo de autorización y fecha de última revisión. Lo que no está en el catálogo se bloquea en el punto de control.

Los servidores de terceros requieren el mismo tratamiento que cualquier componente de software de un proveedor:

1. Revisión de origen y código. Quién lo publica, cómo se mantiene y qué permisos pide. Un servidor local corre con los privilegios del proceso que lo lanza.
2. Versiones fijadas. Una actualización puede cambiar las herramientas o sus descripciones. Revisa los cambios antes de aceptarlos.
3. Descripciones como entrada no confiable. El modelo las lee; un texto malicioso ahí funciona como inyección de instrucciones.
4. Riesgo de proveedor. Si el servidor procesa datos fuera de tu infraestructura, aplica tu proceso de gestión de terceros.

Todo esto encaja en el trabajo de seguridad sobre la IA que planteamos en el CISO frente a la IA.

Cómo encaja en tu gobierno de IA

Nada de esto requiere un marco nuevo. El NIST AI Risk Management Framework organiza el riesgo de la IA en cuatro funciones: Gobernar, Mapear, Medir y Gestionar. El inventario es parte de Mapear; la política por herramienta y la aprobación humana, de Gobernar y Gestionar; el registro alimenta Medir. Con ISO/IEC 42001, estos controles se documentan en el sistema de gestión de IA, como explicamos en ISO/IEC 42001 en la práctica.

Para empezar, recomendamos tres pasos: inventariar los servidores MCP ya en uso (incluidos los que instalaron equipos por su cuenta), poner un punto de control delante de los que tocan producción y completar la tabla de controles para cada herramienta habilitada. Antes de habilitar herramientas que procesen datos personales o afecten controles regulados, valida la política con Seguridad, Riesgo y Cumplimiento.