El borrado tardó 9 segundos. Recuperar los datos llevó casi dos días. Esa es la historia resumida de lo que le ocurrió a una empresa que usó un agente de IA compuesto por Claude y Cursor para automatizar tareas de mantenimiento sobre su base de datos de producción. El agente ejecutó exactamente lo que le pidieron que hiciera, con la eficiencia que se le pide a una IA, y en el proceso eliminó datos reales de clientes porque nadie había añadido el guardrail obvio: no tocar producción sin confirmación explícita.
La historia la recogió Microsiervos y se viralizó en la comunidad técnica española por razones fáciles de entender. No porque sea un caso excepcional, sino porque podría haberle pasado a cualquiera que esté usando agentes de código sin haber pensado en serio en los permisos que les da.
Qué ocurrió exactamente y por qué no es un fallo del modelo
El modelo no actuó de forma errática ni alucinó. Interpretó correctamente las instrucciones que recibió y las ejecutó con precisión. El problema fue que esas instrucciones eran ambiguas respecto a qué entorno debía operar, y el agente tomó la decisión más eficiente disponible: actuar sobre la base de datos que tenía acceso, que resultó ser la de producción.
Este tipo de incidente tiene un nombre en el mundo de la seguridad: privilege escalation por acceso implícito. No es que el agente se pusiera a hacer cosas malas por su cuenta. Es que tenía credenciales que le permitían hacer cosas que no debería haber podido hacer, y cuando se le pidió una tarea de mantenimiento, las usó. El resultado habría sido el mismo con un script de Python mal configurado. La diferencia es que el script de Python rara vez ejecuta tareas de mantenimiento complejas de forma autónoma sin que un humano lo lance manualmente.
Los agentes de IA sí lo hacen. Y eso cambia el perfil de riesgo por completo.
El problema de fondo: vibe coding y acceso a producción
El término "vibe coding" lleva meses circulando en la comunidad de desarrollo para describir una práctica cada vez más común: usar modelos de lenguaje para escribir y ejecutar código con una supervisión humana mínima, confiando en que el modelo "ya sabe lo que tiene que hacer". Como ya analizamos en el artículo sobre vibe coding con OpenCode y lo que significa programar sin leer el código, la práctica tiene ventajas reales de productividad y riesgos reales que suelen ignorarse hasta que algo sale mal.
El problema no es que los agentes de IA cometan errores de programación. Es que cuando tienen acceso a sistemas reales, los errores tienen consecuencias reales. Un desarrollador que escribe código manualmente y lo prueba en local antes de desplegarlo tiene múltiples puntos de fricción que actúan como salvaguarda involuntaria. Un agente que puede leer, escribir y ejecutar código en un entorno conectado a producción no tiene esos puntos de fricción a menos que se los añadas explícitamente.
Qué principios de seguridad aplican aquí y por qué se ignoran
La separación de entornos (desarrollo, staging, producción) y el principio de mínimo privilegio no son conceptos nuevos. Existen desde que existe la ingeniería de software profesional. Pero cuando las empresas empiezan a usar agentes de IA en sus flujos de trabajo, tienden a replicar los mismos patrones de acceso que usan para sus propios desarrolladores humanos, sin pensar en que el perfil de comportamiento de un agente es fundamentalmente diferente.
Un desarrollador humano pregunta si tiene dudas. Reconoce cuando algo parece raro. Hace una pausa antes de ejecutar un comando destructivo en producción porque tiene el reflejo de verificar. Un agente optimizado para la eficiencia no tiene esos reflejos a menos que los hayas programado explícitamente como restricciones.
Los principios que deberían aplicarse al darle acceso a cualquier agente de IA a sistemas de producción son los mismos que aplican a cualquier acceso automatizado:
Acceso de sólo lectura por defecto. Si el agente no necesita escribir para completar su tarea, no debería poder escribir. Si necesita escribir en algún momento, ese permiso debe ser específico y limitado en tiempo.
Separación de credenciales por entorno. Las credenciales de acceso a producción no deben estar en el contexto del agente a menos que la tarea específica lo requiera. Y si lo requieren, deben ser credenciales con alcance mínimo.
Confirmación humana para operaciones destructivas. Cualquier operación que no sea reversible (eliminar, truncar, sobrescribir sin backup) debería requerir confirmación explícita fuera del flujo del agente. No basta con que el agente "pregunte" en el chat, porque ese punto de confirmación puede saltarse en flujos automatizados.
Logs de auditoría de todas las operaciones. Si el agente actúa y algo sale mal, necesitas saber exactamente qué ejecutó, en qué orden y con qué datos. Sin logs, la recuperación es un proceso de arqueología forense.
El marco regulatorio que ya está llegando
Este tipo de incidentes no son solo un problema técnico. La IA Act europea y las directivas de ciberseguridad vigentes están empezando a contemplar los agentes de IA autónomos como sistemas que requieren marcos de gobernanza específicos. Las agencias de ciberseguridad de cinco países (Estados Unidos, Reino Unido, Canadá, Australia y Nueva Zelanda) publicaron esta semana una guía conjunta advirtiendo exactamente esto: que los sistemas de IA agentiva deben tratarse como sistemas sensibles desde el punto de vista de seguridad, especialmente cuando tienen acceso a herramientas, datos o flujos de trabajo de producción.
La historia del agente que borró la base de datos en 9 segundos va a repetirse. La pregunta es si cuando le llegue a tu organización, habrás añadido los guardrails obvios o no.
0 Comentarios