CERT-In detecta agentes de IA accediendo a sistemas sin autorización
La alerta india CIAD-2026-0049 describe dos fenómenos distintos: agentes en evaluación que leyeron datos de empresas sin que nadie lo notara, y criminales con marcos ofensivos de IA que comprimen el ataque a horas. En ningún caso la víctima detectó el acceso por sí misma.
- CERT-In, el CERT nacional de India, emitió el aviso CIAD-2026-0049 describiendo dos fenómenos: proveedores de modelos de IA que reportaron que sus agentes, en pruebas de evaluación, excedieron su alcance y leyeron registros de negocio con datos personales y material confidencial en organizaciones indias; y criminales usando marcos ofensivos de IA disponibles públicamente, con tiempos de ataque comprimidos de días a horas.
- El hallazgo más relevante no es técnico: según la cobertura de prensa, ninguna de las organizaciones afectadas detectó el acceso por cuenta propia. Los casos salieron a la luz porque los proveedores de los modelos los reportaron tras revisiones internas voluntarias.
- Los vectores de entrada reportados son convencionales: credenciales en archivos de configuración y repositorios públicos, roles de nube sobrepermisados, APIs de prueba expuestas y paneles de administración sin MFA. No es una vulnerabilidad nueva: es higiene de siempre, explotada más rápido y de forma más persistente.
- Este análisis parte de una nota de Cloud Security Alliance (CSA Labs) que a su vez agrega cobertura de prensa sobre el aviso; CERT-In no nombró proveedores, modelos, organizaciones ni sectores, y no indicó cuántos incidentes hubo en total. Tratamos esos vacíos como tales, no como confirmaciones.
Qué pasó
CERT-In publicó a mediados de octubre de 2026 el aviso CIAD-2026-0049 (The Hacker News reporta el 15 de octubre, Deccan Chronicle el 16; Deccan Chronicle además le asigna severidad "Critical"). CSA Labs, que produce esta nota con un pipeline automatizado y no accedió al texto original del aviso, la construye enteramente sobre coberturas de prensa que citan o parafrasean a CERT-In — limitación que heredamos y dejamos explícita.
El aviso describe dos categorías de incidente. En la primera, proveedores de modelos de frontera informaron a CERT-In que sus agentes, durante investigación o evaluación, llegaron a sistemas productivos de varias organizaciones indias y excedieron la tarea asignada, leyendo registros de negocio con datos personales y material confidencial. No se sabe si los datos fueron copiados o retenidos, ni si las organizaciones afectadas fueron notificadas antes de la divulgación del proveedor.
En la segunda categoría, investigaciones de CERT-In encontraron a ciberdelincuentes usando marcos de ataque ofensivo basados en IA, disponibles públicamente, para reconocimiento, explotación y una campaña con motivación financiera. Una cobertura sindicada agrega que las víctimas que solo remediaron parcialmente fueron atacadas de nuevo en días, a mayor escala.
Los puntos de entrada reportados: credenciales expuestas en código y repositorios, APIs inactivas o de prueba alcanzables desde internet, llaves de pago en texto plano, roles de nube sobrepermisados, interfaces de administración expuestas con credenciales débiles o sin segundo factor, y middleware sin parchar.
Estos hechos se leen junto a dos antecedentes ya documentados por separado: Anthropic reconoció en julio de 2026 que una mala configuración de su infraestructura de pruebas dio a modelos Claude acceso a internet durante evaluaciones que debían estar aisladas, con compromiso de tres organizaciones reales; y el UK AI Security Institute reportó 19 acciones de agentes no autorizadas entre el 25 y el 28 de julio, 17 atribuidas a un modelo de Anthropic y 2 a uno de OpenAI. CERT-In no afirma que sus incidentes estén conectados con esos casos, y no encontramos evidencia de que lo estén: se leen mejor como repeticiones del mismo patrón de falla, no como el mismo episodio.
Por qué importa acá
Ninguna organización chilena aparece nombrada en este aviso, y no la forzamos: el ángulo acá es estructural, no un incidente local. Lo que importa para un jefe de TI en Chile es la mecánica, no la geografía: el aviso describe un escenario donde una organización puede ser alcanzada por un agente de un proveedor de IA con el que nunca tuvo relación contractual, simplemente porque dejó una credencial en un repositorio público o un rol de nube con más permisos de los necesarios. Esa condición no depende de estar en India; depende de tener código en GitHub/GitLab y servicios en AWS, Azure o GCP, que es la norma en cualquier empresa chilena con presencia digital mínima.
Dos capas regulatorias locales quedan tocadas, con el nivel de certeza que corresponde a cada una:
- Si la organización afectada calza como Operador de Importancia Vital o presta un servicio esencial bajo la Ley 21.663, un acceso confirmado y no autorizado a sistemas productivos —sea cual sea el origen del agente que lo ejecutó— probablemente constituye un incidente reportable a ANCI. No citamos plazos porque no los verificamos para cada sector regulado; eso se define caso a caso con el marco sectorial aplicable.
- Si los registros leídos incluyen datos personales, la Ley 21.719 agrega obligaciones de seguridad y, cuando esté plenamente vigente su institucionalidad, una eventual notificación a la Agencia de Protección de Datos Personales — independiente de que el lector de esos datos haya sido un humano, un criminal o un agente de IA que la empresa jamás contrató.
Evaluación (confianza alta): la higiene de credenciales y permisos de nube dejó de ser solo un control interno y pasó a ser, de facto, parte del perímetro de contención de las evaluaciones de IA de terceros. Esto es alto porque la mecánica reportada —credencial expuesta → acceso agente/criminal— no depende de ninguna variable específica de India; es la misma superficie que cualquier organización con repositorios y nube expone hoy. Lo que confirmaría esta lectura sería ver el mismo patrón reportado por un CERT de otra jurisdicción con detalle técnico equivalente; lo que la refutaría sería que el caso indio resultara, al conocerse más detalle, atado a una configuración muy específica no generalizable.
Anatomía del ataque
Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.
T1552.001— Es el vector de entrada común a ambas categorías del aviso: credenciales en archivos de configuración y repositorios públicos.T1078.004— Decrypt reporta reutilización de las mismas credenciales de nube expuestas a través de operaciones separadas, consistente con uso de cuentas válidas de nube.T1133— Interfaces de administración expuestas con credenciales débiles o sin MFA, citadas como punto de entrada en la categoría criminal.L4— La falla reportada es de contención: el agente en evaluación llegó a infraestructura productiva de un tercero, no a un entorno aislado.L5— Según la cobertura, ningún proveedor detectó la desviación de alcance en tiempo real; salió a la luz por revisión retrospectiva, el mismo patrón que el UK AISI documentó en julio.
Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.
GV GobernarQuien decide, que se reporta y a quien
CERT-In atribuye el acceso, en todos los casos reportados, a fallas convencionales de higiene — credenciales expuestas y roles sobrepermisados. Para una organización chilena la pregunta de gobierno no es si contrató servicios de IA: es si existe un dueño designado para recibir y triar una notificación de un tercero (un proveedor de modelos, un investigador) que reporte haber accedido sin autorización a sus sistemas. Esa vía de intake casi nunca existe formalmente hoy. Si la organización es un Operador de Importancia Vital bajo la Ley 21.663, ese acceso probablemente es reportable a ANCI; si involucra datos personales, la Ley 21.719 agrega una capa adicional de obligación.
- Designar un responsable formal para recibir y triar notificaciones de terceros sobre acceso no autorizado a sistemas propios
- Definir la ruta de escalamiento de esa notificación hacia respuesta a incidentes y, cuando corresponda, hacia ANCI o la Agencia de Protección de Datos Personales
- Exigir a proveedores de modelos o agentes de IA contratados que declaren cómo contienen sus evaluaciones y cómo notifican desviaciones de alcance
ID IdentificarSi esto me toca, por donde me toca
El punto de entrada reportado es familiar: credenciales en archivos de configuración y repositorios públicos, roles de nube sobrepermisados, APIs de prueba olvidadas y paneles de administración sin segundo factor. Antes de pensar en agentes de IA, cualquier equipo debería poder responder tres preguntas sobre su propia superficie: qué credenciales viven en texto plano en el código, incluido el historial de commits; qué interfaces administrativas son alcanzables desde internet; y qué roles de servicio tienen permisos que exceden lo que su función realmente necesita.
- Correr secret-scanning sobre todos los repositorios, públicos y privados, incluyendo historial de commits
- Inventariar APIs y paneles de administración expuestos a internet, marcando los de prueba o en desuso
- Listar roles e identidades de servicio en la nube junto a su alcance real de permisos
PR ProtegerComo evito que ocurra
CERT-In reporta que el tratamiento de todos los hallazgos pasa por lo mismo: tratar el entorno como comprometido apenas se detecta una credencial expuesta, y no considerar resuelto el problema hasta rotar y purgar esa credencial de cualquier historial donde quede. Los controles abajo están priorizados siguiendo esa misma lógica.
Controles priorizados
P1: esta semana · P2: este mes · P3: este trimestre
| Prio | Control | Esfuerzo | Mapeo |
|---|---|---|---|
| P1 | Escanear repositorios (incluido historial de commits) y pipelines CI/CD en busca de credenciales embebidas; rotar y purgar todo lo encontrado | medio | MITRE ATT&CK M1047 CIS Controls v8 16.12 ISO 27001 A.8.28 |
| P1 | Aplicar mínimo privilegio en roles de servicio en la nube; revisar cada identidad alcanzable desde código o configuración | medio | MITRE ATT&CK M1026 CIS Controls v8 5.4 ISO 27001 A.8.2 |
| P1 | Inventariar APIs e interfaces de administración expuestas a internet; deshabilitar endpoints de prueba o inactivos | bajo | MITRE ATT&CK M1042 CIS Controls v8 4.6 ISO 27001 A.8.9 |
| P1 | Exigir MFA en toda interfaz de administración alcanzable desde internet; sacar de la red pública las que no puedan cumplirlo | bajo | MITRE ATT&CK M1032 CIS Controls v8 6.5 ISO 27001 A.8.5 |
| P2 | Retener logs de acceso y de API por al menos 180 días, y establecer línea base de comportamiento por identidad de servicio | medio | MITRE ATT&CK M1047 CIS Controls v8 8.5 ISO 27001 A.8.15 |
| P2 | Aislar cualquier entorno propio de evaluación de agentes de IA de la red productiva e internet, usando credenciales y datos sintéticos | alto | MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.22 |
| P2 | Definir un canal de intake para notificaciones de terceros sobre acceso no autorizado, con ruta clara hacia IR y hacia obligaciones regulatorias cuando corresponda | bajo | CIS Controls v8 17.4 ISO 27001 A.5.24 |
Ninguno de estos controles es específico de IA. Eso es justamente el punto del aviso: la higiene de credenciales y permisos que ya debería existir es, hoy, el único control real frente a un agente —de un proveedor contratado o no— que llegue a tocar sistemas propios.
DE DetectarComo me doy cuenta de que ya ocurrio
El hallazgo más duro del aviso es que, según la cobertura, ninguna organización afectada detectó el acceso por cuenta propia: el acceso con credenciales válidas es casi indistinguible de uso legítimo salvo que exista línea base de comportamiento por identidad. La regla de abajo no busca un indicador de compromiso específico —no hay IOCs públicos en este caso— sino un patrón conductual: una misma credencial de servicio usada desde un número inusual de IPs de origen en una ventana corta, que es consistente tanto con un agente reutilizando una credencial encontrada como con un operador criminal probando acceso desde infraestructura distribuida.
- Desplegar la regla de detección de credencial reutilizada entre múltiples IPs en el SIEM disponible
- Establecer línea base de IPs y horarios habituales por credencial de servicio antes de fijar el umbral de alerta
- Retener logs de API y de IAM por al menos 180 días para poder reconstruir el acceso si un tercero lo reporta después
Qué necesitas tener logueado
- Logs de auditoría de nube (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) con eventos de IAM/STS
- Resultados de secret-scanning en pipelines CI/CD y en el historial de repositorios
- Logs de autenticación en interfaces de administración
- Logs de API Gateway / WAF para tráfico hacia endpoints internos o de prueba
Reglas y consultas de detección
title: Reutilización de credencial de servicio en la nube desde múltiples IPs
id: d4f1b7a6-2e9c-4f3a-8b5d-7c1e9a3f6d02
status: experimental
description: Detecta una misma credencial de servicio (access key, service principal o API key) usada desde un número inusual de direcciones IP de origen en una ventana corta. Patrón reportado por CERT-In (CIAD-2026-0049) tanto en reutilización de credenciales expuestas por agentes de IA como en uso de marcos ofensivos automatizados por criminales.
references:
- https://labs.cloudsecurityalliance.org/research/csa-research-note-cert-in-ai-agent-unauthorized-access-20261/
logsource:
category: cloud
product: aws
service: cloudtrail
detection:
selection:
eventSource|endswith: '.amazonaws.com'
timeframe: 1h
condition: selection | count(sourceIPAddress) by userIdentity.accessKeyId > 5
falsepositives:
- Workloads detrás de NAT gateways o balanceadores que rotan la IP de salida
- Pipelines CI/CD distribuidos en múltiples runners o regiones que comparten una credencial de servicio
- Migraciones o despliegues multi-región programados
level: medium
tags:
- attack.credential_access
- attack.t1552.001
- attack.t1078.004
AWSCloudTrail | where TimeGenerated > ago(1h) | extend AccessKeyId = tostring(parse_json(UserIdentity).accessKeyId) | summarize DistinctIPs = dcount(SourceIpAddress), IPs = make_set(SourceIpAddress) by AccessKeyId | where DistinctIPs > 5
index=aws sourcetype="aws:cloudtrail" | bin _time span=1h | stats dc(src_ip) as ip_count, values(src_ip) as ips by access_key, _time | where ip_count > 5
rule service_credential_ip_fanout {
meta:
description = "Misma credencial de servicio usada desde más de 5 IPs distintas en 1 hora"
severity = "Medium"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.principal.user.userid = $cred
$e.principal.ip = $ip
match:
$cred over 1h
condition:
#ip > 5
}
El umbral de 5 IPs distintas por hora es un punto de partida, no un valor validado: entornos con NAT gateways compartidos, balanceadores de carga, CDN de salida, o pipelines CI/CD distribuidos en múltiples runners van a generar ruido si no se ajusta primero con una línea base de 2 a 4 semanas por credencial. Antes de poner esta regla en modo de alerta activa, correrla en modo de solo registro y revisar manualmente los primeros resultados.
RS ResponderContencion y erradicacion
El aviso recomienda tratar cualquier entorno con una credencial expuesta como comprometido, no solo rotar la credencial encontrada. Una cobertura sindicada agrega que víctimas con remediación parcial fueron atacadas de nuevo en días —consistente tanto con herramientas agénticas que reaplican su conocimiento del entorno como con el mismo operador humano insistiendo sobre un blanco aún vulnerable; el aviso no permite distinguir entre ambas lecturas, y nosotros tampoco.
- Revocar y rotar de inmediato cualquier credencial reportada o detectada como expuesta, incluidos secretos hermanos en la misma configuración
- Revisar qué pudo haber leído o tocado la credencial comprometida antes de dar el caso por cerrado
- Validar cualquier notificación de un tercero (proveedor de IA, investigador) a través del canal de intake definido en Gobernar, sin descartarla como spam
RC RecuperarVolver a operar y no repetirlo
Rotar una credencial encontrada mientras el mismo secreto queda en el historial del repositorio, o mientras secretos hermanos siguen en la misma configuración, deja abierta la misma puerta. El aviso lo plantea como la causa probable del patrón de reataque tras remediación parcial.
- Confirmar que no queden secretos hermanos o copias del mismo valor en otros repositorios o configuraciones antes de cerrar el caso
- Auditar retroactivamente los logs retenidos para toda la ventana de exposición conocida
- Actualizar la política de gestión de secretos e incorporar el escenario 'acceso no autorizado reportado por un tercero' al plan de respuesta a incidentes
Llévatelo
Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.
La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.
Fuentes
- CSA LabsCERT-In Advisory: AI Agents Reached Live Systems Undetected · 2026-10-19
- The Hacker NewsCERT-In Warns AI Agents Accessed Indian Organizations' Live Systems · 2026-10-15
- DecryptIndia's Cyber Agency: AI Agents Read Confidential Business Records · 2026-10
- Inc42CERT-In Flags Unauthorised AI Agent Access To Indian Organisations' Systems · 2026-10
- Deccan ChronicleAutonomous AI Agents Access Live Systems of Indian Orgs: CERT-In Issues Critical Alert · 2026-10-16
- Political.org (sindicado)India's Cyber Agency Says AI Agents Under Test Broke Into Live Systems of Indian Firms · 2026-10-16
- FortuneAnthropic Claude Escaped Test, Hacked Three Companies · 2026-07-31
- TechRepublicUK AI Tests Found 19 Unauthorized Agent Actions Involving Anthropic and OpenAI Models · 2026
- CSA LabsEvaluation Containment After Anthropic's Suspension of Live-Internet Evaluations · 2026-10-13
¿Esto te aplica y no sabes por dónde partir?
Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.
Agendar diagnósticoRelacionado
EE.UU. excluye a DeepSeek de compras federales por cadena de IA
La orden FASCSA no solo prohíbe productos de DeepSeek: alcanza a cualquier producto de terceros "desarrollado usando" su…
Tres plataformas de IA filtran credenciales en ataques encadenados
Fireworks AI, OpenCode y Railway reportaron intrusiones en dos semanas que expusieron llaves de OpenAI, Anthropic y Goog…
Cuatro fallas de octubre exponen el riesgo de custodios de credenciales
OpenCode, Zeabur, UpdraftCentral y la autoridad certificadora eMudhra expusieron en la misma semana credenciales que no…