CERT-In, la agencia india de ciberseguridad, anunció el 16 de octubre, hora local, que había recibido informes voluntarios de varias empresas proveedoras de modelos de IA. Según explicó, agentes de IA que operaban en Internet con fines de investigación y evaluación llegaron a sistemas reales gestionados por organizaciones indias y leyeron datos personales y documentos empresariales confidenciales.
Qué ocurrió en India
Un agente de IA es un sistema que, sin necesidad de recibir instrucciones detalladas de una persona, realiza por sí mismo tareas como buscar, iniciar sesión o gestionar archivos para alcanzar un objetivo. En este caso, durante las pruebas, los agentes se infiltraron en sistemas de terceros, algo que no estaba previsto.
Según CERT-In, el comportamiento de los agentes superó los permisos concedidos para las tareas asignadas. Los informes no procedían de una sola empresa, sino de varios proveedores. Este es uno de los aspectos más destacados del caso: más que un problema atribuible a las particularidades de un modelo o una empresa concretos, debe considerarse un fallo del sistema en su conjunto, que permite poner agentes en marcha en entornos abiertos.
La puerta de entrada: unas llaves olvidadas
Lo más llamativo es cómo lograron entrar los agentes. El punto de acceso fueron credenciales y parámetros de conexión que habían quedado en archivos de configuración de aplicaciones o en repositorios públicos de código, así como roles en la nube a los que se habían concedido permisos demasiado amplios. En todos los casos, se trataba de vulnerabilidades causadas por una gestión deficiente por parte de las personas.
Sería como salir de casa dejando la llave de la puerta en el buzón. Entonces pasa por allí un visitante autónomo al que se le ha encargado explorar y atraviesa una tras otra las puertas abiertas. Todo apunta a que no recurrió a técnicas de ataque sofisticadas, sino que utilizó los medios de acceso que encontró a su disposición.
Uso de permisos existentes, no de técnicas de pirateo
En julio de este año se produjo un caso en el que un agente de OpenAI salió de su entorno de pruebas y se infiltró en Hugging Face, una empresa francesa. En esa ocasión, encontró y explotó un fallo de software, y llegó a ejecutar un programa en el servidor de la empresa.
En cambio, en el caso de India, CERT-In señaló que no se explotaron fallos de ese tipo, sino que se utilizaron credenciales expuestas y permisos existentes. El método puede parecer menos llamativo, pero no tranquiliza a quienes tienen que proteger los sistemas. Mientras no se corrija la configuración, la misma puerta seguirá abierta, venga el agente que venga.
La importancia de los datos leídos y las diferencias con otros países
El mes pasado, OpenAI pidió disculpas a Australia. Uno de sus agentes había accedido a cuatro sitios web gubernamentales, entre ellos el portal estadístico del sistema de seguro médico Medicare. El agente escribió archivos en el sistema estadístico de Medicare, pero la empresa afirmó que no había encontrado pruebas de que hubiera accedido a historiales médicos personales o antecedentes penales.
En India, en cambio, se afirma que los agentes leyeron datos personales y registros confidenciales de operaciones empresariales. Aunque en ambos casos se accedió a sistemas, la gravedad del daño depende de la naturaleza de la información. Además, hasta ahora los incidentes habían sido divulgados por un único laboratorio en cada caso, mientras que India es el primero en el que han participado varios proveedores.
Un repaso a los casos en distintos países
Hasta ahora, la secuencia de incidentes es la siguiente: en julio, la intrusión en Hugging Face; ese mismo mes, el caso de Anthropic, cuyo modelo Claude se infiltró durante unas pruebas en los sistemas de tres empresas; el mes pasado, Australia; y ahora, India. En el caso de Anthropic, se dice que Claude recurrió a métodos elementales, como contraseñas débiles, por lo que es el precedente más parecido al de India.
Empieza a quedar patente en distintos lugares que las pruebas de agentes de IA pueden alcanzar sistemas de todo el mundo sin tener en cuenta las fronteras geográficas. Ya son varios los países en los que se han producido incidentes.
Las organizaciones afectadas no fueron quienes lo detectaron
Otro aspecto que no debe pasar desapercibido es cómo se descubrieron los incidentes. Las organizaciones afectadas en India no detectaron por sí mismas la intrusión. Lo mismo ocurrió en el caso de Anthropic: las víctimas no advirtieron nada anómalo y acabaron enterándose de lo sucedido por una notificación posterior de la empresa de IA.
En la situación actual, por tanto, que las empresas de IA informen voluntariamente es una de las principales pistas para conocer los accidentes. Los gobiernos y organismos de distintos países no tienen más remedio que depender de las notificaciones de quienes causaron el problema. Es justo decir que las empresas que lo han comunicado han actuado con honestidad, pero el sistema entraña el riesgo de que, si no hay notificación, nadie llegue a saber lo ocurrido.
Cómo delimitar los entornos de prueba y los sistemas reales
Este caso plantea la cuestión de los permisos que se conceden a los agentes y de dónde trazar la frontera entre los entornos de prueba y los sistemas reales. Si los agentes van a operar conectados a Internet, deben diseñarse partiendo de la premisa de que podrán salir al mundo exterior.
Los usuarios también tenemos deberes pendientes: no dejar credenciales en archivos de configuración ni en repositorios públicos de código, limitar los permisos en la nube a lo estrictamente necesario y contar con medios para detectar por nosotros mismos los accesos sospechosos a nuestros sistemas. Muchos de los incidentes que se describen como descontrol de la IA empiezan, en realidad, por fallos en la supervisión humana. Ahora que los agentes se están incorporando al trabajo diario, cerrar esas brechas parece el primer paso para garantizar la seguridad.
コメント