Las puertas de enlace MCP no son suficientes: los agentes de IA necesitan identidad, autorización y autenticación

Las puertas de enlace MCP están por todas partes (y eso es bueno)

El Protocolo de Contexto de Modelo (MCP) se ha convertido rápidamente en la forma predeterminada en que los agentes se conectan con el mundo exterior: el protocolo común para conectar un agente a bases de datos, plataformas SaaS, ejecutores de código, sistemas de pago y servicios internos. Si tus agentes hacen algo útil, es casi seguro que lo hacen a través de MCP.

Naturalmente, las puertas de enlace MCP están proliferando. Todos los proveedores de infraestructura, todas las empresas de mallas de servicios y un número creciente de proyectos de código abierto y startups están lanzando soluciones de puertas de enlace MCP. Y aportan un valor real: enrutamiento centralizado, descubrimiento de servicios, gestión de credenciales y control de acceso básico para las conexiones de servidores MCP.

Esto es lo mínimo indispensable. No es la meta en materia de seguridad.

Si su empresa está pasando de los prototipos a la producción de agentes de IA, donde estos llaman a API, ejecutan código, consultan datos confidenciales e interactúan con otros agentes en nombre de su negocio, el enrutamiento y el control de acceso son necesarios, pero ni mucho menos suficientes. Los verdaderos problemas de seguridad son la identidad, la autorización y la autenticación. Y las puertas de enlace MCP no resuelven ninguno de ellos.

Las tres brechas que dejan abiertas las puertas de enlace MCP

Las implementaciones de agentes de IA en la empresa deben responder a tres preguntas antes de poder pasar a producción. Las puertas de enlace MCP dejan las tres sin respuesta.

Laguna 1: Identidad. «¿Quién es este agente?»

Las puertas de enlace MCP se autentican a nivel de conexión. Llega una solicitud con una clave API válida o un token OAuth, la puerta de enlace la compara con una lista y la solicitud pasa. Esto le indica que la credencial es válida. No le dice quién está llamando.

En la práctica, la mayoría de los agentes de IA operan con claves API codificadas o tokens de cuentas de servicio compartidas. Cuando el agente A y el agente B utilizan la misma credencial de servicio para conectarse a un servidor MCP, la puerta de enlace ve a dos solicitantes idénticos. No existe ningún mecanismo para que el agente demuestre criptográficamente su identidad, ni ninguna afirmación respaldada por un certificado que un servicio posterior pueda verificar de forma independiente.

Este es un problema que el mundo de los microservicios resolvió hace años con SPIFFE y mTLS. Cada servicio obtiene una identidad criptográfica verificable. Cuando el Servicio A llama al Servicio B, el servicio receptor sabe exactamente quién está llamando y puede demostrarlo. Los agentes de IA escritos con los marcos actuales no cuentan con nada de esto. Operan en un vacío de identidad, y las puertas de enlace MCP no hacen nada para cambiar eso.

La diferencia en la práctica es abismal. Hoy en día, la mayoría de las llamadas de los agentes llegan a un servidor de herramientas con este aspecto:

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Un token. Posiblemente compartido entre varios agentes. Posiblemente de larga duración. Sin información sobre qué carga de trabajo lo generó, en qué contexto operaba o si se ha rotado desde su última emisión. El servidor de herramientas lo acepta o lo rechaza. Esa es toda la historia de la identidad.

Con la identidad de carga de trabajo basada en SPIFFE, la misma llamada llega con un SVID respaldado por un certificado, una aserción firmada criptográficamente que tiene este aspecto:

spiffe://diagrid.io/ns/payments/fraud-detection-agent

Esa URI no es un secreto. No es necesario que lo sea. Se trata de una afirmación verificable emitida por la plataforma, vinculada a la carga de trabajo específica que se ejecuta en un espacio de nombres concreto dentro de un dominio de confianza específico, que se renueva automáticamente y que puede ser comprobada por cualquier servicio que confíe en ese mismo dominio de confianza. El servidor de la herramienta receptora no se limita a comprobar «¿está esta credencial en mi lista de permitidos?». Verifica: ¿qué carga de trabajo es esta?, ¿dónde se está ejecutando? y ¿es la carga de trabajo la que se supone que debe realizar esta llamada?

El primer modelo protege la credencial. El segundo modelo protege la identidad. Para los agentes de IA que operan de forma autónoma en servicios, bases de datos y sistemas de pago, esa distinción es la diferencia entre el control de acceso y el modelo de confianza cero.

Desde una perspectiva de normalización, el uso de SPIFFE para la identidad de las cargas de trabajo se está debatiendo activamente en el grupo de trabajo WIMSE del IETF y en el grupo de trabajo Identity & Trust de la AAIF.

