Las cuentas de agentes de IA abren una puerta que muchas empresas no vigilan
Las cuentas de los agentes de IA se protegen gobernando como una sola cadena la identidad del agente, las cuentas de servicio, claves API, autorizaciones OAuth, conectores, herramientas y memoria que le permiten actuar. Cada elemento necesita propietario, permisos mínimos, credenciales revocables, registros correlacionados y un mecanismo de desactivación.
Proteger únicamente el acceso al modelo deja una puerta abierta: el agente todavía puede consultar datos, modificar aplicaciones o ejecutar procesos mediante identidades que la empresa quizá no haya inventariado. El control debe seguir la capacidad efectiva de actuar, desde la solicitud inicial hasta el cambio producido en el sistema de destino.
El inventario debe mostrar qué puede hacer cada agente
La unidad de control no es el modelo, sino el flujo completo. La ficha de cada agente debe identificar a sus propietarios técnico y de negocio, finalidad, entorno, herramientas, datos accesibles, credenciales, permisos efectivos, dependencias y procedimiento de retirada.
El diagnóstico de Gartner sobre aplicaciones de IA incluye herramientas públicas y empresariales internas, agentes personalizados e integraciones de terceros; también advierte que los controles débiles pueden exponer datos sensibles o credenciales. Un catálogo limitado a proveedores y modelos no revela esa superficie.
Conviene representar por separado al agente, la identidad con la que se autentica y cada autorización delegada. Dos implementaciones que usan el mismo modelo pueden tener riesgos opuestos si una solo consulta documentación y otra escribe en el CRM, envía correo o despliega código. Una cuenta compartida impide atribuir acciones y obliga a afectar varios procesos cuando llega el momento de revocarla.
La autonomía debe empezar con privilegios mínimos
Los permisos se aplican en la capa que ejecuta la acción, no en el texto del prompt. Hay que limitar roles de nube, ámbitos OAuth, operaciones de cada conector y recursos alcanzables; además, las comprobaciones de autorización deben realizarse antes de cada llamada sensible.
Las identidades no humanas abarcan cuentas de servicio, claves API y tokens OAuth. El análisis de Dark Reading señala que suelen conservar acceso amplio y persistente con menos visibilidad que una cuenta personal, una combinación que favorece el abuso de privilegios y el movimiento entre sistemas.
La separación debe hacerse por agente, función y entorno. Desarrollo no debe reutilizar la identidad de producción, y un agente que redacta una respuesta no necesita la autorización empleada para enviarla. Borrados, transferencias, despliegues y cambios de permisos requieren una regla externa al modelo: bloqueo, aprobación humana o privilegio temporal limitado a la operación.
Claves y OAuth requieren revocación comprobable
Cada credencial necesita custodio, almacenamiento aprobado, consumidores conocidos, caducidad o fecha de revisión y un procedimiento de revocación. Las claves no deben aparecer en prompts, memoria, repositorios ni registros; cuando la plataforma lo permita, las identidades de carga de trabajo y los tokens breves reducen la dependencia de secretos estáticos.
Rotar no consiste solo en emitir otra clave. El procedimiento normal es localizar dependencias, crear la credencial nueva, migrar consumidores, comprobar el servicio y revocar la anterior. Si existe una posible exposición, la prioridad cambia: contener el acceso e invalidar claves, tokens y sesiones antes de recuperar el proceso con una identidad limpia.
OAuth debe auditarse por aplicación, usuario delegado, ámbitos concedidos y acciones habilitadas. El consentimiento para leer un recurso no equivale al permiso para modificarlo, y una autorización de aplicación puede ser más amplia que una delegación ligada al usuario. También hay que detectar conectores retirados que conserven tokens válidos.
Los registros deben reconstruir la acción, no solo la conversación
Guardar el diálogo no demuestra qué ocurrió. Un registro útil conecta al solicitante, la sesión, la identidad del agente, la autorización utilizada, la herramienta, el recurso, la decisión de la política y el resultado mediante un identificador de correlación común.
Los principios de seguridad de Google Cloud exigen responsables humanos definidos, capacidades limitadas y acciones observables; también sitúan las llamadas a herramientas y la memoria entre las áreas que requieren controles específicos. Esta combinación permite distinguir una solicitud rechazada de una operación realmente ejecutada.
Las alertas deben concentrarse en cambios de privilegios, recursos o entornos no previstos, nuevas integraciones, repetición de acciones denegadas y desvíos del patrón autorizado. La memoria también necesita propietario, separación por usuario y entorno, reglas de escritura y retención: una instrucción persistente manipulada puede influir en ejecuciones posteriores.
Matriz control-riesgo para aprobar el despliegue
- Identidad desconocida o compartida: inventario obligatorio, propietario nominal e identidad exclusiva por agente y entorno.
- Acceso excesivo: permisos mínimos por herramienta, ámbitos OAuth acotados, autorización temporal y revisión de permisos efectivos.
- Robo de credenciales: gestor de secretos, tokens breves cuando sea posible, rotación probada y revocación centralizada.
- Acciones no atribuibles: registros correlacionados desde la solicitud hasta el sistema de destino, con identidad, autorización y resultado.
- Propagación entre entornos: separación de redes, cuentas, memoria, conectores y datos entre desarrollo, pruebas y producción.
- Acción autónoma peligrosa: lista de operaciones permitidas, aprobación para las críticas y un mecanismo externo de parada.
La aprobación debe basarse en evidencias, no en la descripción funcional del agente. Si el equipo no puede mostrar quién responde por él, qué permisos acumula, de dónde proceden sus credenciales y cómo se reconstruye una acción, esa autonomía aún no está controlada.
Lista de auditoría y contención
- Enumerar agentes, identidades, cuentas de servicio, claves, tokens OAuth, conectores, herramientas y memorias asociadas.
- Asignar propietario, finalidad, entorno, datos autorizados y fecha de revisión a cada elemento.
- Comparar permisos efectivos con las acciones necesarias y retirar accesos sobrantes o compartidos.
- Comprobar almacenamiento, caducidad, rotación, dependencias y revocación de cada credencial.
- Verificar que los registros enlazan solicitud, identidad, autorización, herramienta, recurso, decisión y resultado.
- Ensayar la desactivación selectiva, la invalidación de sesiones y la conservación de evidencias.
Durante un incidente, el equipo debe poder suspender la identidad afectada sin apagar toda la plataforma. Después de contenerla, corresponde revisar sus accesos anteriores, invalidar credenciales relacionadas, comprobar los cambios ejecutados y restaurar el servicio con permisos corregidos. Así, la cuenta deja de ser una puerta invisible y pasa a ser un activo identificable, limitado y recuperable.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.