Esta entrada se basa en la conversación que Mackenzie mantuvo con Abdel Sghiouar en el podcast «The Secure Disclosure». Escucha el episodio completo o míralo a continuación.
Si le das a un agente libertad total en tu clúster, este puede rastrear un problema a través de todas las capas de la pila más rápido que cualquier ingeniero de guardia. Pero ese mismo alcance hace que merezca la pena secuestrar al agente. Quitarle el acceso de escritura evita que dañe el clúster, pero un agente de solo lectura sigue pudiendo leer todos los secretos que el clúster le muestre, y uno secuestrado puede ser utilizado para filtrarlos.
Abdel Sghiouar lleva 13 años en Google y ahora es asesor sénior de desarrollo en la nube, especializado en Kubernetes y tecnologías nativas de la nube. Considera que el término «inyección de comandos» no refleja todo el alcance de la vulnerabilidad en el caso de los agentes. Él prefiere utilizar el término «envenenamiento de comandos». Mackenzie se reunió con él para hablar sobre la seguridad de los agentes de IA en Kubernetes y sobre qué cambia cuando es un agente quien lleva las riendas.
La respuesta de Abdel es «confiar, pero verificar», aunque admite que la cuestión de la confianza sigue siendo un problema sin resolver.
¿A qué puede acceder un agente de IA en tu clúster?
Una vez que interviene un agente, la primera pregunta es si cuenta con el nivel adecuado de permisos. En Kubernetes, esto se reduce al control de acceso basado en roles (RBAC). Un agente de operaciones suele tener un amplio acceso de lectura, ya que necesita señales de todo el clúster para realizar su trabajo, y ese acceso es precisamente lo que busca un atacante.
Abdel ve dos formas en las que un atacante puede utilizar ese acceso en tu contra. La primera consiste en manipular lo que lee el agente. Los registros de la aplicación son una de las señales que recoge un agente de operaciones, por lo que un atacante que consiga introducir texto en esos registros puede introducir texto en la línea de comandos del agente. «La aplicación recibiría los datos, los escribiría en el disco y, a continuación, el agente los leería».
Por eso Abdel prefiere el término «envenenamiento de la línea de comando». La «inyección de la línea de comando» invita a compararla con la inyección SQL, que se puede resolver con consultas parametrizadas, pero un modelo de lenguaje grande no dispone de una forma equivalente de separar las instrucciones de la entrada. Procesa la línea de comando del sistema, las instrucciones del usuario, el historial de la conversación y cualquier elemento que haya incorporado al contexto en ese mismo momento, por lo que una línea de registro escrita por un atacante puede tener el mismo peso que una instrucción del operador.
El segundo riesgo es lo que el agente puede leer una vez que ha sido manipulado. Si sus permisos abarcan todo lo que el pod puede ver, «puede leer secretos, puede leer variables de entorno», y todo queda expuesto en el momento en que el agente sigue una instrucción errónea. El envenenamiento permite al atacante infiltrarse en el agente, y un acceso de lectura excesivamente amplio determina cuánto se lleva consigo.
Por qué el acceso de solo lectura no es suficiente
La mayoría de los equipos que Abdel ha visto utilizar Kubernetes con agentes los inician en modo de solo lectura. Esto protege el clúster, ya que un agente que solo puede leer no puede eliminar un despliegue ni vaciar un nodo. Y, como señaló Mackenzie, sin acceso de lectura, el agente apenas sirve para nada. Y lo que es más importante, un agente de solo lectura sigue leyendo los secretos y sigue incorporando cualquier código malicioso que haya llegado a los registros.
Mackenzie señaló el mismo patrón fuera del clúster. Aikido Security detectó una inyección de comandos (o «envenenamiento de comandos») en el flujo de trabajo de GitHub que utiliza Google para clasificar los incidencias en su repositorio de la CLI de Gemini, donde una incidencia manipulada podía hacer que el agente revelara las variables de entorno a las que tenía acceso. La corrección de Google impidió que el agente revelara esas variables, lo que cerró esa fuga concreta, pero dejó el sistema expuesto al envenenamiento de comandos en primer lugar.
Según Abdel, los mecanismos de seguridad en los que ya confían los equipos «siguen siendo válidos para los agentes». Lo que cambia es que ahora hay un componente que toma decisiones que no se pueden dar por sentadas. Un modelo de lenguaje puede «alucinar», por lo que «no se puede confiar plenamente en que el razonamiento del agente sea correcto». Su respuesta es «confiar, pero verificar», con un ser humano que supervise lo que hace el agente, aunque reconoce con franqueza que este es «uno de los mayores problemas de cara al futuro» y algo que el sector aún no ha resuelto.
Dónde encaja « Aikido Security »
El « pentesting de IA » de Aikido permite poner a prueba las capacidades de la IA. Introduce datos maliciosos a través de documentos recuperados y resultados de herramientas para comprobar si alguno de ellos anula las instrucciones del agente, y si es posible inducir a un agente afectado a invocar herramientas o acceder a sistemas a los que no debería. También te indica si es posible convencer a tu agente para que trabaje para otra persona.
El resto depende del alcance que pueda tener ese agente si se ha activado. Las comprobaciones de «infraestructura como código» detectan cualquier ClusterRole o rol de gestión de identidades y accesos en la nube que sea demasiado amplio en la solicitud de incorporación de cambios, incluidos los que propone el propio agente, y escaneo de secretos detectan credenciales codificadas de forma fija antes de que acaben en una variable de entorno que el agente pueda leer. escaneo de imágenes de contenedores Cubre las cargas de trabajo en las que confía tu agente, así como la propia imagen del agente, señalando paquetes vulnerables y malware en ambas.
Una vez que el agente está en ejecución, Aikido Cloud comprueba los permisos de los que dispone, que no siempre son los que concedió la solicitud de incorporación de cambios. Señala los enlaces RBAC de Kubernetes que otorgan al agente más acceso del que requiere su tarea, y las comprobaciones de postura detectan cuando la identidad de la carga de trabajo del agente se asigna a un rol en la nube con derechos de administrador. A continuación, el análisis de accesibilidad y de rutas de ataque relaciona estos hallazgos, mostrando cuáles podría encadenar un agente para pasar de su pod a algo relevante, como una base de datos de producción o unas credenciales de administrador de la nube.
{{cta}}
