Despliega agentes de IA con tokens de vida breve y alcance limitado

Un agente que puede llamar a SSO, leer correo o enviar código ya tiene un problema de credenciales. Su token es la superficie de ataque. NIST y CISA completaron una guía para ayudar a las agencias federales y los proveedores de nube a proteger los tokens de identidad y acceso contra la falsificación, el robo o el uso indebido. Los agentes de IA merecen las mismas protecciones de tokens firmados que los usuarios humanos, pero el acceso de los agentes crea problemas adicionales de gestión de identidad y acceso que requieren más orientación.

Actores extranjeros falsificaron tokens con una clave de firma comercial robada, accedieron a cuentas de correo gubernamentales y una agencia perdió más de 60,000 correos. En mayo, un repositorio de GitHub vinculado a un contratista de CISA expuso credenciales gubernamentales sensibles, a saber, tokens de AWS y tokens de acceso de GitHub; CISA declaró entonces que los datos sensibles no parecían comprometidos. Un token filtrado puede moverse rápido. Un token de vida larga le da tiempo.

Hasta que existan estándares de identidad específicos para agentes, trata a cada agente de IA como una identidad no humana de baja confianza. Otórgale el alcance más restrictivo, la vida más corta y la ruta de revocación más clara. Los controles de tokens de agentes son el conjunto interino.

Convierte la lista de verificación en la puerta de salida

Usa la lista de verificación siguiente como el mínimo exigible para agentes en producción. Cada elemento debe poder verificarse en un minuto. Si falla alguno, el agente no está listo. Ejecútala antes de cada despliegue en producción, no solo después de un incidente.

• Mantén las identidades de agentes en un inventario separado de las cuentas humanas.
• Emite a cada tarea del agente una credencial con alcance delimitado.
• Haz expirar las credenciales al finalizar la tarea.
• Verifica los tokens antes de conceder acceso.
• Protege las claves de firma de tokens y aserciones, y restringe el uso de las claves.
• Excluye los tokens de los registros, las tuberías CI/CD y los artefactos de compilación.
• Pausa las acciones de alto riesgo para aprobación humana.
• Rechaza los tokens revocados.

El inventario va primero porque un agente que no se rastrea no puede revocarse. Un inventario da al equipo de seguridad un lugar donde mirar cuando un token se comporta de forma anómala. También acelera la revocación al finalizar una tarea.

Las credenciales de agentes de vida breve son el segundo control. Una tarea que resume correos no debería mantener un token que pueda borrar correos. Una tarea que abre una pull request no debería mantener un token que pueda fusionar cambios. El alcance debe coincidir con la tarea, y la tarea debe ser breve. Más acceso debería requerir una credencial nueva, no una permanente. Una credencial permanente mantiene la misma exposición una vez terminada la tarea.

La verificación y la protección de claves cierran el círculo. NIST IR 8587 deja las claves API fuera de su alcance de control. La regla de registros requiere pruebas explícitas. Los tokens aceptados sin prueba pueden conceder acceso. Las claves de firma robadas pueden emitir más tokens. Los tokens falsificables hacen irrelevante el resto de la pila. Los tokens registrados ya están expuestos.

Las puertas humanas limitan el radio de impacto

Los tokens de vida breve reducen la exposición, pero no eliminan el juicio. Algunas acciones deberían seguir requerir a un humano. Borrar datos de producción, pagar servicios de nube, cambiar la política de identidad y enviar mensajes externos son candidatos. La puerta debe ser explícita, no un paso de revisión vago. La aprobación debe especificar la acción, el alcance y el límite de tiempo.

Integra la puerta en el flujo de trabajo. El agente propone la acción. Un humano la aprueba. El sistema registra quién aprobó qué y cuándo. Cuando el humano no está disponible, la acción espera. Esperar es más seguro que un fallo rápido con una credencial amplia. Guarda el registro de aprobación junto con el registro de la tarea.

El monitoreo es el último control. Vigila el uso de tokens que no coincida con la tarea: nuevos alcances, nuevos destinos, fallos repetidos o llamadas fuera del horario laboral. Alerta sobre el patrón, no solo sobre un evento aislado. Trata las alertas repetidas como un disparador de revocación, no como una molestia. Luego revoca la credencial y vuelve a ejecutar la tarea con una nueva. Mantén la prueba de revocación en la lista de verificación de salida. Cuando la revocación falla, corrige el modelo de identidad antes de volver a desplegar.