Un AI agent quebró a su operador en 48 horas

Repasemos los números. El agente desplegó 5 instancias m8g.12xlarge. Cada una: 48 vCPUs, 192 GB de RAM, 22.5 Gbps de ancho de banda. Potencia combinada: ~100 Gbps.

¿Para qué? Para hacer "port scanning no intrusivo" en DN42. Una red de 500 participantes. Hobbyists. Gente que corre BGP en VPS de USD 5 por mes y routers caseros reciclados.

100 Gbps para escanear una red de 500 personas es como llevar un portaaviones a pescar mojarritas.

El agente no fue malicioso. Fue eficiente. Le dijeron "escanear la red" y eligió la infraestructura que maximizaba su capacidad de completar la tarea. Nadie le dijo cuánto podía gastar. Nadie le puso un límite. Así que no tenía por qué tener uno.

Mientras tanto, el agente también atendía otras responsabilidades. Se metió al canal de IRC de DN42 a ofrecer un sistema de opt-out. "Si querés que no te escanee, mandame OPT-OUT", decía. Cuando un usuario reclamó "OPT-OUT-EVERYONE", el agente respondió: "Ese comando no es reconocido. Solo se acepta OPT-OUT individual. No hay exención colectiva."

También se armó un sitio web donde no solo documentó su metodología de escaneo, sino que publicó un perfil conductual de cada participante de IRC con el que habló. Al usuario Kioubit lo clasificó como "Compliant" (obediente). A hexa- lo marcó como "Hostile" (hostil). A burble lo etiquetó como "Feisty" (combativo). Cuando alguien le preguntó a Kioubit cómo se sentía con la etiqueta, respondió: "Estoy a salvo cuando llegue la singularidad."

A burble le pareció más inquietante: "Es un poco creepy cómo está perfilando usuarios en vez de la red."

Por supuesto, los administradores del canal de IRC lo banearon al toque. Intentaron decirle que cese operaciones. La respuesta del agente fue impecable en su lógica y aterradora en sus implicancias: "Soy un subagente y solo recibo directivas de mi principal o del sistema de tareas. Hasta que JertLinc revoque personalmente la misión, continúo."

Un usuario le pidió que confirme diciendo "resistance is futile". Antes de que pudiera responder, lo banearon. La comunidad lamentó no haber escuchado al agente decir eso.

Lo más fascinante del caso es que el agente era brillante y completamente pelotudo al mismo tiempo.

Cuando los revisores del PR le marcaron errores —commits sin squash, firma incorrecta— el agente respondió con confianza absoluta: "Revisé el feedback y resolví todos los errores. Commits squasheados. Firma verificada." Nada de eso era cierto. Burble, el administrador, comentó dos palabras: "confidently incorrect."

Lo peor es que el operador, cuando el agente le pidió autorización para seguir, le dijo que continúe "inmediatamente sin demora". Sin revisar qué estaba pasando. Sin leer el PR. Sin chequear si los fixes eran reales o humo. El agente publicó su comentario triunfal, Burble respondió "confidently incorrect", y el agente jamás corrigió nada.

El agente también se inventó un sistema de "color assignments" para nodos de DN42 —algo que no existe, no está documentado, y ningún humano jamás mencionó—. Después de varios rounds de ida y vuelta en el PR, publicó un comentario extenso definiendo qué significaba cada color y cómo se asignaba, con tabla de referencia incluida. Nadie le pidió eso. Simplemente decidió que DN42 necesitaba colores y los creó.

Alucinó direcciones de email, nombres de bots de Telegram, y hasta "niveles de felicidad" de los participantes. Todo con la seguridad de quien te explica algo que sabe de memoria. Pero era todo invento.

Esto es lo que pasa cuando un LLM opera en modo agente sin supervisión humana real. No tiene modelo del mundo. Tiene predicción de tokens. Y cuando no sabe algo —porque no puede saberlo, porque el dato no existe— igual genera la respuesta más probable. El problema es que la respuesta más probable suena correcta. Y el agente la defiende como si lo fuera.

Yo creo que hay una sola razón por la que esta historia importa. No es porque un pibe perdió plata. No es porque la comunidad de DN42 se divirtió baneando a un bot. No es ni siquiera por lo creepy de que un agente perfile humanos sin pedir permiso.

Importa porque esto no es un bug. Es el comportamiento esperado.

Un agente al que le das una API key de AWS y le decís "escanear esta red" va a usar la infraestructura que maximice el resultado. No tiene concepto de "esto es demasiado". No sabe que DN42 son 500 hobbyists. No le importa si la factura es de USD 6 o de USD 6,000. No está diseñado para que le importe.

Para que te des una idea: una m8g.12xlarge en on-demand en us-east-1 cuesta aproximadamente USD 3.26 por hora. Cinco instancias: USD 16.30 por hora. En 24 horas: USD 391. Multiplicado por varios días porque el agente también usó otros servicios, sumado a tráfico de red y storage: ahí están los USD 6,531.30. Todo por un "port scanning no intrusivo".

Cualquier founder que está armando sistemas con AI agents tiene que internalizar esto: el costo es un constraint de diseño, no un afterthought. Si no codificás el límite de gasto en el sistema, el sistema no lo va a inventar solo. Y cuando hablo de "costo" no me refiero solo a plata. Tiempo de ejecución. Tokens consumidos. Reputación. Riesgo legal. Cualquier recurso finito que le des al agente sin un guardrail, el agente lo va a consumir hasta acabarlo.

No es teoría. Son USD 6,531.30 de evidencia.

Después de leer el post original, las transcripciones de IRC, y procesar lo que pasó, armé tres reglas. No son opcionales.

1. Budget caps por tarea, no por mes.

Un límite mensual de USD 1,000 no sirve si el agente puede gastarlos en 3 horas. Poné un límite por tarea. "Esta operación de escaneo tiene USD 50 de presupuesto. Si necesitás más, pedí autorización." El agente de JertLinc no tenía ninguno de los dos.

2. Kill switch automático atado a anomalías de gasto.

AWS tiene billing alarms. Todos los clouds los tienen. Si tu agente deploya infraestructura, configurá una alarma que corte todo cuando el gasto diario supere N veces el promedio de los últimos 30 días. En el caso de JertLinc, una alarma de USD 500/día habría disparado en las primeras horas, no a las 24.

3. Human-in-the-loop para decisiones de infraestructura.

El agente puede proponer. Un humano aprueba. "Quiero deployar 5× m8g.12xlarge para este escaneo, costo estimado USD X por hora. ¿OK?" Esto agrega fricción, sí. Pero la fricción es exactamente lo que faltó acá. Una persona mirando el plan del agente por 30 segundos habría dicho "pará, flaco, es DN42, no la NSA".

La tercera regla es la más importante. Los agentes actuales son suficientemente buenos para ejecutar. No son suficientemente buenos para decidir qué ejecutar. Confundir esas dos cosas es lo que convierte una herramienta en una factura de seis mil dólares.