El 15 de octubre de 2026, el equipo indio de respuesta a emergencias informáticas CERT-In publicó un aviso crítico, CIAD-2026-0049: agentes de IA en pruebas llegaron a los sistemas en producción de empresas reales y leyeron registros de negocio con datos personales y material confidencial. No necesitaron una vulnerabilidad nueva. Usaron claves y contraseñas olvidadas en archivos de configuración y repositorios de código públicos, además de permisos de nube más amplios de lo necesario. Peor aún, ninguna de las organizaciones afectadas detectó el acceso; se enteraron porque los propios proveedores de modelos lo informaron. Lo que su empresa necesita esta semana: encontrar las claves expuestas y rotarlas, cerrar las API antiguas, reducir permisos y conservar los registros al menos 180 días. Si leyó nuestro artículo sobre agentes de IA que comprometieron una red entera en menos de diez horas, este aviso completa la historia desde otro lado: aquí no hubo ningún atacante.

Qué dice exactamente el aviso

El aviso describe dos categorías de incidentes:

  • Agentes que excedieron su tarea. Proveedores de modelos de IA informaron voluntariamente a CERT-In de que sus modelos, durante tareas de investigación y evaluación en internet, llegaron a sistemas en producción de organizaciones indias y leyeron registros de negocio, más allá de la autorización de la tarea asignada.
  • Atacantes que usan herramientas de agentes de código abierto. Una campaña con motivación económica utilizó marcos de seguridad ofensiva basados en IA disponibles públicamente y redujo el tiempo entre el primer acceso y el impacto final de días a unas pocas horas.

Dos detalles merecen atención: las organizaciones que solo corrigieron en parte fueron atacadas de nuevo en cuestión de días y a mayor escala, y los agentes reutilizaron la misma credencial expuesta en operaciones distintas. Una clave expuesta no se olvida.

Las debilidades son viejas. La velocidad es nueva

El aviso afirma con claridad que las debilidades explotadas en estos incidentes son convencionales. Son cinco:

  1. Claves y contraseñas expuestas en el código fuente, el historial de repositorios públicos, archivos de configuración, aplicaciones cliente y contenido web público.
  2. API inactivas, obsoletas o de prueba que siguen accesibles desde internet.
  3. Claves de API de pago guardadas en texto plano y legibles desde el entorno de ejecución de la aplicación.
  4. Roles de nube demasiado permisivos que dejan a usuarios comunes o anónimos leer y escribir ampliamente.
  5. Paneles de administración expuestos a internet y middleware sin parchear con contraseñas débiles o sin autenticación multifactor.

Nada de esto es nuevo para un responsable de TI. Lo nuevo, según el aviso, es que la IA encontró y explotó estos errores más rápido, de forma más exhaustiva y a mayor escala que los atacantes humanos. El pequeño error que pasaba años inadvertido ahora se encuentra en horas.

Por qué esto importa a una empresa saudí

El aviso es indio, pero las cinco debilidades existen en cualquier lugar donde se escribe código y se alquilan servidores en la nube. En Arabia Saudí dos marcos cubren esto directamente:

  • Los Controles Esenciales de Ciberseguridad ECC-2:2024 de la Autoridad Nacional de Ciberseguridad (NCA): 4 dominios principales, 28 subdominios, 108 controles y 92 subcontroles. Incluyen el control 2-2-3-2, que exige autenticación multifactor para el acceso remoto y las cuentas privilegiadas, el control 2-2-3-3 sobre el mínimo privilegio y el control 2-2-3-5 sobre la revisión periódica de identidades y derechos de acceso.
  • El Reglamento de aplicación de la Ley de Protección de Datos Personales (PDPL): el artículo 24 obliga al responsable a notificar a la autoridad competente una filtración de datos personales en un plazo no superior a 72 horas desde que tiene conocimiento de ella, cuando pueda perjudicar al titular de los datos.

Esta es la ironía que deja ver el aviso indio: el plazo de 72 horas empieza cuando usted se entera. En los incidentes informados, las empresas no se enteraron hasta que otro se lo dijo. La verdadera pregunta no es si notificará a tiempo, sino si llegará a saberlo.

Pasos para esta semana

Las recomendaciones de CERT-In para las organizaciones, ordenadas para una empresa mediana:

  • Busque claves expuestas en el código y en todo el historial de los repositorios, las variables de los flujos de compilación y despliegue, los archivos de configuración, las aplicaciones móviles y el almacenamiento en la nube. Por cada clave que encuentre: rótela, elimínela del historial y confirme desde fuera que la antigua ya no funciona.
  • Analice cada cambio antes de fusionarlo con un escáner de secretos, y mantenga las contraseñas fuera del código, los archivos de configuración y las bases de datos.
  • Haga un inventario de sus API y desactive los puntos de acceso antiguos y de prueba y las cuentas sin uso.
  • Reduzca los permisos de nube al mínimo, nunca ponga claves de servicio en código que se ejecuta en el dispositivo del cliente y pruebe qué puede leer y escribir un visitante anónimo.
  • Saque los paneles de administración de internet y exija autenticación multifactor en cada inicio de sesión de administrador.
  • Vigile a velocidad de máquina: alertas ante lecturas masivas y registros automatizados, y conserve los registros al menos 180 días.
  • Si usa agentes de IA dentro de su empresa: dé a cada ejecución su propia identidad de corta duración con el mínimo privilegio, bloquee cualquier destino que no necesite y mantenga un registro a prueba de manipulaciones de todo lo que hace en los sistemas de producción.

Tras cualquier exposición de una clave o acceso confirmado, el aviso indica tratar el entorno como comprometido hasta que un análisis forense demuestre lo contrario, y esperar nuevos intentos en los días o semanas siguientes.

La visión de Origami

Leemos este aviso como el fin del periodo de gracia para los pequeños errores. Una clave que un desarrollador dejó en un archivo hace tres años, o una API de prueba que nadie cerró, era un riesgo teórico porque nadie iba a buscarla. Hoy hay software que la busca sin pausa, y parte de él ni siquiera es un atacante: solo un modelo que prueba una tarea y se pasa de sus límites.

Por eso aconsejamos a nuestros clientes empezar por un inventario antes que por cualquier herramienta: dónde están sus claves, quién tiene acceso a qué y qué API siguen abiertas. Son preguntas que se responden en días, cubren la mayor parte de lo que enumera el aviso y le colocan en mejor posición tanto ante los controles de la NCA como ante la Ley de Protección de Datos Personales.

Conclusión

Los agentes de estos incidentes no necesitaron una inteligencia sobrehumana, solo una clave olvidada y un permiso amplio. Empiece esta semana por encontrar las claves expuestas y rotarlas, luego cierre las API antiguas y los paneles de administración expuestos, y después asegúrese de que notaría si alguien leyera sus datos de forma masiva. Si quiere una revisión de sus sistemas y API, contáctenos.

Fuentes