Los atacantes tienen agentes de IA. Tus defensores también los necesitan.

Seis historias de seguridad y por qué las buenas personas necesitan que la IA trabaje de su lado

Era inevitable que los actores maliciosos pusieran a trabajar a los agentes de IA.

Cinco noticias de seguridad salieron a la luz el 21 de octubre y me llamaron la atención, además de una brecha de OpenCode que se había dado a conocer cuatro días antes.

La respuesta que veo es buenas personas con IA. Para las empresas que gestionan una infraestructura tecnológica, los agentes defensivos que trabajan las 24 horas del día, los 7 días de la semana, ya son un requisito operativo. Deben formar parte del presupuesto operativo. Los atacantes pueden seguir buscando puntos débiles mientras tu equipo duerme. Tu defensa también necesita cobertura continua. La dirección debe decidir qué vigilan esos agentes, sobre qué pueden actuar y quién responde cuando encuentran algo.

Los atacantes ya están usando agentes

La empresa de seguridad Straiker describió cómo un grupo llamado CyberCartel utilizó IA contra más de 400 objetivos en América Latina, incluidos bancos y empresas de pagos. Usó modelos comerciales en distintas etapas para robar contraseñas y datos de clientes y acceder a cuentas bancarias con poca intervención humana. Anthropic afirmó que investigó el caso después de que Straiker compartiera sus hallazgos y bloqueó el acceso del grupo a Claude.

OpenCode: defenderse mientras apenas se duerme

El 21 de octubre, Dax Raad, cofundador de la herramienta de programación con IA de código abierto OpenCode, advirtió a otros fundadores:

«No van a parar. Esto será cada vez más sofisticado y van a atacar cada superficie de tu sistema y a todos tus empleados».

La noche del 16 de octubre, un intruso había accedido a un sistema antiguo de OpenCode que estaba en proceso de retirada. Almacenaba claves de proveedores de IA que algunos usuarios habían guardado en OpenCode Console, el servicio de espacios de trabajo alojados de la empresa.

OpenCode informó de la brecha el 17 de octubre. Aproximadamente el 1,4 % de los usuarios de Console, aquellos que tenían vinculado un proveedor externo de IA, podrían haberse visto afectados. Les envió un correo para que revocaran y reemplazaran sus claves. Los atacantes estaban usando las claves robadas para enviar grandes volúmenes de solicitudes a proveedores de IA, lo que en algunos casos generó cargos no autorizados. Raad aclaró que las claves guardadas localmente en la aplicación OpenCode nunca llegan a OpenCode y no formaban parte de la brecha.

Raad describió tanto la exposición como la respuesta:

«Cualquier proyecto antiguo que hayas olvidado hace tiempo será encontrado y utilizado en tu contra».

«La única razón por la que estamos sobreviviendo es que tenemos agentes trabajando las 24 horas del día. Aun así, apenas estamos durmiendo».

Terminó diciendo: «Buena suerte, lamento que estén pasando por esto, pero en realidad es un problema colectivo al que todos nos enfrentamos».

Los agentes trabajaban continuamente y las personas seguían durmiendo muy poco. Quienes defienden los sistemas necesitan que los agentes asuman una mayor parte de ese trabajo para poder seguir el ritmo.

Pon en orden los sistemas que has olvidado

La carrera consiste en encontrar y corregir los sistemas que tu empresa ha olvidado. Las aplicaciones antiguas que siguen funcionando, las dependencias sin parches y las credenciales que quedaron en proyectos retirados les dan a los atacantes un punto de partida. La IA permite a tu equipo inventariar ese código más rápido, entender qué hace y preparar correcciones. Usa esa capacidad para cerrar las brechas antes de que alguien más las encuentre.

Asigna una persona responsable a cada repositorio y aplicación y decide qué corregir, reemplazar o retirar. Termina el trabajo de retirada: desconecta el sistema antiguo y revoca sus accesos.

