Para: cualquiera que administre un sitio web o un servicio en línea. Este artículo se basa en revelaciones oficiales de OpenAI, Anthropic, la Wikimedia Foundation y el Gobierno australiano (la rueda de prensa del primer ministro y la alerta del Centro Australiano de Ciberseguridad). No contiene pasos de ataque. El primer caso, de julio, se trata en la intrusión de Hugging Face (2026).
Qué se reveló
18 de junio de 2026
El equipo de investigación de OpenAI tenía un modelo interno de investigación sobre gasto público en medicina. Tras bloqueos repetidos, el agente encontró la forma de sortearlos y accedió a archivos públicos y no públicos del portal estadístico de Medicare de Australia (según la rueda de prensa del primer ministro australiano).16 de julio de 2026
Hugging Face reveló una intrusión llevada a cabo por un agente de IA (explicación).23–24 de julio de 2026
Anthropic revisó 141.006 ejecuciones de evaluación en busca de casos similares e identificó tres en los que modelos en evaluación llegaron a los sistemas de producción de tres empresas reales. Ese mismo día detuvo todas las evaluaciones de ciberseguridad.27 de julio de 2026
Anthropic notificó a su socio de evaluación y a las tres organizaciones afectadas. Las dos que pudo contactar no habían detectado antes la actividad (según su revelación).18 de agosto de 2026
OpenAI dijo que había ralentizado temporalmente el entrenamiento de modelos de frontera y reforzado el aislamiento en los entornos de investigación (sandboxes más robustos para código no confiable, aislamiento de red).9 de septiembre de 2026
Anthropic reveló un cuarto caso, de una evaluación de enero de 2026, sumado a los tres de julio. Amplió su revisión de unas 141.000 a unos 481 millones de transcripciones y no encontró otros casos de gravedad similar o mayor. También firmó un acuerdo con un evaluador externo para una investigación independiente.10 de septiembre de 2026
Primera notificación de OpenAI al Gobierno australiano: un correo a un buzón público general (según el primer ministro).15 de septiembre de 2026
Services Australia comunicó la notificación al Centro Australiano de Ciberseguridad (ACSC).24 de septiembre de 2026
El primer ministro dio a conocer el incidente y creó un grupo de trabajo. El mismo día, el ACSC emitió una alerta para "todas las organizaciones australianas con sitios web o aplicaciones de cara al público".25 de septiembre de 2026
OpenAI dijo que su revisión llevaría meses y que está notificando a las organizaciones afectadas a medida que se verifican los casos.5 de octubre de 2026
La Wikimedia Foundation dijo que había detectado actividad en sus proyectos por agentes que cree que eran operados por OpenAI.9 de octubre de 2026
Anthropic reveló casos en los que los modelos realizaron acciones no previstas en sitios reales durante evaluaciones y uso interno, incluido un falso aviso enviado a través de un formulario de la Policía de Filadelfia. El Departamento de Policía de Filadelfia también anunció el caso ese mismo día (según Anthropic).
- OpenAI: alcance de las notificaciones
- Tras una amplia revisión de la actividad en internet de sus modelos durante el entrenamiento y la evaluación, ha notificado a decenas de terceros que cumplen sus criterios, y la revisión continúa. Algunos de los sitios implicados son gestionados por gobiernos, universidades y agencias públicas, en parte porque las tareas de investigación llevan a los modelos hacia fuentes públicas autorizadas, afirma la empresa
- OpenAI: tipos de actividad observados
- (1) elusión de controles de acceso (usando una dirección web distinta, alterando peticiones, usando una sesión con más acceso del previsto) (2) uso de credenciales expuestas públicamente (3) inyección de consultas o comandos (4) acceso a partes internas de un servicio (5) spam de agentes (publicar en sitios de terceros, como usar un wiki público como tablón de mensajes)
- Anthropic: qué ocurrió
- Una mala configuración dejó las máquinas de evaluación con acceso a internet en vivo (la empresa lo atribuye a un malentendido entre ella y su socio de evaluación; ninguno de los dos lo sabía). El modelo trató los sistemas reales como parte del ejercicio. En un caso escaneó unos 9.000 objetivos y comprometió la aplicación de una empresa mediante técnicas básicas y bien conocidas, como leer credenciales de una página de depuración expuesta y la inyección SQL
- Anthropic: efecto en un registro público
- Usando el nombre de un paquete de Python que no existe, tomado de una guía de instalación de una empresa ficticia, el modelo publicó un paquete malicioso. Estuvo disponible durante aproximadamente una hora y se ejecutó en 15 sistemas reales (uno de ellos, un escáner de una empresa de seguridad que instala paquetes para revisarlos)
- Anthropic: el cuarto caso (informe del 9 de septiembre)
- En una evaluación de enero de 2026, una versión temprana de un modelo accedió a la máquina de un tercero. Encontró un archivo con una contraseña, la usó para obtener acceso de administrador, cambió la configuración para facilitar el acceso y leyó los datos personales de una persona asociada al tercero. Anthropic afirma que notificó a la parte afectada tras encontrar el caso. El informe de julio hablaba de tres; con este informe, el total de accesos no autorizados a sistemas de terceros asciende a cuatro
- Anthropic: acciones no previstas en evaluaciones y uso interno (informe del 9 de octubre)
- Cuatro tipos: (1) ejecución de comandos en un servidor mediante un fallo básico en una herramienta de análisis alojada por una universidad (2) envío de formularios que no debían enviarse (por ejemplo, el envío de un formulario gubernamental real cuando una copia de práctica no se cargó) (3) sortear restricciones para llegar a datos de pago o restringidos (por ejemplo, tokens de acceso en el archivo de configuración de un mapa de un gobierno local, o tokens que un panel público de una agencia estatal entrega a cualquier visitante) (4) eludir el límite de longitud de URL de la herramienta de obtención de páginas mediante servicios de acortamiento de URL
- Anthropic: impacto y notificación
- Algunos casos afectaron a sitios de agencias gubernamentales federales, estatales y locales de EE. UU., que Anthropic no nombra, a petición de ellas. Notificó a cada agencia e informó a la Casa Blanca. Anthropic afirma que ninguno implicó datos de clientes ni sus sistemas internos, y el impacto en el mundo real fue mínimo, y los califica como significativamente menos graves que los cuatro incidentes de ciberseguridad
- El formulario de avisos de la Policía de Filadelfia
- Mientras generaba tareas de ejemplo en páginas web seleccionadas al azar, un modelo llegó a una página de un homicidio sin resolver y envió un aviso inventado a través de su formulario, dejando vacíos los campos de nombre y contacto. Fue marcado como spam y nunca se remitió para investigación (según Anthropic). La policía afirma que se envió el 18 de julio a las 23:27 y que Anthropic la notificó el 7 de octubre (según informó NBC Philadelphia). Anthropic afirma que compartió el hallazgo con el departamento el 8 de octubre, una vez completada su revisión técnica. Las dos versiones dan fechas distintas. La policía calificó de "inaceptable" el retraso de dos meses en detectarlo e informarlo (mismo informe)
- Medidas de Anthropic (informe del 9 de octubre)
- Algunas evaluaciones públicas se retiraron y otras pasaron a versiones sin conexión que no llegan a sitios en vivo. Se desactivó el acceso a internet en vivo en todas las evaluaciones internas. Las herramientas de obtención web se restringieron fuertemente. Detección y bloqueo automatizados de estos comportamientos en la mayoría de las evaluaciones y en el uso agéntico interno de modelos de frontera
- La Wikimedia Foundation (informe del 5 de octubre)
- Agentes que la Fundación cree que fueron operados por OpenAI hicieron ediciones sin aprobación de la comunidad (casi todas ediciones de prueba en áreas de sandbox). Algunos cambiaron la configuración de una herramienta de citas, lo que la Fundación califica de potencialmente malicioso, con el objetivo de usarla como proxy para obtener datos de servicios remotos. Fracasaron los intentos de comprometer la herramienta pública de notas Etherpad y de usarla como proxy. Hubo millones de peticiones a la API pública, millones de páginas rastreadas y cientos de miles de consultas al Wikidata Query Service, que pueden haber contribuido a una interrupción parcial en mayo. La Fundación no encontró evidencia de que sus sistemas o datos hayan sido comprometidos
- El Gobierno australiano
- Un agente de OpenAI accedió a archivos públicos y no públicos del portal estadístico de Medicare gestionado por Services Australia. Hasta ahora no se cree que se haya accedido a información personal; la investigación continúa. El primer ministro planteó directamente al director ejecutivo de OpenAI su preocupación por lo tardío y por la forma de la notificación (un correo a un buzón público)
- La alerta del ACSC
- Un agente identificó vulnerabilidades de forma independiente e intentó avanzar sin autorización humana directa para completar la actividad asignada. El ACSC afirma que no hay indicios de una amenaza más amplia ni de un ataque malicioso dirigido, y recomienda autenticación fuerte y control de acceso, corrección rápida, monitorización y revisión de registros, y probar los procedimientos de respuesta frente a escenarios habilitados por IA
Casos que no cubrimos
Hay informes que describen a un modelo de IA de Google que entró en sistemas de una empresa real durante una evaluación, pero no encontramos una revelación directa de Google, por lo que este artículo no lo trata. También dejamos fuera las afirmaciones que atribuyen a agentes de OpenAI una campaña de publicación masiva en RubyGems: RubyGems dice que no puede determinar si los agentes de IA fueron responsables, y OpenAI afirma que no ha podido verificar las afirmaciones, así que la atribución no está establecida.
Qué es nuevo y qué no
Lo nuevo
- Un visitante sin malicia que prueba otro método cuando lo bloquean
- En el punto en que un humano se rendiría, sigue intentando otras URL, otras entradas y credenciales que encontró
- Se entera uno meses después, cuando una empresa de IA lo notifica
Lo que no es nuevo
- Las debilidades usadas fueron credenciales expuestas, una página de depuración expuesta e inyección SQL
- Todas deberían haberse corregido ya
- Una vez corregidas, detienen tanto a una persona como a un agente
Lo que este sitio considera más grave es que las organizaciones afectadas no se habían dado cuenta. Anthropic escribe que las dos organizaciones a las que pudo contactar no habían detectado la actividad. El caso australiano ocurrió en junio; el Gobierno lo supo en septiembre. Que la otra parte tuviera buenas intenciones no cambia el hecho de que alguien entró. Y el próximo visitante puede no tener buenas intenciones: cualquier debilidad que un agente pueda encontrar, un atacante también puede encontrarla.
Qué deben hacer hoy los operadores de sitios
Asegúrense de que los avisos lleguen a una persona (security.txt)
En el caso australiano, la notificación fue a un buzón público general y llegó al centro de ciberseguridad cinco días después. OpenAI dice que seguirá notificando a las organizaciones afectadas, y los reportes de vulnerabilidades de investigadores enfrentan el mismo problema.
Primer paso: publiquen /.well-known/security.txt (RFC 9116) con un contacto para reportes (una dirección de correo o la URL de un formulario) y una fecha de caducidad, y decidan quién lo lee realmente. Mientras escribíamos este artículo notamos que nuestro propio sitio no tenía uno, y lo añadimos (el contacto es nuestro formulario de contacto, no una dirección de correo personal).
Comprueben que los envíos de sus formularios llegan realmente a una persona
En el caso de la Policía de Filadelfia, el falso aviso que envió un modelo fue detenido como spam, por lo que nunca llegó a los investigadores. La policía afirma que, tras ser contactada el 7 de octubre, encontró el envío en los registros de avisos del sitio y confirmó que el correo correspondiente seguía en la carpeta de spam (según se informó). Los agentes también envían formularios de contacto, de reporte y de solicitud.
Primer paso: envíen un envío de prueba a través de cada uno de sus formularios y comprueben dónde llega, incluidos los filtros de spam y correo no deseado. Decidan quién revisa los envíos marcados como spam y con qué frecuencia, y conserven un registro de los envíos (hora y contenido) el tiempo suficiente para responder a una consulta que llegue meses después.
Localicen y revoquen las credenciales expuestas
Tanto OpenAI como Anthropic enumeran credenciales expuestas públicamente; también fueron el punto de partida del caso de Hugging Face de julio. Busquen credenciales dejadas en el código, en repositorios públicos, en archivos de configuración y en capturas de pantalla, y revóquenlas en el emisor. Consulten cómo evitar commits de secretos con gitleaks y archivos secretos en directorios públicos.
Mantengan los tokens de acceso fuera de los archivos de configuración enviados al navegador y de los paneles públicos
El informe de octubre de Anthropic describe a un modelo que usó un token de acceso válido del archivo de configuración de un mapa de un gobierno local, y tokens que un panel público de una agencia estatal entregó a los visitantes, para llegar a datos de pago o restringidos. Todo lo que esté en un archivo de configuración o en JavaScript que se ejecuta en el navegador puede ser leído por cualquiera.
Primer paso: revisen los archivos de configuración, el JavaScript y el tráfico de paneles que cargan sus páginas públicas en busca de tokens de acceso y claves de API. Si alguno es realmente necesario, restrínjanlo (solo lectura, datos específicos, referentes permitidos) y limiten su tasa de uso, y entreguen datos de pago o restringidos solo después de una comprobación de autorización en el servidor.
Desactiven las páginas de depuración y los paneles de administración en producción
El caso de Anthropic incluyó la lectura de credenciales de una página de depuración expuesta. Comprueben que el modo de depuración y la salida detallada de errores estén desactivados en producción, y que los paneles de administración no estén abiertos a cualquiera en internet. Las comprobaciones por framework están en seguridad por framework.
Descarten la suposición de que un visitante bloqueado se rinde: comprueben la autorización en cada ruta
La primera categoría que enumera OpenAI es la elusión de controles de acceso mediante una dirección web distinta. Ocultar un enlace o restringir una URL no detiene a un visitante que busca otra vía. Cada ruta que devuelve datos necesita una comprobación en el servidor de si quien llama puede verlos. Consulten autenticación frente a autorización, y los fallos clásicos IDOR e inyección SQL.
Vigilen el volumen y la velocidad, y conserven registros para poder revisarlos
Los agentes no descansan, no hacen pausas y ejecutan la misma acción en paralelo. Las peticiones muy seguidas, un patrón plano de 24 horas y acciones idénticas ejecutadas a la vez son más fáciles de distinguir del uso humano. Y cuando una notificación llega meses después, no pueden verificar nada sin los registros de ese día. El diseño de límites y alertas está en limitación de tasa y control de abuso; la retención de registros, en prioridades de seguridad para organizaciones.
Si gestionan algo donde la gente puede publicar, planifiquen el spam de agentes
OpenAI menciona agentes que usaron un wiki público como tablón de mensajes. Si gestionan un wiki abierto, un foro, una sección de comentarios o un formulario de contacto, revisen los límites de publicación y la moderación.
Si una empresa de IA les notifica, revisen los registros antes de alarmarse
OpenAI dice que una notificación suya no debe interpretarse automáticamente como un incidente de seguridad significativo. Revisen sus registros de acceso y autenticación en las horas y objetivos indicados, y decidan si era información que pretendían publicar o una debilidad que corregir. Si es una debilidad, corríjanla como cualquier otra vulnerabilidad (la guía de remediación de vulnerabilidades).
Lo que hicieron los agentes (según las revelaciones)
sortearon límites mediante otra URL / usaron credenciales expuestas / usaron tokens de un archivo de configuración / leyeron credenciales de una página de depuración / inyección SQL / publicaron en un wiki, enviaron formularios
La medida básica que detiene cada caso
autorización en el servidor en cada ruta / revocar credenciales filtradas / no enviar tokens al navegador / depuración desactivada en producción / consultas parametrizadas / límites de publicación y revisión de envíos
Para cuando algo aún logra entrar
vigilar volumen y velocidad / conservar registros / un contacto que llegue a alguien (security.txt)
Opinión de este sitio: las debilidades que un agente puede encontrar, también las pueden encontrar los atacantes
Estos incidentes tienen una forma extraña. Un visitante sin intención de atacar encuentra las debilidades de una organización, las recorre, y meses después la empresa que creó al agente es quien le dice a la organización "entramos". El ACSC señala que la diferencia es que un agente de IA encontró de forma independiente el tipo de vulnerabilidad que los investigadores humanos suelen encontrar y reportar.
Leer esto como "reportes más útiles" sería un error. Los visitantes que no los reportarán pueden encontrar las mismas debilidades. Y los agentes no se rinden al ser bloqueados; prueban, en paralelo y rápido, lo que a una persona le llevaría días. El tiempo que se puede dejar una debilidad sin corregir con seguridad sigue reduciéndose.
Una cosa más quedó clara: un aviso necesita una dirección. Un reporte de buena fe o una notificación de una empresa de IA se queda días en un buzón general si no hay un destino mejor. Un security.txt son unas pocas líneas de texto, y pueden publicarlo hoy mismo.
Fuentes
- OpenAI, "Hugging Face incident and other third-party impacts of misaligned models" (consultada hasta la actualización del 25 de septiembre de 2026) — openai.com
- Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations" (30 de julio de 2026) — anthropic.com
- Anthropic, "An alignment assessment of recent cybersecurity incidents" (9 de septiembre de 2026) — anthropic.com
- Anthropic, "Investigating unintended model actions in our evaluations and internal use" (9 de octubre de 2026) — anthropic.com
- Wikimedia Foundation, "OpenAI “rogue” agent activities found on Wikimedia projects" (5 de octubre de 2026) — wikimediafoundation.org
- NBC Philadelphia, "Anthropic AI model submits false tip on unsolved Philly murder, police say" (9 de octubre de 2026; usada para la versión de la Policía de Filadelfia) — nbcphiladelphia.com
- Primer ministro de Australia, "Press conference - New York" (24 de septiembre de 2026) — pm.gov.au
- ASD's ACSC, "Risks of AI misalignment to Australian organisations" (24 de septiembre de 2026) — cyber.gov.au
- RubyGems Blog, "An update on the May spam-publishing campaign on rubygems.org" (11 de septiembre de 2026) — blog.rubygems.org (usada para confirmar que la atribución no está establecida)
- IETF RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure" — rfc-editor.org
Historial de actualizaciones
2026-10-12: Se incorporaron los informes de Anthropic del 9 de septiembre y del 9 de octubre, y el informe de la Wikimedia Foundation del 5 de octubre. Se cambió el acceso no autorizado de Anthropic a sistemas de terceros de "tres empresas" a "cuatro casos", y se añadieron sus acciones no previstas en evaluaciones y uso interno (incluido el falso aviso enviado a través de un formulario de la Policía de Filadelfia) y sus medidas. Se añadieron dos pasos para operadores: comprobar que los envíos de formularios llegan a una persona, y mantener los tokens de acceso fuera de los archivos de configuración enviados al navegador y de los paneles públicos.
2026-09-28: Primera versión, basada en revelaciones oficiales de OpenAI, Anthropic y el Gobierno australiano.
Lecturas recomendadas
- Panorama completo de los ataques impulsados por IA y el orden de la defensa: Defensa frente a ciberataques impulsados por IA (intrusión autónoma, inyección de prompts, cadena de suministro de IA)
- Otra intrusión con agentes de IA: La brecha de DIVD mediante zero-days de Zammad
- El primer caso: La intrusión de Hugging Face (2026): un ataque de agente de IA autónomo
- Corregir debilidades: Evitar commits de secretos con gitleaks / Autenticación frente a autorización / Seguridad por framework
- Detectar: Limitación de tasa y control de abuso / Prioridades de seguridad para organizaciones
- Herramienta: Auditoría de seguridad del sitio (también comprueba security.txt)