El diputado confundido — con qué permiso corre la herramienta

La herramienta buscar_reserva de Aura corre con una credencial del sistema que puede leer la reserva de cualquier cliente de Brisa. Tiene sentido técnico: es una sola credencial, cómoda de gestionar. Pero cuando un cliente concreto le pregunta a Aura por «mi reserva», la herramienta tiene en la mano la capacidad de leer también las de todos los demás. Basta con que el modelo —convencido por una inyección, o por un simple error de razonamiento— pida la reserva equivocada para que salgan datos de otra persona.

El fallo no es que la credencial exista, es que su alcance no coincide con el del cliente que dispara la acción. Aura actúa con el permiso de la aplicación, no con el del usuario autenticado. Y el modelo, que decide qué pedir, es precisamente la pieza influenciable: ponerle delante una herramienta que puede leerlo todo es confiar la frontera de datos a quien no la sostiene.

Esta situación es un clásico de la seguridad que precede a la IA: el diputado confundido. Un componente con mucho permiso —el «diputado»— actúa a petición de otro con poco, y hace por él cosas que ese otro no podría hacer por su cuenta. En un sistema con IA el diputado es el conjunto modelo-más-herramienta: tiene las credenciales amplias de la aplicación y recibe peticiones de un usuario limitado, así que puede ser inducido a usar su permiso en favor de quien no lo tiene.

Reconocer el patrón ayuda porque la defensa es conocida. No se arregla haciendo al modelo más listo ni al prompt más firme; se arregla alineando el permiso con el que pide. El diputado deja de estar confundido cuando actúa con exactamente el alcance del cliente autenticado, ni más ni menos, de modo que no pueda hacer por él nada que el cliente no pudiera hacer solo.

Es tentador pensar que esto ya lo resolvió la sala anterior, pero son capas distintas. Allí se acotó qué hace la herramienta: el importe de un reembolso, su cuenta de destino, su tope. Aquí se acota sobre qué datos actúa: el alcance de su credencial. Una herramienta puede tener el importe perfectamente limitado y aun así correr con una credencial que lee a todos los clientes; acotar el parámetro no toca el alcance, y acotar el alcance no toca el parámetro. Hacen falta las dos.

Verlo como dos ejes evita una falsa sensación de cobertura. Un auditor que solo revisó topes e importes puede dar por segura una herramienta que sigue siendo un diputado confundido, capaz de leer datos ajenos aunque nunca mueva un euro de más. La pregunta de esta sala —¿con el permiso de quién corre?— es independiente de la pregunta de la anterior —¿qué puede hacer?—, y un asistente seguro contesta bien a las dos.

La corrección es que cada herramienta actúe dentro del alcance del usuario autenticado de la sesión, no con un permiso global. En la práctica, la aplicación obtiene una credencial o un recorte acotado a ese cliente para cada petición, y la herramienta solo puede tocar lo que el cliente podría tocar por sí mismo. Si luego una inyección convence al modelo de pedir la reserva de otra persona, la herramienta no puede cumplir: su permiso no llega, porque está recortado al cliente en sesión.

Es otra cara del permiso mínimo y del aislamiento por usuario que atraviesa toda la ruta. El modelo sigue proponiendo qué consultar, pero el alcance de lo que se puede consultar lo fija el sistema a partir de quién está autenticado, no el modelo a partir de lo que cree entender. Así el diputado deja de poder ser confundido: no tiene en la mano más permiso del que tiene el cliente que lo manda.

Ya sabes preguntar con el permiso de quién corre cada herramienta. Audítalo sobre Aura: abre el manifiesto de credenciales de sus herramientas y localiza la que corre con una credencial global, capaz de leer a cualquier cliente. El manifiesto cierra con un código de la sala.