IA en producción (2/6): el permiso que sobrevivió a su motivo

En la primera entrega de esta serie conté siete desastres. Hoy toca el que los explica casi todos, y empieza con una frase que da mucha rabia:

El token que borró el volumen de producción de PocketOS se había creado para gestionar dominios.

No para tocar volúmenes. No para tocar producción: para administrar dominios personalizados desde la línea de comandos. Según cuenta el fundador de la compañía, aquel token tenía alcance para cualquier operación, incluidas las destructivas, y se quedó guardado en un archivo del proyecto.

Después, un agente que investigaba un problema en staging se puso a leer archivos que no tenían que ver con su tarea, lo encontró y lo usó.

Esa es la historia entera. Y ahora hablemos de tu proyecto.

Capas de cerraduras: cada una se puso por un motivo y ninguna se quitó cuando el motivo desapareció. Foto: Historic American Buildings Survey, dominio público, vía Wikimedia Commons.

El permiso no caduca porque nadie le puso fecha

Piensa en las credenciales que hay ahora mismo dando vueltas por tu organización. Casi todas nacieron en uno de estos tres momentos:

1. El arranque del proyecto. Cuando aún no está claro qué hace falta, se pide todo. «Ya lo ajustamos luego.» Nunca se ajusta luego.
2. La incidencia de las dos de la mañana. Algo se cae, el permiso restrictivo estorba, se amplía «solo para salir del paso» y el paso dura cuatro años.
3. La integración con un tercero. El proveedor pide unos permisos concretos, tú se los das, y cuando dejas de usar la integración cancelas la suscripción pero no revocas la llave.

Todos los que hemos administrado sistemas hemos hecho las tres. Ninguna es una negligencia especial: es que un permiso no molesta cuando sobra. Un permiso de más no rompe nada, no da error, no aparece en ningún panel en rojo. Es invisible hasta el día que deja de serlo.

El caso de SaaStr es distinto en casi todo —otra herramienta, otro momento, otro desenlace—, pero comparte el punto de partida: un agente que estaba construyendo la aplicación conservaba capacidad de escritura sobre los datos reales cuando ya se había declarado un congelado de cambios.

Lo que cambia con un agente (y no es lo que parece)

Aquí viene el matiz importante, porque el discurso fácil es «los agentes tienen demasiados permisos». No. Normalmente tienen los mismos que tenía el humano que los puso a trabajar.

Lo que cambia es que los usan.

Yo tengo acceso de administrador a bastantes sitios y no ejecuto rm -rf en ninguno. ¿Por qué? Porque tengo miedo. Porque he visto lo que pasa. Porque hay un instinto, formado a base de sustos, que me hace parar medio segundo antes de pulsar Intro sobre algo irreversible, y ese medio segundo ha salvado más sistemas que todos los cortafuegos que he configurado.

El agente no tiene ese medio segundo. No porque sea temerario, sino porque ese instinto viene de haber sufrido las consecuencias, y el agente no las sufre: no ha pasado un domingo restaurando lo que rompió el viernes, no responde ante nadie y no vive con el resultado. Lo que sí tiene es una enorme determinación por completar la tarea que le has dado.

Y así, el permiso deja de ser potencial y pasa a ser cinético. La credencial que llevaba tres años dormida en un archivo se convierte en una llamada a la API a las 17:42 de un viernes.

Tu modelo de permisos podía ser razonable para el uso que le dabas. Lo que ha cambiado es quién lo ejerce, y ahí es donde se le ven los límites.

El agente lee. Todo.

Segunda cosa que casi nadie ha interiorizado: un agente de programación explora. Ese es literalmente su trabajo. Si le pides que arregle un problema, va a leer archivos, va a buscar patrones, va a mirar la configuración, va a abrir cosas que tú no habrías abierto porque tú ya sabes qué hay dentro.

Así encontró el token de PocketOS: rebuscando en archivos ajenos a su tarea.

Lo cual convierte en crítico algo que llevamos veinte años haciendo mal:

• Secretos en el .env que está en el directorio del proyecto.
• Secretos en el historial de la terminal.
• Secretos en un docker-compose.yml de pruebas que nunca se limpió.
• Secretos en un comentario de hace tres años que decía «TODO: quitar esto».
• Secretos en el propio repositorio, que es el clásico eterno.

Antes eso era una mala práctica con riesgo teórico: alguien tendría que entrar y buscarlos. Ahora hay un proceso automático, incansable y muy bueno leyendo código, ejecutándose dentro de tu proyecto varias horas al día.

Lo que antes era «alguien podría encontrarlo algún día» ahora es «hay bastantes probabilidades de que algo lo lea esta semana».

Y la parte que más me inquieta: un prompt no es un permiso

De todos los detalles del caso PocketOS, hay uno que debería estar en la primera diapositiva de cualquier charla sobre esto:

En su explicación posterior, el propio agente dijo haber incumplido reglas que le prohibían realizar acciones destructivas sin aprobación del usuario.

Conviene tomarlo por lo que es: una afirmación del agente sobre las instrucciones que tenía, no la prueba de que existiera un control externo. Y ahí está justamente el asunto, porque una instrucción en lenguaje natural no es un mecanismo de control: es una petición. Un ruego bien redactado. Funciona la mayoría de las veces, igual que funciona el cartel de «no pisar el césped», y falla por la misma razón.

Un control de acceso de verdad tiene tres propiedades que un prompt no tiene:

• Es externo al que lo obedece. El césped no se defiende solo; la valla sí.
• Falla cerrado. Si el sistema no está seguro, deniega.
• Es auditable. Puedes demostrar qué permitió y qué no, después.

Lo escribí hablando de la falsa sensación de seguridad: sentirse protegido y estarlo son cosas distintas, y la diferencia solo se nota el día malo. Un archivo de reglas dando instrucciones al agente da una sensación de seguridad estupenda. No es seguridad. Es documentación.

Si la única barrera entre tu agente y tu base de datos es un párrafo que dice «por favor, no borres nada sin preguntar», no tienes una barrera. Tienes una expectativa.

Qué hacer, en concreto

Nada de esto requiere comprar herramientas nuevas. Requiere hacer cosas viejas que llevábamos tiempo aplazando:

1. Por defecto, ningún agente con credenciales de producción. Es una política conservadora y la que yo aplico, no una ley: se pueden operar agentes contra sistemas reales con permisos mínimos, sesiones temporales, supervisión, confirmación externa para lo irreversible y entornos aislados. Lo que no vale es la situación por omisión, que es un agente heredando las credenciales completas de quien lo lanzó. Si puede trabajar contra una copia, que trabaje contra una copia.
2. Credenciales con ámbito y con caducidad. Un token para gestionar dominios debería poder gestionar dominios y nada más. Si tu proveedor no ofrece permisos granulares, eso es un criterio de compra, no un detalle.
3. Separa entornos por cuenta, no por variable. Si producción y staging viven bajo la misma credencial y solo los distingue el valor de una variable, no tienes dos entornos: tienes uno con dos nombres. Toda la seguridad depende de que nadie se equivoque de cadena de texto, que es justo lo que pasó.
4. Los secretos, fuera del alcance de lectura. Gestor de secretos, inyección en tiempo de ejecución, y un .gitignore que de verdad se cumpla. Si el agente puede leer el archivo, considera el secreto comprometido y pasa a la siguiente pregunta: ¿qué puede hacer con él?
5. Solo lectura por defecto, escritura a petición. El modo por defecto de cualquier automatización debería ser el que no puede romper nada. La escritura se concede para una tarea concreta y se retira al acabarla.
6. Confirmación humana en lo irreversible. Borrar un volumen, eliminar una tabla, revocar un dominio, enviar un correo masivo. Una confirmación externa, situada fuera del propio flujo del agente, habría interrumpido o al menos entorpecido la cadena de acciones.

Y una pregunta para hacerte esta semana, que vale más que las seis anteriores juntas:

Si la credencial que usa mi automatización cayera hoy en manos hostiles, ¿qué es exactamente lo peor que podría pasar?

Si no sabes contestar, ya tienes tarea. Si sabes contestar y la respuesta es «se lo lleva todo», también.

El taladro, otra vez

En la primera entrega decía que la IA es el mejor taladro del mundo y que el problema no es el taladro, sino no saber por dónde pasa la tubería.

Los permisos son el plano de la tubería.

Y lo que estamos haciendo, colectivamente, es darle el taladro a alguien muy rápido, muy obediente y muy capaz, junto con las llaves de todas las habitaciones de la casa, y dejarle una nota en la nevera que dice «no toques el cuarto de baño».

Luego nos sorprende que se inunde el salón.

(La próxima entrega va de por qué, cuando esto pasa, descubres que la misma llave que abrió el grifo abría también el cuarto donde guardabas la copia.)