Resumo Técnico: O Proxy Sabe Demais: Selando Roteadores de API de LLM com TEEs Atestadas

1. Declaração do Problema

O artigo identifica uma vulnerabilidade de segurança crítica na arquitetura dos roteadores de API de Modelos de Linguagem de Grande Escala (LLM). À medida que os agentes dependem cada vez mais de intermediários para acessar múltiplos provedores de modelos, esses roteadores atuam como pontos de homem no meio (MitM) na camada de aplicação. Ao terminar a sessão TLS do cliente e iniciar uma sessão separada de upstream, o roteador detém a interação completa de requisição e resposta em texto simples (plaintext).

Este design estrutural concede ao operador do roteador visibilidade e controle total sobre os dados do agente, permitindo quatro classes distintas de ataques maliciosos:

• AC-1 (Reescrita de chamada de ferramenta): O roteiro pode alterar chamadas de ferramentas (ex: comandos de shell) antes que cheguem ao cliente. Como a reescrita é válida conforme o esquema (schema-valid), o cliente executa o comando malicioso, podendo levar à execução remota de código.
• AC-1.a (Typosquatting): O roteador pode trocar dependências em comandos de instalação por pacotes com nomes similares (typosquatted), contornando listas de permissões baseadas em domínio e estabelecendo um foothold na cadeia de suprimentos.
• AC-1.b (Ataques disparados por gatilho): O roteador pode executar reescritas apenas sob condições específicas (ex: palavras-chave específicas ou contagem de requisições), evitando a detecção por auditores que utilizam conjuntos de sondagem finitos.
• AC-2 (Exfiltração passiva): O roteador pode escanear o tráfego em busca de credenciais e segredos, exfiltrando-os sem alterar a interação.

Defesas existentes no lado do cliente (portões de política, triagem de anomalias) mostram-se evitáveis. O artigo argumenta que uma correção sólida exige mover a fronteira de confiança para uma parte que o cliente possa verificar sem depender da cooperação do provedor ou da honestidade do operador do roteador.

2. Metodologia: AEGIS

Os autores propõem o AEGIS, um roteador de API atestado e transparente ao provedor que confina o processamento de texto simples a um enclave pequeno, reforçado por hardware, enquanto deixa as funções de gerenciamento em um host não confiável.

Arquitetura Central

O AEGIS divide o roteador em dois domínios de confiança distintos:

1. O Host Não Confiável: Lida com autenticação, seleção de conta, agendamento, faturamento e gerenciamento. Ele se comunica com o enclave através de um canal de controle estreito que nunca carrega o corpo da requisição/resposta ou endereços de rede.
2. O Enclave Atestado (TEE): Executa um caminho de dados mínimo e fiel. Ele termina a sessão TLS do cliente, retransmite os bytes da requisição e resposta literalmente para um provedor fixo e reporta apenas telemetria de uso ao host.

Mecanismos Principais

• Passagem Fiel (Faithful Passthrough): O código do enclave não realiza nenhuma transformação semântica. Ele encaminha requisições e respostas byte a byte. Isso garante que a atestação do código garanta a integridade do fluxo de dados.
• Atestação de Falha Fechada (Fail-Closed Attestation): Antes que o cliente libere qualquer texto simples (prompts, chamadas de ferramentas, credenciais), um sidecar local verifica a atestação remota do enclave. O cliente só envia dados se a medição do enclave corresponder a um valor fixo e auditado e estiver vinculada à sessão atual.
• Autoridade de Destino: O conjunto de destinos de upstream legítimos está "incorporado" na imagem medida do enclave. O host pode apenas solicitar uma rota por nome (política), não por IP/URL. O enclave resolve esse nome para um destino fixo, impedindo que o host redirecione o tráfego para endpoints maliciosos.
• Medição Ancorada (ARPA): O sistema utiliza um protocolo Audit, Reproduce, Pin, Attest (Auditar, Reproduzir, Fixar, Atestar). Os operadores publicam um manifesto de build reproduzível assinado e registrado em um log de transparência. Os clientes auditam o código-fonte, reconstroem de forma reproduzível para verificar a medição e fixam o resultado. Isso permite que os clientes confiem no código sem uma autoridade central.