Para profundizar en la identidad, lea «Identidad del agente: la capa fundamental que aún le falta a la IA».

Brecha 2: Autorización más allá del enrutamiento. «¿Qué se le permite hacer a este agente?»

Consideremos un agente con acceso a un servidor MCP de la base de datos de clientes. La puerta de enlace permite la conexión, el agente tiene una credencial válida y la regla de enrutamiento lo permite. El agente se encuentra en medio del flujo de trabajo cuando el LLM, al interpretar una instrucción ambigua, construye una llamada que elimina registros que coinciden con un filtro amplio. Nada en la puerta de enlace lo detiene. La regla de enrutamiento decía que el agente podía acceder al servidor. No decía nada sobre lo que el agente podía hacer una vez allí.

Esta es la brecha de autorización que dejan abierta las pasarelas MCP. Controlan el acceso: qué usuarios pueden acceder a qué servidores. No controlan el comportamiento: qué acciones se permite realizar a una identidad de agente específica, en qué contextos de flujo de trabajo y bajo qué condiciones. Para el software determinista, esa distinción apenas importa; se puede razonar sobre el gráfico de llamadas por adelantado. Para los agentes de IA, cuyo comportamiento es emergente y no determinista por diseño, es la diferencia entre un modelo de seguridad y la ilusión de uno.

Lo que la producción requiere es una autorización de denegación por defecto a nivel de flujo de trabajo: políticas declarativas que especifiquen exactamente qué identidades de agente pueden invocar qué flujos de trabajo y herramientas, aplicadas en la capa de la plataforma independientemente de lo que decida hacer el LLM. Estas políticas deben residir en la configuración de la infraestructura, ser propiedad de los equipos de la plataforma y de seguridad, estar controladas por versiones y ser auditables. No en el código de la aplicación, donde pueden omitirse, anularse o simplemente olvidarse.

Brecha 3: Prueba. «¿Qué ha hecho este agente? ¿Podemos demostrarlo?»

Las pasarelas MCP generan registros. Los registros son útiles. Los registros no son una prueba.

La infraestructura de registro empresarial ha mejorado significativamente. Las plataformas SIEM modernas pueden hacer que los flujos de registros sean a prueba de manipulaciones, y con las herramientas adecuadas se pueden conseguir pistas de auditoría inmutables. Pero incluso un registro perfectamente conservado responde a la pregunta equivocada. Cuando un equipo de cumplimiento pregunta «¿puedes demostrar que un humano aprobó esta llamada a la herramienta antes de que el agente la ejecutara?», una entrada de registro que dice tool: transfer_funds, status: approved, user: alice no es una respuesta. No proporcionan ninguna garantía criptográfica de que los eventos registrados ocurrieran realmente en la secuencia registrada.

En los sistemas multiagente, este problema se agrava. Cuando el agente C invoca una llamada a una herramienta destructiva, ¿fue autorizada por el agente B, que a su vez fue autorizado por el agente A, que fue activado por un humano? Sin una cadena de custodia firmada que se propague a través de todos los límites de los agentes, no hay forma de reconstruir o verificar la cadena de decisiones.

Una entrada de la cadena firmada no es un registro de log. Es un objeto estructurado y criptográficamente verificable que viaja con el flujo de trabajo. Una entrada simplificada tiene este aspecto:

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "fecha y hora": "2025-04-18T14:23:11Z",
  "resultado": "aprobado",
  "signature": "eyJhbGciOiJFUzI1NiJ9..."
}

Cada entrada está firmada por la identidad que la generó. Cuando la cadena llega a un servidor de herramientas downstream, lleva consigo el historial completo: quién inició el flujo de trabajo, qué pasos de validación se ejecutaron, si hubo aprobación humana y qué agente generó cada entrada. El servidor de herramientas verifica cada firma antes de actuar. Una entrada que no se pueda verificar porque se desconoce la identidad del firmante, la firma no coincide o falta el paso esperado provoca que la llamada sea rechazada antes de su ejecución.

La Ley de IA de la UE, las directrices emergentes de la SEC y los requisitos SOC2 en constante evolución convergen en una expectativa clara: las empresas deben demostrar un control verificable y la responsabilidad sobre sus sistemas de IA.

Lo que las empresas necesitan es un registro a prueba de manipulaciones y firmado criptográficamente de cada paso en cada flujo de trabajo de los agentes, no un registro que alguien revise a posteriori, sino una prueba que los servicios posteriores verifiquen en tiempo real antes de actuar. Un servidor de herramientas debería poder rechazar una llamada de herramienta destructiva a menos que el historial firmado demuestre que un humano la aprobó, que se superó un paso de validación y que el agente que realiza la llamada está autorizado. Las pasarelas MCP no tienen en cuenta este concepto.

