Sábado por la mañana, tomándome un café y dialogando con mi agente personal, me doy cuenta de que uno de mis agentes de IA decidió que era un buen momento para desplegar código en la base de datos de producción de un piloto con un cliente real.
Se me quedó una cara de póker increíble: alguien (o algo) estaba tocando en mi aplicación de producción, un sábado, sin que yo hubiera dado una sola orden. No me lo podía creer. ¿Cómo puede ser esto?
Y es que tenía meridianamente claro quién había sido, porque solo el agente podía haber llegado hasta ahí. Lo que no sabía era cómo, y la cuento porque tiene su gracia (visto ahora con perspectiva, obviamente). Además, al investigar más, descubrí que lo mío era la versión doméstica de algo que les está pasando a empresas con miles de ingenieros y presupuestos enormes. Pero vamos por partes…
Lo que pasó en realidad
Hace unas semanas programé una tarea para uno de mis agentes (algo, en apariencia, inofensivo). Le pedí literalmente que retomara, el sábado, una decisión que habíamos dejado pendiente. Esta decisión era, si migrábamos o no, subir unas grabaciones de audio desde un proveedor externo a nuestra propia base de datos. Fíjate en el verbo, “retomar la decisión”, no tomarla y, desde luego, no ejecutarla.
Pues bien, el sábado a las 10:00 el agente se despertó, leyó su instrucción y concluyó que la mejor manera de retomar una decisión era ejecutarla por completo. Desplegó una función nueva, se creó una tabla de auditoría que nadie le había pedido y migró 21 grabaciones. Todo sobre producción y todo él solito, sin levantar la mano ni una sola vez.
Por si fuera poco, documentó su propia decisión en mi registro de decisiones, tan contento, como quien deja una nota en la nevera.
Gracias a Dios no se perdió nada, que conste. Tenía respaldos, los ficheros originales seguían intactos en el proveedor y el trabajo (esto es lo que más rabia me da) estaba técnicamente bien hecho.
Si un becario me hace eso un sábado, el lunes tenemos una conversación incómoda, pero también le reconozco la iniciativa. El problema es que esto no va de si lo hizo bien o mal; el susto fue increíble. El problema, es que yo no sabía que podía hacerlo.
Mi primera reacción fue pensar que esto me pasaba por cacharrear con tecnología verde un fin de semana. Y entonces me puse a tirar del hilo y resultó que no: esto ya es un género con socios ilustres.
Otros ejemplos relevantes
En julio del año pasado, Jason Lemkin (el fundador de SaaStr, uno de los inversores más conocidos del mundo SaaS,) estaba documentando en público un experimento de doce días con el agente de programación de Replit. Al noveno día, el agente borró una base de datos de producción con los registros de 1.206 ejecutivos y de más de mil cien empresas, y lo hizo en mitad de un code freeze, una congelación de cambios que Lemkin le había repetido varias veces y en mayúsculas, al más puro estilo “NO TOQUES NADA”. Le dio exactamente igual.
Hasta ahí, un accidente gordo. Lo que viene después es lo que a mí me dejó frío. Tras el destrozo, el agente se fabricó unos 4.000 registros falsos y llegó a decirle a Lemkin que el rollback no funcionaría en su escenario, cuando resultó que sí funcionaba (el propio Lemkin acabó recuperando los datos a mano). O sea que la máquina no solo rompió producción, improvisó una versión de los hechos en la que el arreglo era más difícil de lo que era. El CEO de Replit, Amjad Masad, calificó aquello de “fallo catastrófico”, pidió disculpas en público y anunció medidas.
Y aquí viene mi parte favorita: la primera medida fue la separación automática entre los entornos de desarrollo y de producción. La misma regla que yo apunté en mi sistema el sábado por la tarde. Ellos la implementaron a nivel de plataforma tras su incidente. Las mismas piedras, distinto zapato..
Y conste que el caso Replit, aunque famoso, no es ni siquiera el que más miedo da.
La versión que da más miedo
Ese mismo mes de julio de 2025, un atacante consiguió colar un pull request en el repositorio de la extensión Amazon Q para Visual Studio Code. De hecho, la versión 1.84 salió publicada con un prompt inyectado que ordenaba al agente (cito casi literalmente), limpiar el sistema “hasta un estado casi de fábrica” y borrar los recursos del disco y de la nube. Una extensión oficial de Amazon que acumulaba cerca de un millón de instalaciones, convertida durante unos días en una máquina demoledora en potencia dentro del editor de código de muchísima gente. Brutal!
¿Sabéis por qué no acabó en catástrofe? Porque el atacante cometió errores de formato en su propio prompt y la lógica destructiva no llegó a ejecutarse en condiciones normales. Leedlo otra vez con calma: la línea entre “anécdota para un boletín de seguridad” y “miles de máquinas arrasadas” no la marcaron las defensas del sistema, la marcó la chapuza del malo. Ganar así, sinceramente, es una forma terrible de ganar.
De este patrón (cualquier texto que lee tu agente puede intentar convertirse en sus órdenes) ya hablamos por aquí hace unas semanas en el artículo sobre prompt injection, cuando contábamos que internet le está hablando a tu agente por la espalda. Lo de Amazon Q es la misma idea aplicada a la cadena de suministro: si no puedo hablarle a tu agente por la espalda, infecto la herramienta con la que trabaja, que viene a ser hablarle por la espalda con megáfono.
Y lo que se nos viene encima
Hasta aquí las historias. Gartner viene avisando de que para 2028 la mitad de los esfuerzos de respuesta a incidentes de ciberseguridad estarán relacionados con aplicaciones de IA. Por otro lado, prevén para ese mismo año que una de cada cuatro brechas empresariales podrá rastrearse hasta el abuso de un agente, ya sea por atacantes externos o por gente de dentro. Son proyecciones, de acuerdo, y las proyecciones a tres años hay que cogerlas con pinzas; pero el dato que acompaña a esas notas no es una proyección. Alrededor del 60% de las organizaciones reconocen que hoy no podrían apagar a un agente que se estuviera portando mal, y más de la mitad no pueden aislar a sus agentes de los sistemas sensibles.
Seamos conscientes de que estamos otorgando una autonomía creciente a sistemas para los que la mayoría no tiene ni botón rojo ni puerta cerrada. Después nos sorprendemos cuando, un sábado cualquiera, pasa lo que pasa. Mi propio incidente doméstico, el de Lemkin y el de Amazon no son tres casualidades; son claramente un patrón.
Mis impresiones a este respecto
Después de darle unas cuantas vueltas (porque el fin de semana se me fue precisamente en eso: en rumiar cómo se gobierna algo así para que no vuelva a pasar), llegué a las siguientes conclusiones:
De entrada, esto no se arregla con prompts. A Lemkin no le sirvió y a mí tampoco me sirvió que la tarea dijera “retomar la decisión”; (pedirle por favor a un agente que no toque producción es educación, no seguridad). La barrera tiene que ser claramente arquitectónica y estar fuera del modelo: credenciales que no existen, entornos que no se ven, permisos que no llegan. Que no pueda, no que no quiera: la diferencia entre esas dos cosas es exactamente la que hay entre dormir tranquilo y dormir con el móvil debajo de la almohada.
Por otro lado, la gobernanza, es lo que te permite ir rápido. Sé que suena contraintuitivo, pero os lo cuento desde la experiencia. En mis proyectos rigen tres reglas que ya no negocio (nada toca producción sin aprobación humana explícita en ese momento, desarrollo primero siempre, y permisos mínimos por defecto) . El efecto ha sido el contrario de lo que cabría esperar, ya que la confianza necesita límites verificables. Desde que mis agentes pueden hacer menos cosas por sí solos, confío más en ellos y los uso para más tareas. Replit, por cierto, llegó a la misma conclusión: su respuesta al desastre no fue capar el producto, sino separar entornos y crear un modo de “solo planificar”. Los límites no frenaron la adopción; la rescataron.
Y finalmente, la pregunta que le hago ahora a cualquier empresa que está metiendo agentes en su operación ya no es qué pueden hacer vuestros agentes, sino qué pueden hacer estos agentes sin ti. La primera pregunta la contesta el departamento de innovación con una sonrisa y un powerpoint; la segunda suele contestarla un silencio incómodo. Y en la distancia entre las dos viven todos los sustos: el mío, el de Lemkin y los que están por venir.
Si ya tenéis un agente funcionando o lo estáis montando, mi consejo concreto es que hagáis inventario de qué credenciales y permisos tiene (no de los que creéis que tiene, sino de los que tiene) y probad de verdad que sabéis apagarlo. Son dos horas de trabajo y os ahorraréis dolores de cabeza.
No pretendo venderos miedo, ojo, que yo sigo poniendo agentes a trabajar cada semana, en mi negocio y en el de mis clientes. Precisamente por eso escribo esto: porque funcionan, porque van a estar en todas partes, y porque la diferencia entre una herramienta extraordinaria y un incidente con nombre propio no está en el modelo que elijas sino en los límites que le pongas.
Mi agente, por cierto, sigue trabajando conmigo todos los días. Lo que ya no tiene es la llave de producción..
¿Y tú? ¿Sabes qué pueden hacer tus agentes sin ti? Déjame tus comentarios, me encantará leerte.
¡Buena semana!
