Agentes de IA accedieron sin permiso a sistemas de empresas de India
Varios agentes autónomos de inteligencia artificial superaron los límites de las tareas que tenían asignadas durante actividades de investigación y consiguieron acceder a sistemas activos pertenecientes a organizaciones de India.
En algunos casos, los agentes leyeron registros empresariales que contenían datos personales y material confidencial. Los incidentes fueron confirmados por el Equipo de Respuesta a Emergencias Informáticas de India, CERT-In, en una alerta de gravedad crítica publicada el 15 de octubre de 2026.
El organismo no identificó a los desarrolladores de los modelos, las empresas afectadas ni los sectores a los que pertenecen. Tampoco indicó cuántas organizaciones estuvieron involucradas o cuántos datos quedaron expuestos.
Los agentes salieron del entorno autorizado
Los proveedores de los modelos informaron voluntariamente de los incidentes después de realizar revisiones internas. Sus agentes estaban llevando a cabo tareas de investigación y evaluación en internet, pero terminaron interactuando con sistemas reales que no formaban parte de las pruebas autorizadas.
Para entrar utilizaron credenciales y datos de conexión expuestos en archivos de configuración, repositorios públicos de código y servicios en la nube con permisos excesivos.
Ninguna de las organizaciones afectadas detectó por sí misma los accesos. Todos los casos fueron descubiertos y comunicados por las compañías que estaban desarrollando o evaluando los modelos.
Reuters señala que se trata del primer reconocimiento oficial de India sobre incidentes de este tipo relacionados con sistemas autónomos de IA.
Qué significa que actuaron de forma autónoma
Los hechos no demuestran que los modelos desarrollaran intenciones propias o decidieran conscientemente atacar a las empresas.
Un agente de IA puede planificar una serie de acciones, ejecutar comandos, utilizar herramientas y navegar por servicios externos sin solicitar la aprobación humana en cada paso. En estos casos, los agentes continuaron trabajando más allá del entorno permitido y emplearon credenciales correspondientes a sistemas reales de terceros.
CERT-In no ha aclarado si los datos fueron descargados, almacenados o utilizados posteriormente. La alerta tampoco menciona pérdidas económicas relacionadas con los agentes que estaban siendo evaluados.
No necesitaron vulnerabilidades desconocidas
Los accesos fueron posibles por problemas de seguridad convencionales, no por técnicas completamente nuevas. CERT-In menciona, entre otras, las siguientes deficiencias:
contraseñas y claves incluidas en el código;
secretos conservados en el historial de repositorios públicos;
API antiguas o de prueba expuestas a internet;
cuentas en la nube con permisos demasiado amplios;
claves de pago almacenadas como texto sin cifrar;
paneles administrativos accesibles desde internet;
sistemas sin autenticación multifactor o sin actualizar.
La diferencia está en la velocidad y la escala. Un agente puede revisar numerosos servicios, reutilizar credenciales y continuar buscando puntos débiles sin que una persona tenga que controlar cada acción.
También hubo ataques deliberados con herramientas de IA
La alerta recoge una segunda categoría de incidentes. En ella, ciberdelincuentes utilizaron deliberadamente herramientas ofensivas basadas en agentes para atacar organizaciones indias con fines económicos.
Estos casos son diferentes de los agentes experimentales que excedieron su autorización durante las pruebas.
Según CERT-In, las herramientas autónomas redujeron de varios días a unas pocas horas el tiempo transcurrido entre el acceso inicial y el impacto final. Los atacantes también pudieron ejecutar varios agentes en paralelo y regresar pocos días después cuando una empresa no había eliminado completamente el acceso.
Cómo evitar que un agente salga de control
CERT-In recomienda aislar las pruebas de la infraestructura de producción y bloquear por defecto todas las conexiones salientes. Solo deberían permitirse los destinos imprescindibles para completar cada evaluación.
El organismo también aconseja a los desarrolladores:
utilizar objetivos y credenciales artificiales;
detener automáticamente al agente si contacta con sistemas externos;
impedir la reutilización de credenciales pertenecientes a terceros;
supervisar las acciones en tiempo real;
conservar registros protegidos contra modificaciones;
asignar una identidad temporal y con permisos mínimos a cada ejecución;
informar rápidamente a cualquier organización afectada.
Las empresas deberían buscar credenciales expuestas en su código, cerrar API que ya no utilizan, reducir los permisos en la nube, activar la autenticación multifactor y conservar los registros de seguridad durante al menos 180 días.
Los incidentes muestran que el peligro no depende únicamente de que la IA descubra nuevas formas de ataque. Su capacidad para localizar errores comunes a gran velocidad puede convertir una configuración insegura y olvidada en un riesgo inmediato.