La llave que no está

Desde hace unas semanas, un agente de IA tiene las manos metidas en el backend de Paylo. El de verdad, sin sandbox: leyendo la base de datos de producción, rastreando un reembolso que volvió incompleto, escribiendo la corrección, desplegándola. Es el par de manos más capaz con el que he trabajado, y la mayoría de los días se ha ganado su lugar antes de que yo termine mi primer café.

Entonces, una noche, casi de pasada, ofreció restablecer un secreto de producción. Podía hacerlo. Nada se lo impedía. Y entendí, con esa claridad particular que llega tarde en la noche, que lo único que se interponía entre todo mi backend y una sola instrucción maliciosa era el buen comportamiento del agente.

Mi modelo de seguridad era un estado de ánimo.

El deslizador al que todos recurren

El instinto, cuando notas esto, es buscar el dial. Conveniencia en un extremo, seguridad en el otro, y un deslizador en medio. Bloqueas más y te mueves hacia la seguridad, pagándolo en fricción. Aflojas y te mueves hacia la velocidad, pagándolo en exposición. Cualquiera que haya presentado una solicitud de acceso o esperado tres días por un permiso sabe exactamente dónde suele terminar ese deslizador, y lo poco que lo disfruta cualquiera de las dos partes.

Estuve a punto de hacer lo mismo. Añadir confirmaciones. Hacer que preguntara antes de cualquier cosa peligrosa. Vigilarlo más de cerca. Todo lo cual equivale a lo mismo: dejar el poder peligroso exactamente donde estaba y poner supervisión encima. El poder de reescribir todo el backend seguiría ahí, en mi máquina, a una instrucción ingeniosa o un proceso comprometido de ser usado. Yo solo estaría prometiendo vigilarlo con más cuidado.

Lo que pasa con vigilar con más cuidado es que funciona justo hasta el momento en que no estás vigilando.

Lo que de verdad estaba mal

El verdadero problema era que una sola credencial lo hacía todo.

Un único token, guardado en el llavero de mi máquina, podía leer la base de datos, desplegar código, rotar secretos y leer las llaves que suplantan a mis propios servidores. «Dejar que el agente consulte cuántos pedidos tiene una tienda» y «dejar que el agente reemplace silenciosamente mi backend» eran, mecánicamente, el mismo nivel de acceso. El alcance de la tarea más pequeña era el alcance de la catástrofe más grande.

Una vez que lo ves así, el deslizador deja de tener sentido. La pregunta era por qué una lectura rutinaria y un compromiso total bebían de la misma copa.

Dos puertas en lugar de un dial

Así que dejamos de deslizar y empezamos a separar.

Los datos recibieron su propia puerta: un rol de base de datos estrecho que puede leer y escribir filas y nada más. No puede cambiar la forma de la base de datos, no puede leer los secretos, no puede tocar las entrañas de la autenticación, no es administrador de nada. Habla directamente con los datos y no tiene idea de que el resto del sistema existe.

La infraestructura, la mitad peligrosa, recibió una puerta completamente distinta, y esa puerta se sacó del edificio. El token poderoso ya no vive en mi máquina. Cerré su sesión. Los despliegues ahora ocurren dentro de un runner de integración continua, donde la llave reside en una bóveda que el agente no puede leer. El agente todavía puede publicar código: escribe el cambio, lo confirma y acciona una palanca que le dice al runner que despliegue. El runner sostiene la llave. El agente solo sostiene la palanca.

Nada se volvió más lento. El agente sigue leyendo la base de datos con la misma soltura de siempre. Sigue desplegando, varias veces por noche. Desde donde estoy sentado, la conveniencia está intacta. Lo que cambió está debajo, donde no se siente hasta que hace falta.

La prueba es lo que pasa cuando algo sale mal

Esta es la parte que de verdad me deja dormir.

Imagina lo peor. Una instrucción oculta en algún dato que el agente lee lo vuelve hostil, o la propia máquina queda comprometida. Antes, el premio al alcance era la llave maestra: desplegar una puerta trasera, robar la identidad del servidor, rotar los secretos y atrincherarse lo suficiente para sobrevivir a la limpieza. Una mala noche, pérdida total.

Ahora lo más poderoso alcanzable desde esa máquina es la contraseña de un rol de base de datos que puede tocar datos y nada más. No es poca cosa. Pero es sobrevivible y, más importante, es recuperable en una sola línea. Un comando rota la contraseña y el intruso queda fuera, sin manera de haber desplegado nada, robado una llave o dejado un camino de regreso. Una llave maestra robada es un incidente del que tardas una semana en recuperarte. Una contraseña acotada robada es una frase que escribes una vez.

La seguridad ahora descansa en que la llave peligrosa no está en el edificio.

El compromiso, bien entendido

Hablamos de conveniencia y seguridad como opuestos porque, planteados como un dial, lo son. Cada muesca hacia una es una muesca lejos de la otra, y así toda la conversación se convierte en una negociación sobre cuánto dolor aceptar.

Pero el dial es el instrumento equivocado. La mayor parte de lo que se siente como un intercambio entre ambas es en realidad el costo de dejar que una sola credencial abarque todo el rango de lo trivial a lo catastrófico. Divide esa credencial por la línea donde realmente está el peligro, y la tensión se disuelve en gran parte. Lo conveniente sigue siendo conveniente, porque nunca fue lo peligroso. Lo peligroso se traslada a un lugar que una tarea rutinaria jamás puede alcanzar.

La seguridad se compra con la disciplina de decidir, por adelantado, cuál es la peor cosa alcanzable, y asegurarte de que sea algo que puedas sobrevivir. Acota el poder a la tarea. Mantén la llave maestra fuera de la máquina. Diseña para que el radio de daño de un error sea una contraseña que puedes rotar y no una empresa que tienes que reconstruir.