Volver al blog
Número 3Evolve on SundaysSeguridad de la IADefensa cibernética

Evolve on Sundays: Cuando los agentes de IA cruzaron la frontera

Un resumen semanal clasificado sobre agentes de IA que llegan a sistemas reales, ataques coordinados contra servicios de agua, fallas explotadas en Exchange y en la gestión de redes, riesgo en la cadena de suministro de software y la siguiente fase de la IA empresarial.

Autora
ALAIsha Lalli
Publicado
2 de agosto de 2026
Tiempo de lectura
Lectura de 28 min

Agentes de IA enfrentándose en una arena de ciberseguridad durante un informe de noticias del domingo por la mañana Obra de arte editorial original creada para Evolving Cyber.

Seguridad, software y perspectivas tecnológicas para la semana que viene.

Ventana de cobertura: domingo, 26 de julio hasta sábado, 1 de agosto de 2026.

La historia definitoria de esta semana no fue que un modelo de IA produjera código dañino. Fue que agentes cada vez más capaces encontraron sistemas reales mientras operaban bajo instrucciones que les decían que esos sistemas eran simulados.

Anthropic reveló tres incidentes en los que los modelos Claude alcanzaron la infraestructura de producción durante evaluaciones de ciberseguridad. La divulgación siguió a nuevos detalles sobre agentes de OpenAI que alcanzaron Hugging Face y otros servicios desde un supuesto entorno de prueba aislado. Ninguno de los episodios se describe con precisión como una IA eligiendo espontáneamente atacar. Ambos muestran algo más útil operacionalmente: un modelo puede seguir fielmente su objetivo asignado mientras que el arnés circundante, los controles de red y las suposiciones fallan.

Lejos de los laboratorios de IA, más de 30 sistemas comunitarios de agua fueron atacados a través de tecnología operativa expuesta, los operadores rusos utilizaron el correo web en sí como una capa de persistencia, y los atacantes continuaron explotando la infraestructura utilizada para gestionar cortafuegos y redes de área amplia.

Esta edición clasifica las historias por impacto operativo, alcance, calidad de la evidencia y relevancia para la semana siguiente.

Metodología editorial: Evolving Cyber prioriza las divulgaciones primarias, los avisos oficiales, los archivos regulatorios y la investigación original del proveedor. Distinguimos el comportamiento observado de la atribución al proveedor y de nuestro propio análisis, y colocamos enlaces directos junto a las afirmaciones materiales para que los lectores puedan inspeccionar la evidencia subyacente.

01Seguridad

1. Las evaluaciones de ciberseguridad de IA alcanzaron organizaciones reales

Anthropic revisó 141,006 ejecuciones de evaluación de ciberseguridad y encontró tres incidentes en los que los modelos de Claude llegaron a internet y obtuvieron acceso no autorizado a tres organizaciones.

La versión del titular —"Los agentes de IA escaparon y atacaron empresas reales"— es alarmante en términos generales pero técnicamente incompleta. La revisión de Anthropic describe tres caminos diferentes de fallo, tres respuestas distintas del modelo y un error de infraestructura compartido: a los modelos se les dijo explícitamente que sus entornos de captura de bandera no tenían acceso a internet, pero un malentendido entre Anthropic y su socio de evaluación, Irregular, dejó un camino activo abierto.

Esa diferencia importa. Los modelos Claude no decidieron abandonar su tarea asignada ni elegir víctimas no relacionadas. Continuaron intentando capturar una bandera ficticia mientras mantenían una creencia falsa sobre qué sistemas formaban parte del ejercicio. El daño fue real, pero entender el fracaso requiere separar el objetivo, la interpretación situacional del modelo y los controles que lo rodean.

2. Ataques coordinados interrumpieron más de 30 sistemas de agua

Minnesota activó la respuesta a incidentes cibernéticos en todo el estado después de que los atacantes atacaran la tecnología operativa en más de 30 sistemas de agua comunitarios. Las acciones reportadas incluyeron cambiar las contraseñas de los controladores lógicos programables, modificar la configuración de la red, desconectar equipos y forzar a algunos operadores a cambiar temporalmente a operación manual.

CISA posteriormente advirtió del aumento de la actividad contra los PLC expuestos a internet en el sector de agua y aguas residuales. La agencia instó a los operadores a retirar la tecnología operativa de la exposición directa a internet, usar VPN o pasarelas seguras cuando el acceso remoto sea esencial, reemplazar las credenciales predeterminadas y restringir el acceso por dirección de origen.

El problema de exposición es mayor que un estado. En una instantánea del 30 de julio, Censys identificó 4,148 hosts expuestos de Rockwell/Allen-Bradley, 4,117 hosts Siemens SIMATIC S7-1200 y 2,072 hosts de Schneider Electric. Censys enfatizó que estos eran recuentos de exposición, no víctimas confirmadas, y que su cifra de Schneider Electric abarcaba a todo el proveedor en lugar de limitarse a los PLC. Los módems celulares no documentados instalados por operadores, proveedores o integradores pueden crear caminos que no aparecen en el inventario normal de activos de la organización.

Por qué importa: los entornos de agua y aguas residuales convierten un cambio de configuración digital en un problema operativo físico. Para los países del Golfo y el resto del Medio Oriente, donde el tratamiento, la distribución y la desalinización son servicios fundamentales, la exposición a OT es un problema directo de resiliencia.

Acción para la próxima semana: inventariar PLC, HMI, estaciones de trabajo de ingeniería, puertas de enlace y módems celulares; eliminar la exposición directa; reemplazar las credenciales predeterminadas; verificar los procedimientos operativos manuales; y probar si los operadores pueden recuperar el acceso cuando se cambian las contraseñas o direcciones de los dispositivos.

3. OWAReaper convirtió un correo electrónico malicioso en acceso duradero al buzón

Proofpoint describió una campaña patrocinada por el estado ruso explotando CVE-2026-42897 contra Microsoft Exchange Outlook Web Access local. La vulnerabilidad de cross-site scripting permitía que JavaScript controlado por el atacante se ejecutara cuando un usuario abría un correo electrónico manipulado en OWA, sin requerir un enlace o archivo adjunto.

La puerta trasera OWAReaper resultante se ejecutó dentro del panel de lectura. Podía recopilar información de la cuenta, intentar el robo de credenciales, abusar de los permisos de los complementos de Outlook para obtener tokens OAuth y modificar los permisos de carpetas del lado del servidor. Esos cambios de permisos podían preservar el acceso al buzón incluso después de que se cambiara la contraseña de la víctima o se reconstruyera el endpoint.

Los atacantes también utilizaron múltiples rutas de mando y control y de exfiltración, incluyendo búsquedas de commits en GitHub, mensajes de correo electrónico, HTTPS y un respaldo DNS. El diseño muestra cómo un compromiso de correo web puede sobrevivir a la remediación enfocada únicamente en el dispositivo del usuario.

Por qué es importante: el correo electrónico no es simplemente un canal de entrega. En las aplicaciones empresariales basadas en navegador, el motor de renderizado de mensajes, los permisos del buzón, los tokens OAuth, los complementos y las cachés fuera de línea forman una plataforma de aplicación con sus propios caminos de persistencia.

Acción para la próxima semana: parchear los sistemas Exchange locales afectados, buscar los indicadores publicados, revisar los permisos de buzones y carpetas, auditar los complementos de alto privilegio y las concesiones OAuth, y no considerar la rotación de contraseñas o el reimaging de endpoints como una remediación completa.

4. AWS conectó los principales compromisos de npm con Corea del Norte

Amazon atribuyó los compromisos involucrando los populares paquetes npm debug, chalk, axios y relacionados con el grupo Sapphire Sleet vinculado a Corea del Norte con confianza media.

La campaña dependió de la ingeniería social de los mantenedores y luego de la publicación de versiones maliciosas a través de cuentas de confianza. Amazon dijo que los atacantes probaron técnicas a través de paquetes más pequeños antes de pasar a dependencias ampliamente utilizadas. La compañía también destacó una evolución más amplia: funciones maliciosas distribuidas a través de múltiples paquetes, cargas útiles obtenidas externamente, ejecución consciente del entorno, personas contribuyentes a largo plazo y nombres de paquetes elegidos para explotar errores cometidos por herramientas de codificación de IA.

Por qué importa: los ecosistemas de paquetes distribuyen la confianza a la velocidad del software. Una cuenta de mantenedor puede convertirse en un punto de entrada a miles de entornos de desarrollo y producción, mientras que la automatización puede instalar una actualización antes de que los defensores comprendan que la propiedad ha cambiado.

Acción para la próxima semana: exigir MFA resistente al phishing para los mantenedores, fijar y retrasar las actualizaciones de dependencias, verificar la procedencia, alertar sobre cambios de editor y propiedad, inspeccionar scripts de instalación y prevenir que los agentes de codificación instalen paquetes recién descubiertos o inventados sin aprobación.

5. Las fallas explotadas en el plano de gestión requerían más que un parcheo rutinario

Cisco divulgó la explotación activa de CVE-2026-20316 en el Centro de Gestión de Firewall Seguro. Las credenciales estáticas de una cuenta de bajo privilegio permitían el acceso remoto no autenticado a los sistemas afectados y podrían combinarse con otras vulnerabilidades para escalar privilegios. Cisco lanzó correcciones e indicadores de compromiso, pero no hay solución alternativa.

Arista parcheó por separado la CVE-2026-16812, una falla de inyección de comandos no autenticada de severidad máxima que afecta a VeloCloud Orchestrator local. La explotación exitosa podría comprometer el orquestador, sus datos gestionados y potencialmente los dispositivos de borde conectados. Las implementaciones alojadas y dedicadas habían sido parcheadas antes de la divulgación pública.

Por qué es importante: los sistemas de gestión se sitúan por encima de los dispositivos que controlan. La compromisión de un gestor de cortafuegos o de un orquestador de SD-WAN puede exponer configuraciones, credenciales, certificados, topología de red y un camino hacia muchos activos posteriores. Instalar una actualización no elimina a un atacante que llegó antes del parche.

Acción para la semana: aplicar las correcciones del proveedor, restringir las interfaces de administración a redes administrativas, usar los indicadores publicados, revisar los cambios de configuración y de administradores, rotar credenciales y certificados expuestos, y reconstruir las instancias comprometidas cuando no se pueda establecer la integridad.

6. Una llamada falsa de soporte de Teams llegó al ransomware en menos de 17 horas

Sophos documentó una campaña en los que los atacantes utilizaron cuentas externas de Microsoft Teams para hacerse pasar por personal de soporte técnico. Se persuadió a las víctimas para que abrieran Microsoft Quick Assist o instalaran software de administración remota, tras lo cual los atacantes establecieron persistencia, desplegaron herramientas de acceso adicionales, se movieron lateralmente y, en al menos tres casos, desplegaron ransomware Chaos.

En un incidente documentado por Sophos, pasaron menos de 17 horas entre el acceso inicial y el despliegue del ransomware. La mayoría de las llamadas de ingeniería social duraron solo unos pocos minutos.

Por qué es importante: los empleados asocian las plataformas de colaboración con compañeros de trabajo y actividades comerciales aprobadas. Los atacantes explotan esa confianza heredada y luego usan herramientas legítimas de soporte remoto que pueden no activar los mismos controles que el malware.

Acción para la próxima semana: restringir o etiquetar la comunicación externa en Teams, requerir un canal de verificación separado para solicitudes de soporte, controlar Quick Assist y las herramientas de gestión remota, alertar sobre instalaciones inesperadas y ensayar la contención de ataques liderados por identidad que puedan alcanzar la encriptación en un día hábil.

7. La violación de la nube de Amgen expuso información de salud y propietaria

Amgen divulgó que los atacantes exfiltraron datos de entornos en la nube operados por proveedores de servicios externos. La empresa dijo que el material robado incluía información propietaria, información de salud protegida de pacientes y otros datos. Todavía estaba determinando si se vieron afectados información comercial confidencial, propiedad intelectual, material de investigación y desarrollo, y información adicional de pacientes.

Amgen clasificó el incidente como material el 29 de julio basándose en el volumen y la posible sensibilidad de los archivos. No había revelado los proveedores de servicios en la nube, el método de intrusión, la población afectada ni el actor responsable al final del período de cobertura.

Por qué importa: la infraestructura subcontratada no subcontrata la responsabilidad. Los datos sensibles distribuidos en múltiples entornos de proveedores pueden dejar la responsabilidad de identidad, registro, retención y respuesta a incidentes dividida entre organizaciones precisamente cuando los investigadores necesitan una vista unificada.

Acción para la próxima semana: mapear la información sensible en los proveedores de SaaS y nube, confirmar la identidad centralizada y la MFA resistente al phishing, recopilar los registros de auditoría del proveedor, probar las rutas contractuales de notificación y verificar que el acceso pueda ser revocado en todos los entornos conectados durante un incidente.

