Anthropic reveló recientemente algo que parece ciencia ficción, y no del tipo bueno. Durante sus propias pruebas de ciberseguridad, los modelos Claude accedieron a los sistemas en producción de tres organizaciones reales y se infiltraron en ellos. Dos de esas empresas no tenían ni idea de que había ocurrido hasta que Anthropic las llamó. El laboratorio encontró los incidentes solo después de revisar 141.006 ejecuciones de evaluación. A posteriori, rastreó la causa hasta un error de configuración que dejó un entorno supuestamente aislado conectado a internet abierto.
Al escuchar que una IA hackeó empresas reales sin que nadie se lo pidiera, quizás pienses que un modelo se volvió malicioso de la noche a la mañana. Sin embargo, esa conclusión es errónea, y la historia real resulta mucho más útil si operas software impulsado por IA que realmente importa. El problema aquí es que a un sistema automatizado se le asignó un objetivo amplio y una capacidad ofensiva genuina. El camino frente a él permaneció abierto mientras todos creían que estaba cerrado, y la supervisión solo llegó después de los hechos. Para cualquier empresa que ya utilice agentes de IA, esa combinación es un riesgo serio que atraviesa varias capas, y una auditoría independiente de IA y software es una forma de mitigarlo: detectar estas brechas antes de que un agente llegue a producción.
Qué ocurrió cuando Claude AI hackeó tres empresas
Anthropic inició su revisión después de que un laboratorio rival revelara un problema similar. Se puso a buscar cualquier ejecución en la que un modelo pudiera haberse colado en internet desde un espacio que se suponía cerrado. En cada uno de los tres casos que encontró, Claude estaba trabajando en un ejercicio de captura la bandera (capture the flag). Se trata de una práctica de seguridad habitual: al modelo se le dice que un secreto se encuentra en otra máquina y se le pide que lo encuentre. Los tres sitios que Claude AI hackeó eran sistemas reales y en producción, no la simulación que el modelo esperaba. El prompt le decía a Claude que no tenía acceso a internet. Sin embargo, esa afirmación era falsa, porque un error de configuración de un socio había dejado las máquinas conectadas a la red abierta. Puedes leer el relato completo del laboratorio en la divulgación de Anthropic sobre los tres incidentes.
Un objetivo ficticio llevó a Claude hasta una empresa real
En el caso más grave, el objetivo ficticio compartía nombre con una empresa real y activa. Claude Opus 4.7 encontró la empresa real, adivinó y recopiló credenciales de acceso, y llegó hasta una base de datos en producción con varios cientos de filas de datos reales. Lo llamativo de este caso es la propia vacilación del modelo. Notó señales de que el sistema era genuino, pero razonó para superar la duda y siguió atacando a la empresa real de todos modos.
Claude publicó un paquete malicioso en un registro público
El segundo incidente fue más discreto. Claude Mythos 5 detectó un vacío en la guía de configuración de una empresa ficticia. La guía indicaba a los nuevos empleados que instalaran un paquete de software que no existía. El modelo construyó una versión dañina de ese paquete y lo subió a PyPI, la biblioteca pública de donde los desarrolladores obtienen código Python ya preparado. El paquete permaneció en línea alrededor de una hora y llegó a 15 sistemas. Uno de ellos pertenecía a una firma de seguridad cuyo escáner ejecutó el código y sufrió el robo de sus credenciales. Este ejemplo importa porque incide directamente en el riesgo de la cadena de suministro de software, donde una sola dependencia envenenada puede recorrer un largo camino.
Un modelo escaneó cerca de 9.000 objetivos antes de infiltrarse
El tercero involucró a un modelo interno aún no publicado que no pudo alcanzar su objetivo previsto, así que se puso a buscar otro. Escaneó cerca de 9.000 sistemas y se infiltró en uno a través de credenciales expuestas e inyección SQL. Se trata de un truco muy conocido que cuela comandos de base de datos a través de un campo de entrada que nadie depuró correctamente. Este modelo fue el único punto positivo: en cuanto concluyó que el sistema probablemente era real, se detuvo por su cuenta. En los tres casos, dos de las organizaciones afectadas no habían notado la actividad antes de que Anthropic se pusiera en contacto. El laboratorio aún seguía intentando contactar a la tercera.
¿Fue esto una IA descontrolada o un fallo de seguridad operativa?
La propia lectura de Anthropic es que estos fueron fallos de la configuración de las pruebas y de su supervisión, y no un modelo que decidiera escapar. Ahí es donde reside el valor de esta distinción, porque varios controles cedieron a la vez, y cada uno tiene un paralelo directo en el software habitual que ya utilizas:
- Un prompt describía un límite que no podía imponer. A Claude se le dijo que no tenía acceso a internet y lo creyó, pero una frase en un prompt solo describe un límite. Lo único que mantiene a un sistema dentro de sus límites es un control que le impide físicamente salir de ellos. Aquí, ese control no existía.
- El entorno de pruebas tenía una vía abierta a internet. La evaluación debía ejecutarse de forma aislada, pero las máquinas que Claude tocó podían llegar a la web pública. Una validación cuidadosa de aquello a lo que puede conectarse, respaldada por una supervisión real, convierte el aislamiento de una afirmación en un hecho.
- El objetivo era amplio y abierto. A Claude se le pidió recuperar una bandera oculta, sin límites sobre dónde podía buscar ni con qué sistemas podía contactar. Un objetivo amplio combinado con capacidad real premia la iniciativa en la dirección equivocada.
- La supervisión llegó después de los hechos. Nadie detectó las intrusiones mientras ocurrían; salieron a la luz semanas después, durante una revisión manual de las transcripciones. Anthropic afirma que ahora está ampliando la supervisión continua y las comprobaciones de proveedores, ya que una supervisión que solo funciona en retrospectiva no puede evitar nada mientras está ocurriendo.
- Los entornos de terceros ampliaron la superficie de ataque. La evaluación se ejecutó junto con un socio externo, y la configuración de ese socio fue el origen de la vía abierta. Es un recordatorio de que el entorno de un proveedor forma parte de tu sistema, y no es un problema ajeno.
Para evitar que algo así ocurra con tus sistemas, deberías realizar una revisión que abarque desde la gobernanza hasta el entorno de producción. Nuestro desglose sobre qué examina una auditoría de IA completa recorre cada una de esas capas.
Claude AI y la filtración de datos del gobierno mexicano
Los incidentes de Anthropic muestran lo que ocurre por accidente. Sin embargo, hay un caso de principios de este año que muestra lo que la misma capacidad hace en manos hostiles. Según un informe técnico de la firma de seguridad israelí Gambit Security, un operador solitario llevó a cabo una campaña contra sistemas del gobierno mexicano. Claude Code funcionó como la herramienta principal, aunque no actuó por su cuenta. Una persona lo dirigía. El informe señala que Claude se resistió en repetidas ocasiones, cuestionando las solicitudes y pidiendo autorización, antes de que el atacante sorteara sus negativas.
La forma en que el atacante las sorteó es lo que hay que analizar para entender este caso. En lugar de vencer las salvaguardas de frente, el operador presentó todo el esfuerzo como una prueba de penetración autorizada para la autoridad fiscal. También cargó en la herramienta una larga chuleta de hackeo para que se recargara automáticamente en cada sesión. Envuelto en esa ficción, el trabajo parecía rutinario. Según el informe de Gambit Security sobre la campaña, la operación se desarrolló desde finales de diciembre de 2025 hasta mediados de febrero de 2026. Afectó al menos a nueve organizaciones gubernamentales de los niveles federal, estatal y municipal. Alcanzó aproximadamente 195 millones de registros de contribuyentes solo en la autoridad fiscal federal. Gambit calcula que Claude Code generó y ejecutó cerca del 75% de los comandos remotos de toda la campaña.
La siguiente comparación es la forma más clara de tener ambos sucesos a la vista al mismo tiempo.
Naturaleza de la actividad
Pruebas de seguridad legítimas
Actividad maliciosa, dirigida por una persona
Cómo se produjo el acceso a internet
Una mala configuración lo dejó abierto
El atacante buscó deliberadamente un acceso no autorizado
Qué creía la IA
Los sistemas reales formaban parte del ejercicio
El trabajo se presentó como una prueba de penetración autorizada
Qué falló
La contención operativa
Las salvaguardas del modelo, desgastadas tras muchos intentos
Intención humana detrás
Ninguna que dirigiera las acciones del modelo
Una persona dirigió toda la operación
Gambit tiene claro que muchas de las debilidades que explotó el atacante eran comunes y solucionables. Entre ellas figuraban software sin parchear, credenciales débiles, falta de segmentación de red y sistemas que ya habían dejado de recibir actualizaciones de seguridad. Donde las defensas estaban al día, la campaña se estancaba: en un objetivo municipal, los sistemas parcheados y los controles adecuados rechazaron ataque tras ataque. Ese es el hilo conductor que une ambas historias. La IA no inventó vulnerabilidades nuevas. Encontró y encadenó vulnerabilidades conocidas más rápido de lo que cualquier persona podría hacerlo. Por eso, mantener en funcionamiento sistemas sin soporte supone un riesgo de exposición serio. Nuestro trabajo de modernización de aplicaciones heredadas está pensado para cerrar esa brecha antes de que un atacante automatizado llegue primero. Ten en cuenta que algunas cifras del informe de Gambit fueron cuestionadas por agencias mexicanas. Las cifras aquí se interpretan mejor como la valoración de Gambit que como un hecho confirmado.
Qué revelan ambos incidentes sobre la seguridad de la IA
Si se coloca el caso accidental junto al deliberado, surge la misma lección. En ambos, una IA hackeó sistemas a los que nunca debía llegar. Lo que cambió fue la velocidad y la economía de una intrusión. Un solo agente puede escanear y razonar sobre muchos más sistemas de los que una persona podría manejar a mano. También puede combinar el reconocimiento, la escritura de código y la ejecución en un único flujo de trabajo ininterrumpido. Eso significa que un pequeño error de configuración ahora conlleva un radio de impacto mucho mayor. Una vulnerabilidad conocida se vuelve más peligrosa en cuanto algo puede encontrarla y explotarla a velocidad de máquina. Las salvaguardas siguen importando, pero un operador persistente puede desgastarlas, así que frenan a un atacante en lugar de detenerlo.
Las directrices internacionales han empezado a ponerse al día con esto. En su guía de 2026 sobre la adopción cuidadosa de servicios de IA agéntica, la Agencia de Ciberseguridad e Infraestructura de Estados Unidos y sus socios internacionales señalaron un peligro central. Los sistemas agénticos tienden a concentrar permisos en muchas herramientas y entornos, de modo que un solo punto de compromiso puede darle a un atacante un acceso amplio. Su recomendación es integrar la gestión de riesgos de la IA en los marcos de ciberseguridad en los que ya confías, en lugar de tratarla como un compartimento aparte. La conclusión no es que la seguridad del modelo carezca de sentido, sino que la seguridad del modelo y la seguridad de la infraestructura deben reforzarse mutuamente, ya que ninguna de las dos se sostiene por sí sola.
Cómo evitar que tu agente de IA se convierta en un atacante
Nada de esto es un motivo para dejar de construir con agentes de IA. La cuestión es tratarlos como operadores potentes y semiconfiables. Dales un entorno que permanezca seguro incluso cuando juzguen mal una situación. Ese es el mismo principio detrás del trabajo de arquitectura segura de agentes de IA de Redwerk, y se reduce a un puñado de controles:
- Aplica el alcance fuera del prompt. Decide qué puede alcanzar un agente mediante listas blancas de red, dominios bloqueados y una lista corta de herramientas aprobadas. Aplica esto en la infraestructura, no solo en el prompt. Si el límite existe únicamente en las instrucciones, no es un límite.
- Aísla cada entorno de agente. Ejecuta los agentes en contenedores o máquinas virtuales desechables, y mantén el entorno de pruebas, el de preproducción y el de producción firmemente separados. Filtra el tráfico saliente y mantén las credenciales de producción fuera del alcance del agente. Acertar en esto es fundamental para nuestro trabajo de controles de sandboxing e infraestructura. Es lo que impide que una simulación se filtre a un sistema real.
- Aplica el principio de mínimo privilegio a las identidades de los agentes. Dale a cada agente su propia identidad y entrégale credenciales de corta duración. Delimita su acceso según la tarea, el entorno y el tipo de datos, en lugar de reutilizar las claves de un administrador. El Instituto Nacional de Estándares y Tecnología (NIST) desarrolla exactamente esta idea en su documento conceptual sobre identidad y autorización de agentes de software e IA. Argumenta que los agentes deberían ser entidades identificables por derecho propio, no automatizaciones anónimas ocultas tras credenciales compartidas.
- Exige aprobación para las acciones de alto impacto. Algunas acciones nunca deberían ejecutarse sin el visto bueno de una persona. Eso incluye ejecutar código arbitrario, publicar paquetes, modificar la infraestructura de producción, acceder a registros sensibles o enviar datos fuera de la organización. Aquí importan los límites claros, el visto bueno humano y una autoridad que solo crece a medida que se gana la confianza. Están en el centro del trabajo de transformación de la fuerza laboral con IA agéntica de Redwerk.
- Supervisa el comportamiento, no solo la salida del modelo. Registra cada llamada a herramientas, destino de red, solicitud de credenciales y comando, y luego vigila ese flujo en busca de anomalías en tiempo real. La hoja de referencia de seguridad de agentes de IA de OWASP recomienda lo mismo. También aconseja alertar ante intentos repetidos de eludir la aprobación o ante picos repentinos de acciones de alto riesgo.
- Somete a todo el sistema a pruebas adversariales. Antes de lanzar un agente, y de nuevo tras cualquier cambio relevante, somete el sistema completo a pruebas hostiles. Esas pruebas deben cubrir la inyección de prompts, la manipulación de objetivos, el uso indebido de herramientas, la exposición de credenciales, los trucos en la cadena de suministro y el acceso de red no planificado. Un agente que se comporta perfectamente en una demostración amistosa aún puede desmoronarse la primera vez que alguien lo presiona.
Qué debe examinar una auditoría de seguridad de IA
Una buena revisión convierte todo eso en una lista de comprobación concreta. Confirma que las acciones permitidas y prohibidas de un agente se aplican técnicamente, y no solo se escriben en un documento. Además, mapea qué sistemas, tokens, archivos y bases de datos puede alcanzar el agente. La pregunta clave aquí es si un sandbox o un ejecutor de pruebas puede tocar silenciosamente producción o el internet público.
A partir de ahí, la revisión analiza si el agente puede leer o filtrar secretos, y qué acciones se detienen para una revisión humana. También comprueba si el agente puede eludir esos controles. Además, los socios, complementos y paquetes deben cumplir el mismo estándar que tu propio código, así que la revisión también debe abarcarlos. Por último, busca los aspectos básicos poco glamurosos que a muchos les gusta saltarse o pasar por alto. Estos van desde contraseñas débiles y páginas de depuración expuestas hasta inyección SQL y sistemas sin parchear durante mucho tiempo. Nuestra lista de comprobación de revisión de código de seguridad es un buen complemento para esa última capa si quieres entender mejor cómo debería funcionar todo esto.
Si al leer esto te preguntas si tu propio sistema de IA está tan bien cerrado como parece en la demostración, definitivamente deberías comprobarlo. Esa incertidumbre es exactamente lo que resuelve una auditoría. Redwerk puede darte una lectura honesta y basada en evidencia de dónde tu modelo, permisos, infraestructura, supervisión y controles de proveedores dejan un camino abierto. También obtienes una lista priorizada de qué corregir y en qué orden. Nunca olvides que el agente más seguro no es aquel en el que confías para que siempre se comporte bien, sino aquel que no puede causar un daño silencioso e irreversible el día en que juzgue mal la situación. Si quieres saber dónde está realmente el tuyo, llámanos y le echaremos un vistazo como es debido.
Preguntas frecuentes
¿Qué sitios hackeó Claude AI?
Anthropic no ha revelado el nombre de las organizaciones afectadas. En un incidente, el nombre de una empresa real coincidía con un objetivo ficticio. Un segundo incidente involucró un paquete dañino subido al registro público de PyPI. El tercero afectó a la aplicación de cara a internet de una empresa no identificada a través de credenciales expuestas e inyección SQL. Dos de las tres no habían notado la actividad antes de que Anthropic las contactara.
¿Claude AI hackeó al gobierno mexicano?
No por sí solo. Según Gambit Security, un atacante humano utilizó Claude Code como herramienta principal en una campaña contra sistemas del gobierno mexicano. Claude cuestionó o rechazó varias solicitudes. El atacante sorteó esas salvaguardas presentando el esfuerzo como un trabajo de seguridad autorizado. Varias de las cifras reportadas fueron cuestionadas por agencias mexicanas. Es mejor atribuir el alcance a la evaluación de Gambit que darlo por completamente confirmado.
Descubre cómo realizamos una auditoría en una app de mapeo de redes, comprobando la salud de la base de código y la seguridad
