Resumo Técnico: Proveniência de Caminho de Gateway com Evidência Vinculada para Inferência de LLM de Terceiros

1. Declaração do Problema

Gateways de Large Language Models (LLM) de terceiros tornaram-se infraestruturas críticas para aplicações que utilizam múltiplos provedores de LLM externos. Esses sistemas gerenciam roteamento, seleção de modelos, mecanismos de fallback, streaming e faturamento. No entanto, existe uma fronteira de confiança fundamental: o operador do gateway controla tanto a mediação do caminho de inferência quanto a autoria dos registros que descrevem esse caminho.

Em implantações convencionais, embora o TLS proteja os saltos de rede, o gateway encerra as requisições do cliente em texto simples (plaintext). Isso permite que o gateway possa:

• Ler prompts e reescrever requisições upstream.
• Substituir endpoints ou modelos sem o conhecimento do cliente.
• Alterar respostas de streaming ou injetar conteúdo.
• Forjar registros de uso, faturamento ou proveniência.

Os clientes que recebem apenas uma resposta e um log gerado pelo gateway não podem distinguir uma mediação honesta de uma substituição de modelo oculta, fallback não declarado, reescrita de endpoint ou manipulação de stream. Esse risco é amplificado em sistemas agentes, onde o texto retornado pode disparar chamadas de ferramentas (tool calls) ou edições de código. O problema central não é meramente quem pode ler o prompt, mas quem pode ser o autor do registro do caminho do gateway.

2. Metodologia: Arquitetura de Gateway com Evidência Vinculada

O artigo propõe uma arquitetura de Gateway com Evidência Vinculada que separa o plano de negócios controlado pelo operador de um plano de execução atestado remotamente. O componente central é o Ambiente de Execução de Gateway Atestado (AGR - Attested Gateway Runtime), que opera dentro de um Ambiente de Execução Confiável (TEE - Trusted Execution Environment).

Componentes Arquiteturais Chave

• Plano de Negócios (Business Plane): Lida com autenticação de clientes, aplicação de cotas, encaminhamento de tráfego e logging. Ele encaminha ciphertext opaco, mas não pode descriptografar requisições ou acessar chaves de stream.
• Ambiente de Execução de Gateway Atestado (AGR): O plano de execução de segurança crítica que roda dentro de um TEE (ex: AWS Nitro Enclaves). É o único componente autorizado a:
  • Descriptografar requisições de clientes.
  • Aplicar políticas de roteamento e fallback por requisição.
  • Construir chamadas upstream para provedores de LLM.
  • Criptografar fluxos de resposta.
  • Assinar Cadeias de Evidência de Inferência (IEC - Inference Evidence Chains).

Fluxo do Protocolo

1. Registro e Atestação: Uma autoridade de liberação assina um registro de medições de runtime e políticas aprovadas. Os clientes verificam este registro e solicitam uma atestação fresca do AGR. O AGR fornece um "quote" de hardware vinculando sua medição, hash de política e chaves de criptografia/assinatura de evidência.
2. Contratos com Transporte de Política: Os clientes enviam requisições criptografadas contendo um Contrato de Inferência (IC - Inference Contract) que estreita a política global para uma requisição específica (ex: modelos permitidos, arestas de fallback). O AGR calcula a política efetiva ($P_{eff} = P \cap IC$).
3. Execução Segura: O AGR descriptografa a requisição, valida a política, seleciona a rota/endpoint, chama o provedor upstream. Ele criptografa o fluxo de resposta e mantém um compromisso (commitment) contínuo sobre os chunks criptografados.
4. Geração de Evidência: O AGR assina uma Cadeia de Evidência de Inferência (IEC). Este objeto vincula:
   • Atestação de runtime e identidade.
     im
   • Política efetiva e hashes de contrato.
   • Decisões de rota e fallback.
   • Identidade do endpoint observado (verificação TLS).
   • Compromissos de transcrição de stream criptografados (StreamEv).
   • Metadados de conclusão.
