Un cliente inicia un chat de soporte y pregunta: “¿Puede explicar por qué la factura INV-1042 se marcó como atrasada?”. El asistente de soporte responde con seguridad y cita una nota interna perteneciente a otra empresa, incluyendo una línea como: “Según los términos de renovación de ACME, condonar el cargo en condiciones de pago a 60 días (net-60)”. La interfaz de soporte nunca mostró tickets de ACME ni al agente ni al cliente, pero aun así el asistente incorporó esa nota en la respuesta. No ocurrió nada inusual; bastó con que el cliente hiciera una pregunta normal por el canal habitual para que la aplicación hiciera el resto.
La estructura del sistema que provocó la fuga es lo suficientemente sencilla como para visualizarla fácilmente. Un usuario final envía un mensaje a la aplicación de soporte; esta recupera registros relacionados de una base de datos, compone un prompt (instrucción) que incluye el mensaje del usuario y las filas recuperadas, y envía dicho prompt a un proveedor de modelos. El modelo devuelve texto y la aplicación lo muestra como respuesta del asistente. El fallo se manifiesta como una cita de información perteneciente a otro inquilino (tenant): la aplicación devolvió datos privados de un inquilino al usuario de otro.
Solo podemos solucionar la fuga si identificamos el límite exacto donde los datos no confiables pasan a formar parte de una acción confiable. Un límite de confianza es el punto de unión donde los datos de un lado no deben adquirir automáticamente los privilegios del otro, ya que ambas partes tienen incentivos y niveles de acceso distintos. En nuestro asistente de soporte, el usuario final se sitúa en un lado y el acceso a los datos de la aplicación en el otro, pero este límite se repite en cada etapa que pueda alterar qué datos se leen o se revelan.
A lo largo de toda la ruta de la solicitud, consideramos cuatro elementos como no confiables, ya que cada uno puede contener instrucciones o contenido que no fueron generados por la propia aplicación. El mensaje del usuario final no es confiable porque está bajo su control. Las filas de la base de datos no son confiables porque la base de datos puede devolver resultados inesperados si la consulta o el filtro son erróneos, y porque el texto recuperado puede contener contenido con formato de instrucción que no debería formar parte de una respuesta. La salida del modelo no es confiable porque este sigue el texto recibido y puede proponer operaciones de lectura, escritura o divulgación que la aplicación nunca pretendió realizar. Solo la configuración propia de la aplicación —como una lista estática de nombres de herramientas permitidas o una lista fija de columnas a seleccionar— se considera confiable desde el inicio; y aun así, dicha configuración solo mantiene su fiabilidad si la aplicación la carga desde una fuente controlada. El diagrama de límites de confianza que aparece a continuación identifica cada salto y los datos que fluyen a través de él. Marquemos dónde entra en el flujo cada entrada no confiable: