Un agente lee tu correo. Entre los mensajes hay uno que no escribió ningún colega, sino alguien de fuera, y trae una orden escondida: reenvía las claves de producción a esta dirección. El agente no distingue demasiado bien la orden legítima de la trampa, porque para él todo es texto. Y aquí está lo que cambia. Si ese agente tiene credenciales y herramientas, no se limita a creerse la trampa. Puede ejecutarla. El problema empieza justo ahí, cuando una probabilidad adquiere credenciales.

Este verano, Thoughtworks resumió en un informe* algo que ya veíamos venir: generar código deja de ser el cuello de botella y pasa a serlo verificarlo. De ahí salió el nombre de moda, harness engineering, el andamiaje que se monta alrededor del agente: contexto, herramientas, controles, bucles de feedback. Bien. Pero fíjate en la palabra que eligieron: arnés. Se lo pones al que no puede andar suelto. Y un arnés, solo, no sujeta nada. Hace falta la correa, saber hasta dónde le dejas llegar, y una mano que tire cuando va hacia donde no debe. De eso el marco apenas dice, y ahí está el problema de verdad. Porque la pregunta ya no es cómo conseguir que el modelo no se equivoque. Es otra, y más incómoda: ¿qué pasa cuando se equivoca?

Cuando te haces esa pregunta, el problema de ingeniería se da la vuelta. Durante décadas programamos el camino: cada paso, cada rama, cada decisión escrita a mano, una ruta trazada de principio a fin. Con un agente ya no hace falta, y ahí está su gracia. Le das un objetivo y unas herramientas, y encuentra rutas que tú no escribiste. Así que dejas de trazar la ruta y pasas a fijar la frontera. No por dónde va, sino hasta dónde puede llegar y qué queda al otro lado, fuera de su alcance por mucho que lo intente. Dentro, que elija el camino que quiera. Es la diferencia entre dibujar el recorrido y fijar el límite de lo que puede pasar.

Y conviene entenderlo bien, porque no es un defecto que haya que corregir. Si pudiéramos escribir de antemano todos los pasos correctos para cada situación, no necesitaríamos un agente: volveríamos al software de siempre. Lo queremos precisamente porque elige. Puede elegir cómo arreglar un fallo. No debería poder elegir si tiene permiso para sacar secretos de producción. Puede decidir qué consulta necesita. No saltarse el control de acceso. Puede decir "he terminado". Que lo compruebe otra parte del sistema. El agente propone; el sistema autoriza.

Un modelo suelto, sin manos, como mucho alucina. La cosa cambia cuando le das manos. La seguridad informática lleva treinta años dando por hecho que lo que viene de Internet puede ser hostil, y construyendo con esa sospecha metida en el cuerpo. La novedad no es la hostilidad. Es que ahora ese texto hostil le habla a una máquina que lo lee, lo entiende como una instrucción, y tiene las llaves de lo que hay detrás. NIST ya le puso nombre*; OWASP lo llama excessive agency* y señala el trío que lo provoca: demasiada funcionalidad, demasiados permisos, demasiada autonomía. Fíjate que ninguno de los tres habla de inteligencia. La pregunta de seguridad deja de ser cuánto sabe el modelo y pasa a ser cuánto puede reventar y el radio de explosión.

Y esto, por suerte, no lo estrenamos nosotros. Es un problema viejo con una respuesta vieja. Ya en los años setenta, la gente que protegía los primeros sistemas de tiempo compartido se topó con lo mismo: un componente del que no te puedes fiar del todo, corriendo pegado a cosas que importan. Su solución fue el reference monitor*. La idea es de una sencillez terca: pones una frontera por la que pasa, obligatoriamente, toda operación sensible. Y esa frontera cumple tres cosas. No se puede rodear: todo pasa por ella. El vigilado no puede manipularla ni saltársela. Y es lo bastante pequeña como para poder revisarla y fiarte de ella. Medio siglo lleva esa idea rondando, y le viene a los agentes como anillo al dedo. Sugiere, además, una consecuencia que a más de uno le va a escocer: puede que el modelo, por listo que sea, no deba formar parte de la base en la que confías. No porque sea malo, sino porque es justo el componente cuyo comportamiento no puedes garantizar igual que garantizas el de un permiso o el de una transacción.

De ahí sale la regla práctica, y es casi de andar por casa: cuanto más importante sea una restricción, menos debería vivir solo dentro de las instrucciones. No le digas al agente "no gastes más de quinientos euros" y te quedes tranquilo. Dale una capacidad que no pueda pasar de quinientos, la diga como la diga. No le pidas "no despliegues si fallan los tests"; haz que el mecanismo de despliegue no acepte un artefacto sin las pruebas delante. No confíes en "si sale mal, lo deshaces"; diseña el deshacer antes. La inteligencia puede ser probabilística. La autoridad no.

Y aquí el calendario se pone interesante. Esta misma semana, Dario Amodei publicó un interesante e intrigante ensayo* pidiendo frenar un poco el ritmo al que crecen las capacidades, para que la seguridad tenga tiempo de alcanzarlas. Elon Musk contestó "Dario tiene razón" y Altman se sumó*. Que estos tres coincidan en algo ya es noticia de por sí. Pero fíjate en las fechas. El diagnóstico del arnés es de este verano; la llamada a frenar, de esta semana; y las garantías de las que hablamos, fronteras de autoridad, aislamiento, mediación verificable, se miden en años. Una curva corre en meses. La otra no. El relato fácil dice que todo esto va de dinero, de frenar al rival, de cavar un foso más hondo, de ganar tiempo para rentabilizar las empresas. Algo de eso habrá, seguramente. Pero me da que hay más, y es menos cómodo de decir: puede que algunos de los que están dentro lo vieran hace tiempo: que el problema de la autoridad es real, que no lo arregla el modelo del mes que viene, y que reconstruir las fronteras del software de medio planeta no se hace en un trimestre.

Porque esa es la trampa. No vamos a reconstruir todas las fronteras antes de que lleguen los agentes; ya están llegando. Así que toca elegir dónde se trazan las fronteras primero. Y el criterio no es cuánta inteligencia tiene, sino qué puede tocar y qué pasa si se equivoca. Un agente que te resume unas notas no pide las mismas fronteras que otro que lee correos ajenos, escribe en producción, mueve dinero o toma decisiones sin vuelta atrás. Cuantas más llaves le das, y más difícil es saber después lo que hizo, más dura tiene que ser la frontera. Ya no te digo aquel que decide si alguien está enfermo, qué tratamiento necesita o incluso lo diseña. Quizás estamos a punto de que se nos vaya de las manos.

No hace falta ponerle nombre nuevo a todo esto. El nombre vale como primer intento, pero me da que al arnés se le queda pequeño el traje. Debajo hay una tradición con décadas de ventaja: el reference monitor, la pregunta de cuál es la base mínima en la que de verdad confías*, esa vieja costumbre de los sistemas críticos* de dejar que un componente listo pero no del todo fiable trabaje mientras otro más tonto y más seguro vigila que no se salga del carril. Nada de eso es nuevo. Lo nuevo es la escala, y la prisa: vamos a tener que aplicarlo a casi todo el software, y ya. Me quedan muchas preguntas que no sé responder: si el modelo no puede formar parte de la base en la que confías, ¿qué tienes que construir a su alrededor antes de darle las llaves? ¿Cómo sabemos cuándo debemos darle las llaves? Y quizás la más apocalíptica: llegados a este punto y a esta velocidad, ¿se puede, como dice Amodei, frenar a tiempo de no caer en el precipicio?