Cómo es una infraestructura preparada para la IA

Cerrar estas tres brechas requiere tres capacidades que operen en la capa de la plataforma de IA, por debajo del código del agente o de la aplicación y por encima de la red/computación.

Identidad criptográfica del agente

Cada agente necesita una identidad criptográfica basada en SPIFFE, un certificado emitido y renovado automáticamente por la plataforma. Cuando un agente llama a una herramienta u otro agente, el servicio receptor verifica la identidad a través de mTLS estándar. No se trata de un token en un encabezado. Es una afirmación respaldada por un certificado, arraigada en una cadena de confianza que cualquier participante puede verificar de forma independiente. El mismo enfoque probado en la práctica que protege la comunicación entre microservicios, ampliado a los retos únicos de los agentes autónomos y no deterministas.

Autorización de flujos de trabajo de confianza cero

La identidad sin autorización carece de sentido. Los equipos de plataforma y seguridad necesitan políticas declarativas y compatibles con GitOps que definan qué identidades de agentes pueden invocar qué flujos de trabajo y herramientas. La postura predeterminada debe ser «denegar todo»: se bloquea cualquier cosa que no esté explícitamente permitida. Estas políticas deben ser aplicables en la capa de la plataforma.

Esta es la diferencia entre «este agente puede acceder a este servidor» (lo que hacen las puertas de enlace) y «esta identidad de agente específica puede invocar este flujo de trabajo específico en este objetivo específico, y nada más» (lo que requiere la producción).

Política como código sobre historial firmado

Las reglas generales de identidad a flujo de trabajo son necesarias, pero no suficientes. Las cuestiones de autorización verdaderamente interesantes son contextuales: ¿esta llamada a la herramienta fue precedida por un paso de detección de fraudes? ¿La aprobó un humano en los últimos 30 segundos? ¿El agente que realiza esta llamada es el mismo que recibió la solicitud original del usuario, o se ha secuestrado la cadena?

Estas preguntas no pueden responderse solo a partir de la solicitud. Requieren un razonamiento sobre el historial del flujo de trabajo que condujo a la llamada. Con un historial de ejecución firmado criptográficamente que se propaga a lo largo de cada paso, un motor de políticas al estilo de Open Policy Agent (OPA) que puede evaluar Rego (o cualquier otro lenguaje de políticas) frente a toda la cadena en el momento de la decisión:

allow_tool_call {
    input.history[_].step == "human_approval"
    input.history[_].step == "fraud_check_passed"
    input.history[_].agent == input.calling_agent
}

La política se ejecuta en el receptor, no en el iniciador de la llamada. Los agentes no pueden falsificar el historial porque cada entrada está firmada por la identidad que la generó. Esto convierte el propio historial del flujo de trabajo en una entrada verificable para la autorización, del mismo modo que OPA ya evalúa las reclamaciones JWT y el contexto de la solicitud para las API HTTP, pero ahora ampliado de extremo a extremo a través de cadenas de ejecución con múltiples agentes y múltiples herramientas.

Cadena de custodia criptográfica

Cuando los agentes colaboran más allá de los límites de los servicios, cada paso debe firmarse. Cada servicio firma el historial de ejecución acumulado con su propio certificado de identidad, creando una cadena a prueba de manipulaciones. Una herramienta posterior no se limita a comprobar «¿tiene permiso este solicitante?». Verifica todo el historial: quién inició el flujo de trabajo, qué aprobaciones se produjeron, qué pasos de validación se superaron y si todas las identidades de la cadena están autorizadas.

No se trata de un registro que alguien comprueba más tarde. Es una prueba criptográfica verificada antes de cada llamada a una herramienta. Permite patrones de aplicación que son imposibles solo con el enrutamiento: una herramienta MCP de pagos que se niega a ejecutarse a menos que el historial firmado demuestre que se ha superado un flujo de trabajo de detección de fraudes y que un humano ha aprobado la transacción.

Cómo funciona esto en la práctica

No se trata de requisitos teóricos. Diagrid Catalyst, la plataforma gestionada para ejecutar aplicaciones basadas en Dapr y agentes de IA en producción, ofrece todo esto hoy en día.

MCP como infraestructura. Las conexiones al servidor MCP se declaran como CRD de Kubernetes con detalles de conexión, credenciales y ámbitos de acceso. No hay lógica de conexión codificada en el código de la aplicación. Las credenciales se resuelven a partir de almacenes de secretos en tiempo de ejecución y nunca se exponen al código del agente.

