Los desarrolladores están creando agentes de IA a un ritmo vertiginoso para automatizar todo, desde la atención al cliente hasta la gestión de la infraestructura. Estos agentes de IA son muy robustos y pueden leer correos electrónicos, consultar bases de datos de producción e incluso desplegar servidores. Si bien las capacidades de estas máquinas de IA han evolucionado, la forma en que las protegemos no lo ha hecho.
La mayoría de los agentes de IA actuales funcionan mediante claves API estáticas con permisos amplios y de larga duración. Esto significa que si un atacante modifica el agente mediante inyección de prompt, podría obtener las claves de administrador. Este modelo de seguridad está obsoleto y viola los principios fundamentales de Zero Trust.
En primer lugar, exploraremos por qué los agentes de IA necesitan identidades distintas y, a continuación, explicaremos cómo implementar el Protocolo de Contexto del Modelo (MCP) para otorgar a los agentes de IA un acceso con privilegios mínimos y garantizar que actúen solo cuando estén autorizados.
El problema del “superusuario”
Durante la última década, nos hemos alejado del uso de contraseñas compartidas para humanos, pero a menudo tratamos a los agentes de IA como superusuarios, otorgándoles secretos predefinidos. Cuando insertamos un token de API estático directamente en las variables de entorno de un agente, creamos una gran superficie de ataque. Este token carece de contexto: el sistema sabe que se utilizó el token de la API, pero no por qué ni quién activó el agente.
Los agentes pueden sufrir alucinaciones o ser manipulados; una vez que esto ocurre, pueden realizar acciones difíciles de rastrear, y puede resultar aún más difícil revocar el acceso sin dañar toda la aplicación. Para solucionar este problema, debemos tratar a los agentes de IA con la misma mentalidad de priorizar la identidad que aplicamos a los empleados humanos.
La pesadilla de la “rotación”
Seamos honestos, nadie rota las claves estáticas con la frecuencia necesaria porque es una pesadilla logística.
Si tenemos un único OKTA_API_TOKEN codificado en tres microservicios diferentes, una canalización CI/CD y un archivo .env local El archivo para pruebas, rotar esa clave no es una tarea de seguridad — es una interrupción del servicio en potencia. Para hacerlo bien, tenemos que generar una nueva clave, encontrar todos los repositorios que usan la clave antigua, volver a desplegar todos los servicios y rezar para no habernos saltado alguna pequeña tarea programada que se esté ejecutando en algún servidor antiguo.
Debido a lo doloroso que resulta este proceso, los equipos lo retrasan. He visto algunas claves de producción que no se han rotado en años porque el desarrollador original que las creó se fue, y nadie quiere ser quien rompa la compilación cambiándolas. Esto crea una enorme ventana de vulnerabilidad: si esa clave se filtra, el atacante tendrá acceso permanente hasta que se realice una rotación de pánico.
La solución: el flujo “en nombre de”
Para garantizar la seguridad de esta nueva ola de automatización, necesitamos pasar de las claves estáticas al intercambio dinámico de tokens (definido en la RFC 8693). En arquitectura de identidad, conocemos esto como el flujo en nombre de (OBO). Aquí, el agente actúa como delegado en lugar de como administrador en modo God. Cuando un usuario le pide al agente que haga algo, el agente se autentica, pero solicita permiso para actuar en nombre de ese usuario específico.
Esto requiere dos componentes clave:
- Un protocolo estándar: necesitamos una forma para que la IA estandarice sus solicitudes; el Protocolo de Contexto del Modelo (MCP) es donde entra en juego esto.
- Verificación de identidad: Necesitamos una forma de intercambiar la sesión del usuario por un token de acceso temporal y con ámbito definido para el agente.
Implementación del Protocolo de Contexto del Modelo (MCP)
Ahora veremos cómo podemos implementar este patrón en la práctica. Para ello, utilizaremos el servidor Okta MCP de código abierto para gestionar la conexión entre nuestro LLM (como Github Copilot o Claude) y su proveedor de identidad (IdP).
Paso 1: eliminar secretos estáticos
Primero, auditaremos el código de nuestro agente. Para ello, identifique las variables de entorno que almacenan secretos de larga duración, por ejemplo, OKTA_API_TOKEN, y elimínelas todas. Utilizar claves estáticas para agentes dinámicos es el equivalente en seguridad a compartir la contraseña de tu cuenta bancaria con un contratista temporal. El objetivo es garantizar que el agente no tenga privilegios cuando esté inactivo.
Paso 2: configurar permisos con alcance
En su proveedor de identidad (IdP) correspondiente, registre este agente como una aplicación independiente. Esto nos permite definir con exactitud qué puede y qué no puede hacer. En lugar de otorgar acceso de lectura/escritura, intente utilizar ámbitos granulares. Por ejemplo, no debería tener permisos explícitos como users.delete. En Okta, esto se gestiona mediante el acceso entre aplicaciones (XAA), que nos permite vincular estos permisos específicos al ID de cliente único del agente.
Paso 3: el intercambio de tokens
Ahora, analizaremos el flujo técnico cuando un usuario le solicita al agente (por ejemplo, "Restablecer mi contraseña"):
- El desencadenante: El usuario envía una solicitud al agente a través de su IDE o interfaz de chat.
- El protocolo de enlace: a continuación, el agente se conecta al servidor MCP utilizando el protocolo estándar.
- El intercambio: el servidor intercepta la solicitud y realiza una afirmación de identidad. Le indica al IdP: "Soy un agente de restablecimiento de contraseña." El usuario X me acaba de autorizar. Deme un token válido por cinco minutos.
- La acción: El proveedor de identidad (IdP) emite un token de corta duración válido únicamente para la tarea específica de restablecimiento de contraseña.
El resultado: agentes preparados para auditorías
Al implementar esta arquitectura, transformamos nuestros registros imprecisos en un rastreo de pila claro.
En lugar de mostrar una acción genérica del sistema, nuestros registros mostrarán:
“El agente de restablecimiento de contraseña accedió a la API de contraseñas en nombre del Usuario X.”
Esta visibilidad detallada permite a los equipos de seguridad realizar revisiones de acceso a los agentes de IA, al igual que lo hacen con los empleados habituales. Si, por algún motivo, un agente de IA comienza a comportarse de forma sospechosa, podemos revocar su política de acceso específica al instante sin necesidad de rotar las claves de acceso de todo el equipo de ingeniería.
De claves estáticas a autonomía segura
A medida que los agentes de IA evolucionan y se vuelven más autónomos, no podemos permitirnos el lujo de protegerlos con las mismas claves estáticas antiguas que usábamos para las tareas programadas en 2015.
Una vez que adoptemos el Protocolo de Contexto de Modelo y la aserción de identidad (XAA), podremos contar con agentes de IA que sean útiles, capaces y, lo que es más importante, seguros.
¿Listo para empezar a construir? Echa un vistazo al servidor Okta MCP de código abierto. Esta implementación de referencia proporciona un puente entre su agente de IA y cualquier IdP para permitir un intercambio seguro de tokens en su nombre.