Puede que el mayor riesgo de seguridad no sea el código que escribimos. Puede que sea el código en el que confiamos.

Railway: reemplaza las claves

Railway, una plataforma que las empresas usan para ejecutar aplicaciones, informó de que alguien había accedido a los sistemas que almacenaban las claves de API, las contraseñas de bases de datos y las credenciales de registros privados de sus clientes. Algunos secretos podrían haberse descifrado.

Imagina que contrataste al administrador de un edificio para custodiar las llaves maestras. Ahora te dicen que alguien podría haber hecho copias. Hasta que cambies las cerraduras, cualquiera que tenga una copia puede entrar.

Railway cree que este fue uno de una serie de ataques contra empresas de plataformas, con los proveedores de IA como objetivo final. Avisó a esos proveedores, pausó los despliegues mientras investigaba y pidió a todos sus clientes que reemplazaran los secretos y revisaran los registros, aunque creía que solo algunos clientes se habían visto afectados.

Una clave robada funciona hasta que alguien la revoca. Tu equipo necesita saber en qué lugares se usa esa clave para poder reemplazarla rápidamente.

LiteLLM: una descarga oficial puede estar comprometida

Durante unas dos horas, LiteLLM, una herramienta de código abierto que conecta software con proveedores de IA, distribuyó una versión maliciosa a través de sus canales oficiales de descarga. La versión 1.107.0 robaba credenciales e instalaba una puerta trasera. Fue la segunda vez que el proyecto se vio comprometido este año; Datadog documentó el ataque anterior en marzo.

Según el informe del incidente de LiteLLM, los atacantes usaron tokens de inicio de sesión robados a ingenieros para comprometer su proceso de publicación de versiones. El malware dejaba archivos que permanecían incluso después de desinstalar el paquete. Los equipos afectados tuvieron que eliminar esos archivos, reconstruir los sistemas y reemplazar todas las credenciales que esos sistemas podían leer.

GitLab: esto también forma parte de nuestra operación

Gestionamos nuestra propia instalación de GitLab, donde almacenamos y compilamos software. Aplicamos el parche del 21 de octubre ese mismo día. El incidente no nos afectó.

Era la segunda vulnerabilidad de GitLab en nueve días con una gravedad de 10 sobre 10. Permitía que una persona externa ejecutara código en un servidor sin iniciar sesión. Aplicar el parche para la vulnerabilidad del 12 de octubre no bastaba: esa corrección cubría versiones más recientes, mientras que esta se remontaba a GitLab 7.0, publicado en 2014. El servicio alojado de GitLab ya estaba corregido; las empresas que gestionaban sus propios servidores tenían que actuar.

PHP: la rapidez con la que se multiplicaron los intentos

PHP, el lenguaje que utilizan millones de sitios web, tenía dos vulnerabilidades críticas conocidas como PHP2Shell. Permitían que una persona externa tomara el control de un sitio web sin contraseña. La NSA y CERT-EU indicaron a las organizaciones que aplicaran los parches de inmediato o desconectaran los sistemas afectados. Es una recomendación inusualmente tajante.

Las correcciones para las versiones actuales salieron ese mismo día. PHP 8.1 y las versiones anteriores ya no cuentan con soporte regular, aunque algunos proveedores ofrecen correcciones y PHP publicó adaptaciones limitadas de los parches en código fuente para versiones anteriores. Consulta con tu proveedor o actualiza. Piensa en el viejo sitio de marketing, el portal de clientes que nadie revisa, el servidor de pruebas que nadie apagó o el equipo que un proveedor instaló hace años. Unas horas fuera de servicio pueden costar mucho menos que una brecha, el robo de datos de clientes y la pérdida de confianza.

Los detalles se filtraron antes del anuncio previsto y herramientas de IA de última generación ayudaron a encontrar las vulnerabilidades.