Llamadas duraderas a herramientas MCP. Cada llamada a una herramienta MCP se ejecuta como un flujo de trabajo dentro del sidecar de Dapr. Si un proceso se bloquea en medio de una llamada, la ejecución se reanuda desde el último punto de control. Las llamadas a herramientas de larga duración (migraciones de bases de datos, secuencias de API externas, ejecución de código) sobreviven automáticamente a los fallos de procesos y nodos.

Ganchos de middleware. Antes y después de cada llamada a una herramienta, los ganchos de flujo de trabajo configurables permiten la autorización por herramienta, el registro de auditoría, la limitación de tasa, la validación de entradas y los controles de costes, sin modificar el código del agente. Estos son flujos de trabajo en sí mismos, componibles y desplegables de forma independiente, y es donde se integra OPA o cualquier otro motor de políticas para evaluar el historial firmado antes de que una herramienta se ejecute realmente.

Política de acceso a flujos de trabajo declarativa. Un CRD de Kubernetes que controla qué identidades de aplicaciones pueden iniciar flujos de trabajo y actividades específicos en una aplicación de destino. Utiliza identidades basadas en SPIFFE/mTLS para la verificación del solicitante. Admite patrones glob, reglas por solicitante y políticas de denegación total en todo el espacio de nombres. Cuando existe una política, se deniega todo lo que no esté explícitamente permitido.

Propagación del historial firmado. Los flujos de trabajo optan por enviar su historial de ejecución completo a los flujos de trabajo y actividades secundarios. Cada identidad que interviene en un flujo de trabajo firma el historial acumulado con su certificado de identidad. Los servicios posteriores verifican toda la cadena antes de actuar, y los motores de políticas pueden razonar sobre ella.

Intervención humana con prueba. Los agentes pueden detenerse para obtener la aprobación humana a través de eventos de flujo de trabajo duraderos. Cuando una herramienta posterior recibe el historial firmado, puede verificar criptográficamente que la aprobación se produjo realmente, y no solo que un registro indique que así fue.

Consideremos un agente que procesa una solicitud de reembolso de un cliente por encima de un umbral definido. En lugar de ejecutarse inmediatamente o fallar, el flujo de trabajo se detiene y emite un evento de aprobación:

El agente de reembolsos alcanza el umbral de 10 000 $
        │
        ▼
El flujo de trabajo se suspende — emite una solicitud de aprobación
  — envía un mensaje de Slack al canal de aprobaciones de pagos
  — registros pendientes de aprobación en el historial de firmas
  — establece un tiempo de espera de 30 minutos
        │
   Revisiones humanas en Slack
        │
        ├── Se aprueba → se reanuda el flujo de trabajo
        │             paso de aprobación firmado y añadido al historial
        │
        └── Rechaza / tiempo de espera → el flujo de trabajo se detiene
                              el rechazo se registra en el historial firmado
        │
        ▼
La herramienta de reembolso recibe la llamada
  — verifica que el historial firmado contiene el paso "human_approval"
  — confirma que la marca de tiempo de la aprobación se encuentra dentro del plazo establecido en la política
  — confirma que la identidad del aprobador es un aprobador autorizado
  — se ejecuta solo si se superan todas las comprobaciones

La aprobación no es una entrada de registro añadida a posteriori. Es un paso firmado en el historial de ejecución que el servidor de la herramienta verifica antes de actuar. Si el paso de aprobación está ausente, ha caducado o está firmado por una identidad no reconocida, la llamada a la herramienta se rechaza, no se audita una vez que el daño ya está hecho.

La pregunta que las empresas deberían plantearse

La pregunta no es «¿necesitamos una puerta de enlace MCP?». Probablemente sí, y sin duda debería formar parte de su gestión de conexiones de entrada. MCP es el protocolo, y necesita una infraestructura para gestionar las conexiones a los servidores MCP a gran escala, realizar el enrutamiento y aplicar cierta limitación de velocidad.

La pregunta es: ¿le proporciona su infraestructura MCP identidad, autorización y prueba?

¿Puede su plataforma de IA indicarle exactamente qué agente realizó una llamada, no qué credencial se utilizó, sino qué identidad verificada criptográficamente? ¿Puede aplicar políticas de confianza cero y denegación por defecto sobre lo que cada agente está autorizado a hacer, gestionadas por su equipo de plataforma y aplicadas independientemente de lo que decida el LLM? ¿Puede generar una cadena de custodia firmada y a prueba de manipulaciones que demuestre cada paso del flujo de trabajo de cada agente, verificable en tiempo real por los servicios posteriores antes de que actúen?

Si la respuesta es no, no tienes una capa de seguridad para los agentes de IA. Tienes un enrutador.

Y los routers no son suficientes.

Profundice en Catalyst.

Hable con un experto