Um chat de suporte pode se transformar em uma ação que envolve movimentação financeira quando um backend FastAPI aceita a saída do modelo como uma instrução autoritativa.
No cenário de falha utilizado neste curso, um aplicativo cliente envia uma mensagem aparentemente comum para POST /v1/chat, o serviço FastAPI encaminha esse texto para um provedor de modelos e o modelo retorna uma instrução de ferramenta que se assemelha a uma solicitação de reembolso.
O backend executa a chamada da ferramenta assim que o modelo a sugere, sem verificar se o usuário final tem permissão para realizar essa ação e sem tratar a saída do modelo como texto não confiável.
Não é necessário nada incomum para que a falha ocorra. O backend faz exatamente o que foi projetado para fazer, mas executa a etapa de maior privilégio — a ação da ferramenta — com base em uma string que veio de fora do limite de confiança.
Uma vez executada a ação irreversível, nenhum filtro posterior consegue desfazer o efeito colateral; portanto, precisamos decidir onde deve ocorrer a primeira interrupção eficaz.
A mesma requisição atravessa vários limites onde texto não confiável se transforma em gastos ou efeitos colaterais, e o curso mantém o foco nesse caminho único para que cada controle seja aplicado em um ponto específico.
Texto não confiável entra por três vias, mesmo quando o cliente se comporta adequadamente. A mensagem do cliente chega na requisição HTTP, documentos recuperados vêm dos próprios armazenamentos de dados do backend e resultados de ferramentas retornam de outros sistemas que podem estar incorretos ou ser hostis.
Dinheiro e dados podem ser consumidos em dois pontos. A chamada ao provedor de modelos consome tokens e gera custos, enquanto a execução da ferramenta pode ler ou alterar recursos reais que talvez não pertençam ao usuário.
Os únicos pontos de controle confiáveis são as verificações no lado do servidor, dentro do serviço FastAPI, em torno desses pontos de consumo. O curso implementa autenticação, vinculação de tenant, cotas, filtros de entrada e saída, autorização de ferramentas, sandboxing e registro de auditoria como barreiras explícitas; a redação do prompt não impõe nenhuma dessas restrições, pois o prompt do sistema é legível e o modelo apenas segue o texto.
O diagrama abaixo indica cada entrada não confiável e cada ponto de controle no caminho único da requisição que estamos analisando. Vamos identificar exatamente onde o texto passa a ter autoridade e onde podemos recusar a operação.
Este diagrama torna visível uma regra. Nenhuma seta que transporta texto é confiável, e apenas as caixas em nosso serviço podem recusar, limitar, validar, autorizar e registrar o que aconteceu.
Um contrato de API seguro precisa de códigos de recusa consistentes, pois tanto os clientes quanto a depuração em regime de plantão dependem de resultados previsíveis quando uma barreira de controle rejeita uma solicitação.
Definimos o mapa de recusas uma única vez e o reutilizamos, sempre associando cada recusa ao limite (ou barreira) que a impõe, em vez de associá-la ao modelo.
401 Unauthorized: rejeita credenciais de quem chama que estejam ausentes, inválidas, revogadas ou comprometidas; o serviço retorna esse erro antes de consumir a cota ou chamar o provedor.403 Forbidden: rejeita um solicitante autenticado que esteja fora de seu escopo permitido (incluindo casos de aprovação negada ou expirada) e também rejeita a busca de uma ferramenta em um destino bloqueado, o qual nunca chega a ser contatado.422 Unprocessable Content (RFC 9110): rejeita a saída do modelo que falha na validação de esquema, pois uma saída não validada é apenas texto até que o servidor comprove que ela está em conformidade com o contrato da ferramenta.429 Too Many Requests (com Retry-After): rejeita solicitações quando o limite de taxa ou a cota se esgotam; o contador deve ser compartilhado para evitar que réplicas multipliquem silenciosamente o limite.503 Service Unavailable: ocorre quando o armazenamento do contador de cotas está fora do ar ou um circuit breaker aberto impede a aplicação da regra, pois o serviço não consegue decidir com segurança se o consumo é permitido.504 Gateway Timeout: ocorre quando a chamada ao provedor excede o tempo limite (timeout) do serviço, pois chamadas travadas representam consumo ilimitado.Para manter o curso prático, construímos um artefato funcional e o fortalecemos passo a passo. O artefato é uma rota POST /v1/chat com suporte a múltiplos inquilinos (tenant-aware) capaz de chamar exatamente uma ferramenta; cada lição subsequente adiciona uma barreira de controle a esse fluxo.
No caso da falha inicial, o solicitante pode ser legítimo; isso significa que a autenticação pode ser bem-sucedida enquanto a solicitação ainda desencadeia uma ação de ferramenta não autorizada.
Se o serviço aguardar a execução da chamada da ferramenta para validar a saída do modelo, a validação de esquema ainda poderá rejeitar um payload malformado, mas não conseguirá reverter uma ação que parecia correta, porém nunca deveria ter sido permitida.
A decisão importante é qual etapa pode recusar a operação antes que uma ação irreversível da ferramenta seja executada. Qual é o ponto de parada mais inicial capaz de conter a falha: autenticação, autorização da ferramenta ou validação da saída?