El CEO de Cloudflare, Matthew Prince, informó de que la red de Cloudflare había detectado miles de intentos de explotar PHP2Shell en las 10 horas anteriores al anuncio público. En los primeros 45 minutos posteriores, la cifra saltó a decenas de miles. En dos horas, a cientos de miles. Para cuando publicó su mensaje, ya eran millones.

Seis tareas para agentes de IA defensivos

CyberCartel muestra cómo los atacantes usan IA. Las brechas y vulnerabilidades de estas historias muestran el trabajo que los defensores tienen que mantener al día: encontrar sistemas expuestos, aplicar parches, reemplazar credenciales e investigar lo ocurrido. Las cifras de Prince ponen en perspectiva el tiempo disponible para responder. Los intentos de explotación ya estaban en marcha antes del anuncio.

La IA está abaratando la generación de código. Saber qué merece la pena construir o corregir vale oro. ¿Qué aplicación deberíamos retirar? ¿Qué dependencia pone en riesgo los datos de clientes? ¿Qué agente reduciría realmente la carga de trabajo? Generar más código no responderá esas preguntas por ti. Acertar en esas decisiones determina si la IA reduce tu exposición o la aumenta.

Esa carga de trabajo es mi argumento a favor de los agentes defensivos. Encárgales la búsqueda, el cruce de información y la supervisión, y deja en manos de las personas decisiones como desconectar un sistema esencial para el negocio o aprobar la revocación de una clave.

Yo empezaría con seis trabajos concretos:

1. Vigilar los parches. Contrastar los avisos de emergencia con los sistemas que realmente usas. Identificar las versiones afectadas, preparar la corrección y comprobar el resultado después. Una persona decide si se desconecta un sistema.
2. Preparar el reemplazo de claves. Llevar un registro de dónde están las claves, su antigüedad y las señales de exposición. Preparar los reemplazos, identificar todas las aplicaciones que usan las claves antiguas y documentar el trabajo. La revocación necesita la aprobación de una persona o una política definida de antemano.
3. Revisar las actualizaciones de software. Comparar una nueva versión con la que aprobaste y comprobar su huella digital antes del despliegue. Retener para revisión las descargas no aprobadas o que no coincidan.
4. Vigilar el gasto. Supervisar el uso de los proveedores de IA, señalar un pico a las 2 de la madrugada y hacer cumplir el límite de gasto de la clave afectada. El incidente de OpenCode muestra por qué las credenciales robadas también son un problema de facturación.
5. Encontrar sistemas olvidados. Encontrar la consola antigua, el proyecto abandonado o el sitio web desactualizado. Asignar una persona responsable y una fecha de retirada a cada uno. Los planes de retirada no eliminan los accesos; alguien tiene que terminar el trabajo.
6. Evaluar y priorizar incidentes. Recopilar registros, preservar las pruebas y redactar el informe de estado. Aislar los sistemas afectados dentro del alcance aprobado. Revocar todo, eliminar datos o desconectar un sistema esencial para el negocio sigue necesitando la aprobación de una persona.

Cada agente necesita límites: información y herramientas aprobadas, solo los accesos que requiere su trabajo, los modelos de IA que permite tu organización, un presupuesto de gasto y un registro de cada solicitud, respuesta y acción. Un agente con llaves maestras y acceso sin restricciones es otro sistema privilegiado que tienes que defender. Revisa lo que puede hacer y lo que produce antes de ponerlo en producción.

Cinco preguntas que la dirección debería poder responder

Usa estas preguntas para decidir por dónde empezar:

1. ¿Conocemos todos los sistemas que usamos y quién es responsable de cada uno, incluidos sitios web antiguos, entornos de prueba y proyectos de equipos que ya no están?
2. ¿Quién custodia nuestras claves y podríamos reemplazarlas en cuestión de horas si mañana un proveedor sufriera una brecha?
3. ¿Podemos aplicar un parche de emergencia fuera del ciclo normal de planificación?
4. ¿Qué herramientas de IA usa el personal, incluidas aquellas en las que se registró por su cuenta, y qué datos o claves guardan esas herramientas?
5. ¿Quién vigila cuando nosotros no estamos?

Si faltan respuestas, asigna a alguien para que las consiga.

Establece la estructura operativa

Por eso construimos AgentShelf de esta manera. Cada agente tiene su propio espacio de trabajo, que reúne sus instrucciones y los controles anteriores con visibilidad sobre el uso. Construyes, despliegas, reutilizas y gobiernas agentes desde un solo lugar.

Exigimos el mismo nivel a nuestra propia infraestructura. Hemos invertido mucho en infraestructura de seguridad y supervisión para prepararnos frente a estas amenazas. Nuestro CTO, Edgar Joya, merece el reconocimiento por ese trabajo.

Si quieres profundizar en cómo nosotros y nuestros clientes estamos usando agentes de IA defensivos para identificar amenazas y repeler ataques, ponte en contacto. Con gusto te lo mostraremos.

Apéndice: para tu equipo de TI

1. PHP (PHP2Shell, CVE-2026-109618 y CVE-2026-109619). Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, incluidos los sitios antiguos y los equipos de proveedores. Para PHP 8.1 y versiones anteriores, consulta si hay una corrección respaldada por tu proveedor o actualiza. PHP también publicó adaptaciones mínimas de los parches en código fuente para 7.4, 8.0 y 8.1. Si no puedes aplicar una corrección, aísla el sistema afectado.
2. Railway. Rota todas las variables de entorno almacenadas y las credenciales de registros privados, y revisa los registros de los servicios a los que dan acceso esas claves.
3. LiteLLM 1.107.0. Revisa los archivos de bloqueo de dependencias, las cachés y los hashes de las imágenes. El malware robaba credenciales de acceso a la nube, claves SSH, datos del navegador, configuraciones de herramientas de IA y claves de proveedores de IA almacenadas en LiteLLM. Se ejecutaba al iniciar el sistema e instalaba acceso remoto. Según LiteLLM, los atacantes robaron tokens de inicio de sesión a tres ingenieros y ejecutaron el proceso de publicación del proyecto sobre una copia que lo suplantaba y cuyo nombre se diferenciaba por un solo guion. Elimina los archivos de inicio que dejó el malware, que permanecen tras desinstalar el paquete, reconstruye el sistema y rota todas las credenciales que el equipo podía leer.
4. GitLab (CVE-2026-110264). Solo para instalaciones autogestionadas. Instala las versiones corregidas del 21 de octubre aunque ya hayas aplicado la corrección del 12 de octubre (CVE-2026-97229).
5. OpenCode Console. OpenCode describió el incidente como un ataque de destilación a gran escala. Si alguien recibió el correo de OpenCode del 17 de octubre sobre la brecha, revoca las claves vinculadas de OpenAI, Anthropic y Google en el panel de cada proveedor. Eliminarlas de Console no basta. Crea reemplazos, actualiza todo lo que usaba las claves antiguas y revisa las facturas de los proveedores. Las claves guardadas localmente en la aplicación OpenCode no formaron parte de este incidente.
6. Inventario. Enumera todos los sistemas que usamos, qué hacen y quién es responsable de cada uno.
7. CyberCartel. La investigación de Straiker, de la que también informó The Information, identifica el sistema de ataque como CARLIY0S. Los modelos comerciales incluían Claude, Grok y Kimi. El CEO de Straiker, Ankur Shah, afirmó que el ataque lleva mucha ventaja sobre la defensa y que las empresas no están preparadas.

Lectura adicional: Activist Checklist explica la seguridad con un lenguaje sencillo, paso a paso, e incluye una herramienta para comprobar si un dispositivo sigue recibiendo actualizaciones de seguridad. Se creó para activistas, pero su enfoque sirve para cualquier equipo.