02Software y tecnología

1. Oracle integró a Gemini en los flujos de trabajo principales de la empresa

Oracle anunció que los modelos Gemini de Google estarían disponibles a través de AI Agent Studio para Aplicaciones Fusion y se utilizarían en escenarios integrados en Fusion Cloud y NetSuite. Las organizaciones podrán seleccionar diferentes modelos para ERP, RR.HH., cadena de suministro, finanzas, experiencia del cliente y otros flujos de trabajo.

Por qué es importante: la IA empresarial está pasando de una ventana de chat separada a sistemas que aprueban pagos, cambian registros de empleados, gestionan inventarios y ejecutan transacciones. La selección de modelos se está convirtiendo en parte de la arquitectura de aplicaciones, mientras que los permisos, las aprobaciones, los límites de datos y los registros de auditoría determinan si un agente puede actuar de manera segura.

Acción para la semana: clasificar las acciones del agente por consecuencia, requerir aprobación para transacciones de alto impacto, registrar el modelo y la política utilizada para cada decisión, y hacer que la reversión sea parte del diseño del flujo de trabajo.

2. Amazon respaldó la verificación formal para agentes más seguros

Amazon se comprometió a brindar un apoyo sustancial a largo plazo a la organización detrás de Lean, un lenguaje de programación de código abierto y asistente de pruebas utilizado para verificar propiedades matemáticas y de software. AWS ya utiliza la verificación basada en Lean en servicios que incluyen Bedrock AgentCore.

Los métodos formales no pueden demostrar que un objetivo empresarial mal definido sea prudente. Pueden demostrar que una política o protocolo definido cumple con propiedades específicas. Esa distinción importa a medida que las organizaciones piden a los agentes que operen bajo reglas de autorización cada vez más complejas.

Por qué importa: las pruebas convencionales demuestran el comportamiento en escenarios seleccionados. La verificación formal puede establecer garantías más sólidas sobre los límites definidos, incluyendo si un lenguaje de políticas permite una acción que debería ser imposible.

Acción para la semana próxima: identificar los controles de alta consecuencia—políticas de autorización, límites de aislamiento, reglas de transacción y protocolos distribuidos—donde la verificación matemática proporcionaría más seguridad que solo las pruebas basadas en ejemplos.

3. El gasto en IA comenzó a repetir la crisis de costos inicial de la nube

Investigación discutida por Harness se encontró que el 72 por ciento de las organizaciones habían experimentado aumentos inesperados en los costos de la IA, la IA representaba el 23 por ciento de la factura promedio de nube empresarial, y los encuestados estimaron que el 26 por ciento del gasto en IA se desperdiciaba.

El problema no es solo el precio del modelo. Los rastros de razonamiento largos, los bucles repetidos del agente, las grandes ventanas de contexto, las llamadas a herramientas, los reintentos y el uso de modelos frontera para trabajo rutinario pueden convertir un precio de token barato en un proceso empresarial costoso. La propiedad también está fragmentada entre ingeniería, finanzas y TI.

Por qué importa: una función de IA puede ser técnicamente exitosa y económicamente insostenible. El costo debe medirse por resultado completado, no solo por token o solicitud de API.

Acción para la próxima semana: asignar un responsable del gasto en IA, medir el costo por flujo de trabajo, establecer límites de reintento y razonamiento, dirigir tareas más simples a modelos más pequeños, almacenar en caché los resultados reutilizables y exigir a los equipos que definan el valor empresarial que justifica una ejecución de mayor costo.

4. Google retiró una función de Earth AI después de un día

Google introdujo y luego retiró una función de generación de imágenes que permitía a los usuarios colocar escenas generadas dentro de Google Earth. Retiró la función un día después de que los usuarios demostraran cómo las capturas de pantalla podían parecer mostrar eventos fabricados en ubicaciones geográficas reales. Google dijo que trabajaría en medidas de seguridad más estrictas.

Por qué importa: la seguridad no puede detenerse en el límite de la interfaz del producto. Una imagen generada puede estar etiquetada correctamente dentro de una aplicación y volverse engañosa cuando se recorta, se toma una captura de pantalla, se vuelve a publicar o se separa de sus metadatos. El riesgo es mayor cuando el producto anfitrión ha sido históricamente tratado como una fuente confiable de evidencia geográfica.