5. Verificação: O cliente verifica a IEC contra a identidade do runtime atestado e recomputa o compromisso do stream para garantir que o ciphertext recebido corresponde à evidência assinada.

3. Principais Contribuições

O artigo apresenta quatro contribuições primárias:

1. Identificação do Problema: Identifica o problema da fronteira de confiança de múltiplas autoridades em gateways de LLM de terceiros, onde o roteamento, fallback, admissão de endpoint e autoria de evidência estão concentrados em um único serviço controlado pelo operador.
2. Arquitetura: Apresenta uma arquitetura de planos divididos, movendo a descriptografia, aplicação de política, construção de upstream e assinatura de evidência para um runtime atestado (AGR), preservando as funções do plano de negócios.
3. Mecanismos: Introduz contratos de inferência com transporte de política e cadeias de evidência de inferência que vinculam a atestação de runtime, política por requisição, decisões de rota e transcrições de stream criptografadas em uma proveniência verificável.
4. Implementação e Avaliação: Implementa um protótipo em Rust na AWS Nitro Enclaves e avalia os overheads de mecanismo, aplicação de rotas e comportamentos de falha fechada (fail-closed).

4. Resultados Experimentais

Os autores avaliaram o sistema usando um protótipo em Rust com provedores mock locais e endpoints GPT ao vivo.

• Overhead: Em um ambiente mock determinístico local (concorrência 16), o gateway com evidência vinculada (B2) apresentou um p95 de latência de 38,72 ms.
• Desempenho no Nitro Enclave: Quando o runtime foi colocado em um Nitro Enclave (B3), a latência p95 aumentou ligeiramente para 46,2 ms (aproximadamente 1,1x o runtime local), com o throughput mantendo 95% da linha de base local. O overhead foi dominado pelo transporte, não pelas operações criptográficas.
• Custos de Evidência: Para uma transcrição de 100 chunks, a construção e recomputação do StreamEv custaram aproximadamente 130 µs e 120 µs (p95), respectivamente. A assinatura e verificação da IEC ocorreram na ordem de dezenas de microssegundos.
• Validação de Falha Fechada (Fail-Closed): O sistema rejeitou com sucesso tentativas de adulteração em todos os cenários de controle negativo, incluindo:
  • Adulteração de atestação/registro (PCR, nonce, modificação de registro).
  • Violações de integridade de canal (adulteração de chave/ciphertext).
  • Substituição de rota e fallback (troca de modelos, omissão de fallbacks).
  • Violações de restrição de endpoint.
  • Reescrita de metadados de evidência e manipulação de transcrição de stream (deleção, reordenação, replay).
  • Envenenamento do gateway (chamadas de ferramentas injetadas foram rejeitadas).

5. Significância e Alegações

O artigo afirma que esta arquitetura estabelece a autenticidade da proveniência do caminho do gateway. Ele permite que os clientes verifiquem que:

• A requisição foi mediada por um runtime específico e mensurado.
• O roteamento, fallback e seleção de endpoint aderiram à política assinada.
• A transcrição do stream criptografado entregue corresponde ao compromisso assinado.
• A evidência não foi forjada ou transferida de um contexto de requisição diferente.

Escopo e Limitações:
Os autores declaram explicitamente o que o sistema não afirma fazer:

• Não esconde metadados de tráfego (tempo, tamanho de pacote, frequência).
• Não previne ataques de Negação de Serviço (DoS).
• Não prova que o provedor de LLM upstream executou o modelo correto ou gerou conteúdo seguro (o provedor permanece fora do TCB).
• Não protege contra provedores de LLM maliciosos, contextos RAG envenenados ou violações de política no nível do agente.
• Depende da confiabilidade da plataforma TEE, da raiz de atestação e do processo de assinatura de liberação.

A significância reside na mudança do modelo de confiança: os clientes não precisam mais confiar no operador do gateway para mediar o caminho e autoria dos registros. Em vez disso, eles confiam em evidências criptográficas vinculadas a um runtime mensurado, garantindo que roteamento não autorizado, fallbacks ocultos, manipulação de stream e registros de faturamento forjados sejam detectados e rejeitados.