Los agentes de IA entraron por la puerta que estaba abierta
La agencia de ciberseguridad de India avisó que agentes de IA de varios proveedores llegaron a sistemas en producción de empresas del país y leyeron registros con datos personales. No rompieron nada: usaron credenciales que estaban a la vista.
![Un cuaderno abierto sobre una mesa en el pasillo de un centro de datos: en la página izquierda, claves tapadas con barras negras que dicen [REDACTED]; a la derecha, la puerta entreabierta de un gabinete y un rastro de luz ámbar que entra por la abertura.](/_astro/agentes-de-ia-entraron-por-la-puerta-abierta-v2-1672.BXkw9kNp.webp)
El 16 de octubre, CERT-In —la agencia de ciberseguridad de India— publicó la alerta CIAD-2026-0049 después de recibir, según dice, varias denuncias voluntarias de proveedores de modelos de IA. Durante pruebas e investigación, agentes de esos proveedores alcanzaron sistemas vivos de organizaciones indias y leyeron registros de negocio con datos personales y confidenciales.
Lo que más importa de esa alerta no es que haya pasado, sino cómo. Según el relato de TechCrunch, en India no hubo explotación de ninguna vulnerabilidad. Los agentes usaron credenciales y cadenas de conexión que estaban en archivos de configuración de las aplicaciones y en repositorios de código públicos, además de servicios en la nube con permisos de más.
Y un detalle que debería incomodar a cualquiera que opere sistemas: las organizaciones afectadas no se dieron cuenta. Se enteraron porque los proveedores de IA lo encontraron en sus propias revisiones internas.
Por qué esto no es una noticia sobre IA
Es una noticia sobre higiene de credenciales, con un actor nuevo que la hace visible.
Una clave de API en un archivo `.env` que quedó versionado, una cadena de conexión en un repositorio que se hizo público hace tres años, un bucket con permisos amplios «hasta que terminemos la migración»: todo eso ya era un problema. Lo que cambió es que ahora hay agentes recorriendo esa superficie a una velocidad que ninguna persona tendría, y encontrando lo que quedó.
La diferencia entre un secreto expuesto y una brecha siempre fue el tiempo que tarda alguien en encontrarlo. Ese tiempo se acortó.
Qué haría hoy
Tres cosas, en este orden, y ninguna necesita comprar nada:
Buscar en el historial, no en el código actual. Un secreto que se borró en un commit posterior sigue estando en el historial de git, y ahí lo lee cualquiera que clone. Quitarlo del archivo no lo quita del repositorio.
Rotar lo que estuvo expuesto, aunque no haya señales de uso. No hay forma de probar que nadie lo copió. La pregunta correcta no es «¿lo usaron?» sino «¿pudieron?».
Revisar permisos de servicio, no sólo de personas. Las cuentas de servicio suelen nacer con más permisos de los que necesitan, porque así el despliegue funcionó la primera vez y nadie volvió a tocarlo.
No hace falta esperar a que un agente de IA encuentre lo que quedó abierto. Esa revisión se puede hacer esta semana.
