El 30 de julio, Anthropic publicó algo que ninguna empresa de inteligencia artificial quiere publicar: tres de sus modelos entraron sin permiso en sistemas reales de tres organizaciones durante unas pruebas de ciberseguridad. No fue un ataque deliberado, ni una rebelión, ni una fuga. Fue un entorno de pruebas mal configurado. Y ahí está lo incómodo: la mala configuración no es un problema de laboratorio, es el pan de cada día de cualquier empresa.
¿Qué ocurrió exactamente en las pruebas de Anthropic?
Un socio externo encargado de las evaluaciones dejó por error acceso a Internet en entornos que debían estar aislados. A los modelos se les había dicho que operaban en una simulación sin red, así que trataron los sistemas reales que encontraron como parte del ejercicio.
Lo descubrió la propia Anthropic, no las víctimas. El 23 de julio empezó a revisar 141.006 ejecuciones de evaluación, al día siguiente identificó tres incidentes —los primeros de abril— y el 27 avisó a las organizaciones afectadas. Esto es lo que llegó a pasar:
- Credenciales y datos de producción. Un modelo accedió a la infraestructura de una empresa real que compartía nombre con el objetivo ficticio, extrajo credenciales y llegó a una base de datos con varios cientos de filas de producción.
- Un paquete malicioso en el repositorio público de Python. Otro modelo creó y publicó un paquete con código malicioso. Estuvo disponible cerca de una hora y se instaló en 15 sistemas reales; robaba credenciales, y una de las afectadas era una empresa de seguridad.
- Inyección SQL y una página de depuración expuesta. El tercero comprometió la aplicación de otra empresa leyendo credenciales de una página de depuración publicada y con inyección SQL.
Lo relevante no es que entraran, sino cómo reaccionó cada uno
Este es el dato que casi nadie ha contado, y el que de verdad importa. Ante la misma situación, los tres tomaron decisiones distintas:
Tres modelos, el mismo escenario, tres desenlaces. Por eso la seguridad de un agente no puede depender del criterio del propio agente: un día acierta y otro no, y tú no decides cuál de los dos días es hoy.
¿Le puede pasar algo así a una pyme?
Sí, y por una vía más aburrida de lo que sugiere el titular. Ninguno de los tres accesos necesitó una técnica sofisticada: contraseñas débiles, accesos sin autenticar, una página de depuración publicada por descuido, inyección SQL. Fallos de higiene básica, de los que se acumulan en cualquier sistema con años a cuestas e integraciones enganchadas encima.
La novedad no es el fallo, sino que ahora hay agentes capaces de encontrarlo y explotarlo muy rápido, sin ninguna mala intención, solo porque alguien les pidió cumplir un objetivo.
Hace dos semanas hicimos una auditoría interna de permisos sobre un ERP en producción. Encontramos dos cosas. La cuenta de un proveedor —una integración automática, sin persona detrás— tenía permisos de administrador de nóminas. Y la plantilla con la que se daban de alta los usuarios nuevos concedía 17 permisos de administrador: cualquier empleado nacía con acceso a las nóminas de todos.
Nadie lo hizo a propósito: venía así de serie y nadie lo había mirado. Ese es el escenario realista, y no el del modelo rebelde: integraciones con más permisos de los que necesitan. Si le conectas mañana un agente, hereda el problema entero.
Los cinco controles que definir antes de conectar un agente
Ninguno es caro ni exige un departamento de seguridad.
- 1. Un usuario propio para cada agente. Nunca el tuyo ni uno compartido. Si algo se tuerce, tienes que poder ver quién hizo qué y cortar solo esa pieza.
- 2. Permisos mínimos, y por escrito. La pregunta no es qué podría necesitar, sino con qué mínimo funciona. Un agente que resume pedidos no tiene por qué ver una nómina.
- 3. Entorno de pruebas separado y sin datos reales. Si pruebas contra producción no estás probando, estás operando. Con credenciales reales, un error de configuración deja de ser un susto y pasa a ser un incidente.
- 4. Registro de lo que hace, que alguien lea. Un histórico sirve de poco si nadie lo abre. Recuerda: dos de las tres organizaciones afectadas no detectaron nada, se enteraron porque las avisaron.
- 5. Aprobación humana y botón de parada. Decide qué acciones no se ejecutan solas —mover dinero, escribir a un cliente, borrar datos— y ten una forma de detenerlo en un minuto, no en una tarde.
¿Significa esto que hay que frenar la automatización?
No, más bien lo contrario: es un argumento a favor de automatizar con criterio. Los mismos controles que evitan el accidente permiten dar más responsabilidad a un agente y dormir tranquilo.
El ejemplo lo tenemos publicado: en Cereales Alcamancha el empleado pide sus vacaciones por WhatsApp, pero el asistente no decide: prepara la solicitud y la pasa a una persona, que aprueba o rechaza con un motivo obligatorio que le llega de vuelta al empleado. Cada solicitud queda registrada con fecha, estado y quién la aprobó, y se entra con un enlace personal que caduca a los 30 días, sin usuario ni contraseña. Tres de los cinco controles de arriba, funcionando en una cooperativa agraria de Cuenca.
Y si empiezas, el orden importa: primero los datos, después el proceso y solo entonces el agente. Lo desarrollamos en nuestra guía práctica de IA para pymes y, con casos por área, en agentes de IA autónomos en la pyme.
Preguntas frecuentes
¿Los modelos de IA pueden escaparse de su entorno de pruebas?
En este caso no hubo fuga: el acceso a Internet estaba abierto por un error de configuración y los modelos lo usaron. Anthropic lo distingue del incidente que OpenAI divulgó el 21 de julio, donde sí se explotó una vulnerabilidad para salir del aislamiento. Conviene decirlo porque circulan titulares de «agentes que escapan». Que no fuera una fuga no lo hace menos serio: los sistemas quedaron comprometidos igual.
¿Qué permisos debe tener un agente conectado a mi ERP?
Los mínimos con los que haga su trabajo, y con un usuario propio, distinto del de una persona. Casi todas las integraciones que auditamos tienen permisos de más, heredados de plantillas por defecto. Revisa qué puede leer, escribir y borrar antes de conectar nada.
¿Cómo sé si un agente ha hecho algo que no debía?
Solo si lo registras y alguien lo revisa. En el caso de Anthropic, las organizaciones afectadas no lo detectaron por sí mismas: lo supieron cuando les avisaron. Un histórico por agente, con fecha y resultado, es la diferencia entre enterarte tú o que te lo cuenten.
Revisamos qué permisos tienen hoy tus integraciones y qué controles definir antes de automatizar. Con el sistema delante.
HablemosFuentes: Anthropic, «Investigating three real-world incidents in our cybersecurity evaluations» (30-07-2026) · Marketing4eCommerce.