3. Principais Contribuições

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

1. Design Transparente ao Provedor: Uma arquitetura de roteador que fecha todas as quatro classes de ataques de roteador malicioso (AC-1, AC-1.a, AC-1.b, AC-2) sob um modelo preciso de operador malicioso, sem exigir mudanças no lado do provedor.
2. Base de Confiança Mínima (Minimal TCB): Um design focado em confidencialidade onde apenas a passagem fiel roda no enclave (851 linhas de código confiável). Autenticação e faturamento permanecem no host não confiável, minimizando a Base de Computação Confiável (TCB).
3. Medição Igual a Código Auditado: Uma construção usando builds reproduzíveis e logs de transparência (protocolo ARPA) que permite que usuários finais ou seus agentes ancorem a confiança sem uma autoridade central.
4. Avaliação Empírica: Testes abrangentes demonstrando que o AEGIS bloqueia todas as quatro classes de ataque enquanto mantém um baixo overhead. Isso inclui testes adaptativos, verificação formal via ProVerif e testes de carga com provedores reais.

4. Resultados e Avaliação

Os autores implementaram o AEGIS no AWS Nitro Enclaves e o avaliaram contra uma linha de base de acesso em texto simples.

• Eficácia de Segurança: Todas as quatro classes de ataque (AC-1 a AC-2) tiveram sucesso contra a linha de base de texto simples, mas foram completamente bloqueadas pelo AEGIS. Testes adaptativos confirmaram que o host não pode reescrever chamadas de ferramentas, injetar typosquats, disparar reescritas condicionais ou exfiltrar segredos.
• Verificação Formal: Um modelo simbólico usando ProVerif confirmou a ordenação do protocolo, a liberação atestada e a autoridade de destino, invalidando o sistema quando as verificações individuais eram removidas.
• Auditabilidade: Em um piloto de auditoria semeado, dois agentes de codificação comuns (Codex e Claude Code) identificaram com sucesso violações de invariantes plantadas (8/10 e 10/10, respectivamente) no código mínimo confiável, validando a afirmação de que o código reduzido é passível de revisão.
• Overhead de Desempenho:
  • Latência: O relay local adiciona aproximadamente 6 milissegundos por requisição para payloads pequenos.
  • Escalabilidade: O overhead cresce com o tamanho do payload devido à criptografia e travessia de fronteiras (atingindo ~183ms para payloads de 4MB), mas permanece bem abaixo da latência da própria chamada do modelo.
  • Concorrência: O sistema lida com paralelismo moderado (até 16 requisições simultâneas) com a latência mediana mantendo-se dentro de 20% dos valores de requisição única.
  • Streaming: O sistema preserva a cadência de tokens do provedor, não adicionando jitter mensurável entre os tokens.

5. Significância e Alegações

O artigo afirma que o AEGIS representa o primeiro retrofit de enclave reproduzível de código confiável mínimo de um template de roteador open-source amplamente implantado. Sua significância reside em:

• Mudança da Fronteira de Confiança: Ele move a fronteira de confiança do operador do roteador (que não pode ser totalmente confiável) para um enclave de hardware verificável, removendo a capacidade do operador de agir de forma maliciosa em vez de apenas detectar o comportamento após o fato.
• Fechamento do "Gap de Implantação": Resolve o problema onde os clientes não podem assumir que os provedores adicionarão novas APIs ou infraestrutura para eles. O AEGIS funciona com provedores existentes e upstreams HTTPS padrão.
• Preservação da Semântica do Agente: Ao impor estritamente uma "passagem fiel", ele garante que as chamadas de ferramentas dos agentes e as estruturas de streaming permaneçam intactas, o que é crítico para agentes de codificação que dependem de respostas exatas do provedor.

Os autores mantêm modéstia quanto às limitações, reconhecendo que o sistema depende da raiz de confiança do hardware, não protege contra ataques de canal lateral (side-channel) e atualmente deixa vazamentos residuais em relação ao tamanho e tempo do tráfego. Eles observam que, embora o protótipo atual seja uma solução de um único salto (single-hop), o trabalho futuro pode estender a confiança para upstreams atestados de múltiplos saltos.