Um cliente inicia um chat de suporte e pergunta: “Você pode explicar por que a fatura INV-1042 foi marcada como atrasada?” O assistente de suporte responde com uma explicação segura e cita uma nota interna pertencente a outra empresa, incluindo uma linha como “Conforme os termos de renovação da ACME, isentar a taxa para pagamentos em 60 dias (net-60)”. A interface de suporte nunca exibiu nenhum chamado da ACME para o atendente ou para o cliente, mas o assistente ainda assim incorporou essa nota à resposta. Não houve nada de incomum aqui. O cliente apenas fez uma pergunta comum no canal habitual, e o aplicativo fez o resto.
A estrutura do sistema que gerou o vazamento é simples o suficiente para ser facilmente compreendida. Um usuário final envia uma mensagem ao aplicativo de suporte, o aplicativo busca registros relacionados em um banco de dados, monta um prompt que inclui a mensagem do usuário e as linhas recuperadas, e envia esse prompt a um provedor de modelo. O modelo retorna um texto, e o aplicativo exibe esse texto como a resposta do assistente. A falha manifesta-se como uma citação de dados entre tenants (clientes distintos). O aplicativo retornou dados privados de um tenant para o usuário de outro tenant.
Só podemos corrigir o vazamento quando identificamos o limite exato onde dados não confiáveis passam a influenciar uma ação confiável. Um limite de confiança é a fronteira onde dados de um lado não devem adquirir automaticamente os privilégios do outro lado, pois ambos possuem incentivos e níveis de acesso distintos. No nosso assistente de suporte, o usuário final está de um lado e o acesso a dados do aplicativo está do outro; no entanto, esse limite se repete a cada etapa que possa alterar quais dados são lidos ou revelados.
Ao longo de todo o caminho da requisição, tratamos quatro elementos como não confiáveis, pois cada um pode conter instruções ou conteúdos não criados pelo aplicativo. A mensagem do usuário final não é confiável porque é controlada pelo próprio usuário. As linhas do banco de dados não são confiáveis porque o banco pode retornar registros inesperados caso a consulta ou o filtro estejam incorretos, e porque o texto recuperado pode conter conteúdo com formato de instrução que não deveria fazer parte de uma resposta. A saída do modelo não é confiável porque o modelo segue o texto recebido e pode propor operações de leitura, escrita ou divulgação que o aplicativo nunca planejou. Apenas a configuração do próprio aplicativo — como uma lista estática de nomes de ferramentas permitidas ou uma lista fixa de colunas a serem selecionadas — começa como confiável; e mesmo essa configuração só permanece confiável se o aplicativo a carregar de uma fonte controlada. O diagrama de limites de confiança abaixo identifica cada etapa e os dados que trafegam por ela. Vamos marcar onde cada entrada não confiável ingressa no fluxo: