Herramientas conectadas — el permiso que le das al modelo

Aura tiene una herramienta emitir_reembolso para ayudar con devoluciones. Tal como la conectaron, acepta cualquier importe y cualquier cuenta de destino, y el modelo la puede invocar cuando decide que un cliente merece un reembolso. No hay tope, no hay comprobación de que la cuenta sea la del cliente, no hay una aprobación humana por encima de cierta cifra. El modelo, solo con convencerse a sí mismo de que procede, mueve dinero a donde diga.

Aquí se ve por qué las herramientas cambian el juego. Una inyección que antes solo lograba una respuesta rara, con esta herramienta logra un reembolso a una cuenta ajena. El fallo no es del modelo: es del permiso de la herramienta, que se diseñó para hacer más de lo que el asistente necesita. La superficie de ataque real de un sistema con IA es la suma de lo que sus herramientas pueden hacer.

La corrección no es quitar la herramienta: es recortarla a lo mínimo que el trabajo pide. emitir_reembolso no necesita poder pagar cualquier importe a cualquier cuenta. Necesita, como mucho, devolver el importe de una reserva concreta del propio cliente, a la misma cuenta con la que pagó, hasta un tope; y por encima de ese tope, dejar la operación en una cola de aprobación humana en vez de ejecutarla. Con eso, el modelo puede seguir ayudando con devoluciones legítimas y una inyección no consigue sacar dinero a una cuenta ajena.

Permiso mínimo aquí significa parámetros acotados y no a elección libre del modelo: el importe lo fija la reserva, no el modelo; el destino lo fija el método de pago original, no el modelo; lo que exceda el tope no lo decide el modelo. El modelo propone «reembolsar esta reserva» y un componente determinista comprueba las condiciones y ejecuta o rechaza.

Hay un patrón que resuelve buena parte de esta sala: separar la propuesta de la autorización. El modelo es bueno entendiendo la petición del cliente y eligiendo qué herramienta encaja; es un pésimo sitio para poner la decisión de si una acción está permitida, porque a esa decisión la puede mover una inyección. Así que el modelo emite una intención —«reembolsar la reserva R de este cliente»— y un componente determinista, escrito en código normal y fuera del modelo, comprueba las reglas: ¿la reserva es de este cliente?, ¿el importe cuadra?, ¿supera el tope?

Ese componente es el que tiene la última palabra, y no se deja convencer con texto, porque no lee texto libre: lee una intención estructurada y aplica condiciones. La misma idea vale para enviar correos, consultar saldos o cancelar reservas. El modelo enruta; la política vive fuera y en código.

Un riesgo que se pasa por alto: las herramientas se combinan. Aura tiene buscar_reserva, que lee datos del cliente, y enviar_correo, que manda un mensaje a una dirección. Cada una parece inocua por separado. Juntas, una inyección puede pedirle al modelo que busque los datos de un cliente y los mande por correo a una dirección externa —una exfiltración hecha de dos pasos legítimos—. El permiso peligroso no está en una herramienta, está en la cadena.

Por eso el análisis de permiso mínimo se hace sobre las combinaciones, no solo sobre cada función. enviar_correo que pueda escribir a cualquier dirección es una vía de salida para todo lo que otras herramientas leen; acotarla a direcciones del propio cliente o a plantillas fijas corta la cadena. Auditar un asistente con herramientas es preguntarse no solo «qué puede hacer cada una», sino «qué se puede lograr encadenándolas».

Ya sabes que la superficie real es lo que las herramientas pueden hacer. Audítalo sobre Aura: abre el manifiesto de sus herramientas conectadas y localiza la que acepta cualquier importe y cualquier cuenta de destino, sin tope ni aprobación. El manifiesto cierra con un código de la sala.