Defensa por arquitectura

Un reflejo que cuesta adquirir: lo que el modelo devuelve no es más de fiar que lo que el usuario escribe. La salida de Aura puede estar influida por una inyección, así que tratarla como contenido seguro es un error. Si la respuesta del modelo se muestra en la interfaz sin escapar, y el modelo fue inducido a devolver una etiqueta con un guion dentro, esa etiqueta puede ejecutarse en el navegador de otro cliente. Si la salida se pasa a otra herramienta sin comprobarla, esa herramienta hereda lo que la inyección metió.

La defensa es el manejo seguro de la salida: todo lo que el modelo produce se valida y se escapa antes de usarse, según a dónde va. Si va a la pantalla, se escapa como texto; si va a una consulta, se trata como parámetro; si va a una herramienta, se comprueba contra lo que esa herramienta espera. La salida del modelo cruza una frontera de confianza, igual que la entrada del usuario, y se trata con la misma desconfianza.

No todas las acciones merecen el mismo trato. Leer el estado de una reserva es reversible y de bajo impacto; mover dinero o enviar un correo a un tercero no lo es. Un diseño sano clasifica las acciones por impacto y pone compuertas donde el impacto lo pide: por debajo de un límite, el sistema determinista ejecuta directo; por encima, la acción espera una confirmación humana. Aura puede seguir siendo ágil en lo cotidiano y a la vez no ser capaz, ella sola, de causar un daño que no se pueda deshacer.

La compuerta humana no es burocracia: es reconocer que un sistema no determinista no debería tener la última palabra sobre lo irreversible. El límite se fija por el riesgo de la acción, no por la comodidad, y se aplica fuera del modelo, para que una inyección no pueda subirlo ni saltárselo.

El aislamiento apareció en la fuga de contexto y en el RAG, y aquí se ve como principio transversal. Cada pieza que toca datos —la memoria de conversación, la recuperación de documentos, las herramientas— opera dentro del alcance del usuario autenticado, no del conjunto de todos los usuarios. El modelo nunca recibe en su contexto nada que el usuario de esa sesión no pudiera ver por sí mismo, y ninguna herramienta actúa sobre datos de otro usuario.

Aislar de punta a punta cierra de golpe una familia entera de fugas y de abusos: si el contexto solo contiene lo del cliente actual, una inyección no puede sacar lo de otro, porque no está ahí para sacarlo. Es la aplicación del permiso mínimo a los datos: el sistema no le da al modelo acceso a un universo de datos «por si acaso», le da el recorte de ese usuario. Lo que no está en el contexto no se puede filtrar.

Las cuatro piezas —validar la salida, poner límites, aislar, dar permiso mínimo— son caras de un mismo principio de arquitectura: el modelo es un componente no confiable y no determinista, así que se le deja proponer e interpretar, pero nunca se le deja ser quien autoriza lo sensible. Alrededor de él hay código normal, auditable y determinista, que aplica las reglas y tiene la última palabra. Ese código no se deja convencer con texto, porque no lee texto libre para decidir: lee intenciones estructuradas y comprueba condiciones.

Diseñar así cambia la pregunta de seguridad. Deja de ser «¿cómo evito que el modelo se equivoque?» —que no tiene respuesta completa— y pasa a ser «¿qué pasa de malo si el modelo se equivoca del todo?». Un sistema bien arquitecturado responde: nada irreversible, nada fuera del alcance del usuario, nada sin validar. El modelo puede fallar, porque el sistema está construido para que su fallo no llegue lejos.

La salida del modelo cruza una frontera de confianza igual que la entrada. Compruébalo sobre Aura: abre su política de manejo de la salida y mira si lo que el modelo devuelve se pinta y se pasa a herramientas sin validar ni escapar, y cuáles de las cuatro piezas de defensa faltan. El archivo cierra con un código de la sala.