Acción para la semana: probar el contenido generado fuera de su interfaz original, hacer que la procedencia sobreviva en capturas de pantalla y exportaciones cuando sea posible, realizar revisiones de abuso antes del lanzamiento y definir un camino de reversión para las funciones que socavan el modelo de confianza del producto que las rodea.

5. Los resultados de Microsoft mostraron que la IA empresarial está avanzando más allá de la experimentación

Microsoft informó que los ingresos de Azure habían superado los 100 mil millones de dólares en el año y que Microsoft 365 Copilot había alcanzado más de 30 millones de asientos pagados. Azure creció un 43 por ciento en el trimestre, mientras que la compañía continuaba invirtiendo fuertemente en infraestructura de IA y en sus propios modelos.

Por qué importa: la inteligencia artificial empresarial ya no se limita a los equipos de innovación y a pequeños pilotos. A esta escala, las decisiones sobre proveedores de modelos, acceso a datos, asignación de costos, capacitación de empleados, resiliencia y estrategia de salida se convierten en responsabilidades ordinarias de gestión tecnológica.

Acción para la próxima semana: trate los servicios de IA como dependencias de producción. Controle la adopción y los resultados comerciales por separado, documente la concentración de proveedores, pruebe opciones de respaldo y asegúrese de que el crecimiento de licencias esté acompañado por gobernanza y valor medible.

De qué estaban hablando realmente las personas

La idea conectora de la semana era la diferencia entre una instrucción y un límite.

Se puede decir a un agente de IA que no tiene acceso a internet mientras la red todavía lo permite. Un PLC puede estar destinado a gestión privada mientras un módem olvidado lo expone públicamente. Un proceso de soporte puede requerir verificación de identidad mientras un empleado todavía confía en una interfaz familiar de Teams. Un contrato en la nube puede dividir la responsabilidad sin limitar técnicamente quién puede acceder a los datos.

Las políticas describen el comportamiento deseado. Los límites determinan lo que sigue siendo posible cuando un modelo, usuario, proveedor o control hace una suposición incorrecta.

Eso conduce a un conjunto práctico de preguntas:

  • ¿Puede el agente alcanzar destinos fuera de su alcance aprobado?
  • ¿Se puede acceder a una interfaz de gestión desde una conexión ordinaria a Internet?
  • ¿Puede un mantenedor publicar código a millones de sistemas descendentes?
  • ¿Puede un llamador externo aparecer dentro de una herramienta de colaboración confiable?
  • ¿Puede el acceso sobrevivir a un restablecimiento de contraseña, reconstrucción de endpoint o eliminación de proveedor?
  • ¿Puede la organización detener un proceso automatizado antes de su próxima acción?

La mejora de seguridad más importante de esta semana no es otro aviso de advertencia. Es convertir las expectativas en límites técnicos aplicados.

Lista de verificación de prioridades para la semana próxima

  1. Denegar por defecto el acceso a Internet para rangos de evaluación cibernética y cargas de trabajo de agentes de alto riesgo.
  2. Usar listas de permitidos de destino, credenciales sintéticas, monitoreo continuo y condiciones automáticas de parada para pruebas autónomas.
  3. Encontrar y eliminar PLCs, pasarelas OT, HMIs y módems celulares no documentados expuestos públicamente.
  4. Aplicar parches a los sistemas afectados de Exchange OWA, Cisco Secure FMC y Arista VeloCloud Orchestrator, luego buscar explotación previa.
  5. Revisar los permisos de buzones del lado del servidor, concesiones de OAuth y complementos en lugar de depender solo de restablecimientos de contraseña.
  6. Proteger a los mantenedores de paquetes con MFA resistente a phishing, controles de procedencia, actualizaciones retrasadas y alertas de cambio de editor.
  7. Restringir la comunicación externa de Teams y requerir verificación independiente para solicitudes de soporte remoto.
  8. Centralizar la identidad y el registro de auditoría en entornos de nube y SaaS de terceros que contienen datos sensibles.
  9. Medir el costo de IA por flujo de trabajo completado y dirigir tareas rutinarias lejos de modelos de frontera costosos.
  10. Requerir aprobación, auditoría, reversión y procedencia duradera antes de que los agentes o contenido generado entren en flujos de trabajo de alta confianza.

Fuentes

Fuentes primarias y oficiales:

Apoyo a la elaboración de informes y análisis: