La ola de la IA agéntica se está acelerando rápidamente. Lo que empezó como chatbots equipados con herramientas sencillas está evolucionando hacia trabajadores digitales autónomos profundamente integrados en los flujos de trabajo de las empresas.
A medida que estos despliegues maduran, se hace cada vez más evidente una brecha crítica en la seguridad.
Muchas arquitecturas de agentes actuales siguen basándose en lo que puede describirse como un modelo de clave de Dios, en el que credenciales amplias y duraderas combinan la identidad del usuario, la autorización y el acceso a las herramientas en un único secreto compartido.
Este enfoque no se escala con seguridad.
Para las empresas que pretenden poner en funcionamiento agentes a escala, es necesario realizar una transición hacia la identidad delegada y los mecanismos de aplicación conscientes de la IA.
A continuación le ofrecemos una visión en profundidad del problema real y de lo que implica una solución a nivel de producción.
1. El verdadero riesgo: credenciales de agente con privilegios excesivos
En muchas de las primeras implantaciones de agentes -como las herramientas de estilo LangChain, los servidores MCP personalizados y las pasarelas de herramientas internas-, la autenticación suele gestionarse mediante credenciales de servicio estáticas:
- claves API de larga duración
- cuentas de servicios compartidos
- amplias credenciales de cliente OAuth
- o identidades de carga de trabajo gruesas
Para aclarar, MCP en sí no requiere claves estáticas. El protocolo admite modelos de identidad delegada y OAuth adecuados. Sin embargo, en las implementaciones del mundo real, muchos agentes siguen utilizando credenciales sobreescaladas y no vinculadas al usuario para hablar con servidores MCP individuales.
Este es el origen del riesgo.
El problema de la identidad compartida (atribución entre usuarios)
Considere un escenario en el que:
- 50 empleados utilizan un único Agente de Marketing
- el agente llama a GitHub utilizando una credencial de servicio
En esta configuración, los registros de GitHub mostrarían simplemente: Agente_Servicio_Cuenta borró repo X.
Lo que falta:
- qué humano inició la acción
- si el usuario estaba autorizado
- si se esperaba la acción
Desde una perspectiva de auditoría y forense, se pierde la atribución. No se trata de un defecto de MCP, sino de una laguna en la propagación de la identidad presente en muchos despliegues de agentes.
El problema de los permisos demasiado amplios (alcance transversal)
Considere un servidor MCP que expone múltiples herramientas:
- leer_archivo
- list_files
- borrar_archivo
Si el agente se autentica con una única credencial de amplio alcance, cualquier inyección puntual exitosa o mal comportamiento del agente podría invocar potencialmente herramientas de mayor riesgo. Aunque MCP permite a los servidores aplicar la autorización por herramienta, muchos servicios MCP actuales se centran principalmente en la funcionalidad de las herramientas y no están diseñados para servir como puntos de aplicación de políticas empresariales completas.
Esto crea una importante brecha arquitectónica.
2. La realidad arquitectónica: Los servidores MCP no son puertas ZTNA
En la mayoría de las empresas, no se espera que las aplicaciones internas implementen por sí mismas una lógica exhaustiva de autenticación, autorización y política de riesgos. En su lugar, esta responsabilidad suele centralizarse en una capa de Acceso a la Red de Confianza Cero (ZTNA) que se sitúa delante de las aplicaciones empresariales.
Los servicios de MCP deben considerarse de la misma manera.
En la práctica, muchos servidores MCP:
- centrarse en la ejecución de herramientas
- confiar en la identidad ascendente
- implementar la autenticación gruesa o a nivel de servicio
- carecen de modelos profundos de políticas de usuario/grupo
- no realice el intercambio de fichas
- no están diseñadas para gestionar decisiones de riesgo rápidas
Esperar que cada servidor MCP actúe como un motor completo de aplicación de la confianza cero no es realista ni escalable.
3. Por qué la ZTNA es el punto de control natural
ZTNA ya desempeña un papel bien establecido en la seguridad empresarial por:
- fronting de aplicaciones internas
- centralizar la autenticación
- aplicación de las políticas de acceso
- proporcionando un único plano de control
- reducir la carga de los equipos de aplicación
La aplicación de este modelo a los servicios MCP ofrece a las organizaciones un enfoque unificado para proteger tanto las aplicaciones tradicionales como el acceso a las herramientas impulsadas por la IA.
Una forma coherente de proteger tanto las aplicaciones tradicionales como el acceso a las herramientas impulsadas por la IA.
Sin embargo, la IA introduce un nuevo requisito para las soluciones de ZTNA.
4. La ZTNA tradicional es ciega al comportamiento de la IA
Las soluciones tradicionales de ZTNA basan sus decisiones en factores como:
- identidad del usuario
- postura del dispositivo
- contexto de red
- identidad de la solicitud
El tráfico de IA agéntica añade nuevas dimensiones de riesgo, como:
- qué herramienta MCP se está invocando
- qué argumentos se pasan
- si la solicitud fue generada por un prompt
- si la acción representa un alto riesgo
- si el usuario está autorizado para esa herramienta específica
Las soluciones ZTNA tradicionales no pueden ver ni aplicar controles en esta capa. Para hacer frente con seguridad a los servicios MCP, la ZTNA debe ser consciente del protocolo MCP y de la IA.
Lo que se necesita no es una sustitución de la ZTNA, sino una evolución de la misma.
MCP-Aware ZTNA: La evolución necesaria
La ZTNA tradicional sigue siendo la puerta de entrada arquitectónica correcta para las aplicaciones empresariales, incluidos los servicios MCP. Centralizar el control de acceso fuera de la aplicación ha demostrado ser escalable, auditable y eficiente desde el punto de vista operativo.
Sin embargo, los flujos de trabajo dirigidos por agentes introducen dos nuevos requisitos para los que la ZTNA clásica no fue diseñada:
identidad delegada a nivel de usuario para la ejecución de herramientas
visibilidad a nivel de protocolo de la actividad de la herramienta MCP
El cumplimiento de estos requisitos no sustituye a la ZTNA, sino que la hace evolucionar.
Una capa ZTNA con conciencia de MCP amplía el modelo tradicional de Confianza Cero en dos dimensiones críticas: la delegación de identidad y la autorización con conciencia de protocolo.
Identidad delegada: Por qué es necesario el intercambio de tokens
Cuando un agente de IA invoca una herramienta MCP, el servicio posterior debe ser capaz de responder a una pregunta fundamental:
¿En nombre de qué humano se realiza esta acción?
Pasar un token de usuario amplio y de larga duración directamente a cada servicio MCP no es seguro ni escalable. Crea una propagación excesiva de la confianza y aumenta el radio de explosión si se hace un uso indebido de un token.
En su lugar, las arquitecturas modernas de Confianza Cero utilizan la identidad delegada.
En este modelo:
- el usuario se autentica con el IdP de la empresa
- el agente propaga la identidad del usuario
- la capa de aplicación de la ZTNA valida al usuario
- la capa de aplicación realiza el intercambio de fichas
- se acuña una credencial de corta duración y alcance limitado para el servicio MCP específico
Este enfoque garantiza que los servicios posteriores reciban sólo la autoridad mínima necesaria para la operación solicitada.
El intercambio delegado de fichas también permite a las empresas:
- aplicar controles de vida útil coherentes
- normalizar las audiencias
- reducir el radio de explosión de los tokens
- y mantener la atribución completa al usuario
Pero la identidad por sí sola no es suficiente.
Por qué es importante conocer el protocolo MCP
Incluso con una identidad perfecta, la ZTNA tradicional sigue careciendo de visibilidad sobre lo que el agente está haciendo realmente.
Desde la perspectiva de la red, el tráfico MCP suele aparecer como HTTPS estándar. Sin conocimiento del protocolo, la capa de aplicación no puede ver:
- qué herramienta MCP se está invocando
- qué argumentos se pasan
- si la acción es de alto riesgo
- si el usuario está autorizado para esa herramienta específica
Este es el punto ciego clave.
Una capa ZTNA consciente de MCP incluye un análisis profundo del protocolo que puede extraer:
- nombre de la herramienta
- argumentos de la herramienta
- contexto de la sesión
- reclamaciones de usuarios
Estas señales permiten políticas de autorización de grano fino y conscientes de la IA que van mucho más allá de las simples decisiones de acceso a las aplicaciones.
Sólo después de que tanto la delegación de identidades como la inspección a nivel de MCP estén en marcha se podrá lograr una verdadera aplicación de mínimos privilegios para los flujos de trabajo de los agentes.
Detalle crítico de implementación: Los agentes deben propagar la identidad del usuario
Para que la identidad delegada funcione de extremo a extremo, el tiempo de ejecución del agente debe propagar activamente la información sobre la identidad del usuario. En muchas implantaciones actuales, el usuario se autentica en el extremo frontal (por ejemplo, utilizando ZTNA y OIDC), pero las llamadas a herramientas descendentes se siguen realizando con credenciales de servicio estáticas. Cuando esto ocurre, se pierde la atribución del usuario y se rompen los controles de mínimo privilegio.
Para habilitar la Confianza Cero consciente de la IA, el agente o el marco del agente debe garantizar que las solicitudes salientes de MCP o de herramientas lleven una credencial verificable y vinculada al usuario hacia la IA>Secure. Esta capacidad no es automática en la mayoría de los marcos de agentes y, por lo general, requiere una configuración explícita y, en algunos casos, pequeños cambios en el código.
Patrón de producción recomendado: Cabezales de doble identidad
En las implantaciones de producción de AI>Secure, las solicitudes suelen incluir dos identidades verificables de forma independiente:
Identidad del agente:
Autorización: Portador
Identidad de usuario:
X-AI-User-Assertion:
Delegado aguas arriba:
Autorización: Portador
Ambas fichas son validadas de forma independiente por AI>Secure antes de que tenga lugar cualquier evaluación de la política.
Qué cambia en el agente (mínimo)
La mayoría de los marcos de agentes sólo requieren cambios menores para soportar este patrón:
- apunte el punto final MCP a AI>Secure
- continuar enviando el JWT de agente existente
- añadir una cabecera de salida que lleve el JWT del usuario
Los marcos modernos como OpenClaw suelen admitir cabeceras de salida personalizadas, lo que hace que esta transición sea sencilla. No se requieren cambios en el protocolo MCP.
Cómo AI>Secure aplica el mínimo privilegio
Cuando una solicitud llega a AI>Secure, se producen los siguientes pasos:
- Se valida la identidad del agente
- Se valida la identidad del usuario
- El tráfico MCP se analiza
- Se evalúa la política de grano fino
- AI>Secure realiza el intercambio de tokens
- Un token delegado de corta duración se envía aguas arriba
Antes de reenviar la solicitud, AI>Secure elimina las credenciales originales y las inyecta:
Autorización: Portador
Esto garantiza que el servidor MCP sólo reciba una identidad con el alcance adecuado.
Con qué debe configurarse AI>Secure
Autenticación ascendente por servidor MCP
Para cada servidor MCP, AI>Secure se configura con el método de autenticación ascendente adecuado, que podría incluir:
- Portador OAuth
- Clave API
- mTLS
- otros métodos admitidos
Políticas de autorización detalladas
Las políticas de AI>Secure son capaces de hacerlas cumplir:
- herramienta permitir/denegar reglas
- inspección de argumentos
- controles de usuario/grupo
- condiciones basadas en el riesgo
Configuración del agente de identidades
El AI>Secure Identity Broker se encarga de las siguientes tareas:
- validación de las fichas de usuario entrantes
- verificar emisor y audiencia
- realizar el intercambio de tokens OAuth
- acuñación de fichas delegadas de corta duración
- tokens de alcance al servicio MCP de destino
- aplicación de los límites de vida útil
- reivindicaciones opcionalmente transformadoras
Con estos mecanismos, los servidores MCP sólo reciben credenciales de mínimo privilegio y no se les exige que implementen ellos mismos una lógica de identidad compleja.
Lo esencial
El reto no es un defecto del protocolo MCP. El problema principal es que muchos despliegues tempranos (o incluso ahora) de agentes se basan en credenciales que tienen demasiados privilegios y carecen de la atribución adecuada. Estas credenciales conceden permisos excesivos y no identifican claramente qué usuario o agente realizó una acción específica. Como resultado, se está pidiendo a los servicios MCP que apliquen controles de seguridad y políticas de acceso para los que nunca fueron diseñados, lo que supone una carga excesiva para sus implementaciones.
Al colocar una capa ZTNA consciente de la IA delante de los servicios MCP, las empresas pueden:
- centralizar el control de acceso
- preservar la atribución al usuario
- aplicar el privilegio mínimo por herramienta
- evitar sobrecargar las implementaciones del servicio MCP
Las organizaciones que adapten su arquitectura de Confianza Cero a la era de la IA estarán mejor posicionadas para escalar de forma segura a los empleados digitales. En la era de los agentes autónomos, la Confianza Cero debe extenderse más allá de quién puede conectarse – a lo que la IA está realmente autorizada a hacer.