AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

O artigo apresenta o AEX, uma extensão de atestação não intrusiva para APIs de modelos de linguagem que utiliza objetos de atestação assinados para vincular criptograficamente solicitações do cliente às respostas ou linhagens de saída, garantindo a integridade e a proveniência dos dados em ambientes de API hospedados.

O essencial

Imagine que você está pedindo um prato em um restaurante de luxo (o Modelo de Linguagem ou LLM) através de um garçom muito eficiente (a API). Você diz: "Quero uma sopa de tomate", e o garçom traz uma tigela.

O problema é: como você tem certeza de que a sopa na sua mesa é realmente a sopa de tomate que você pediu? E como saber se o garçom não trocou o prato no caminho, ou se o cozinheiro usou ingredientes diferentes do que prometeu?

Hoje, muitos "restaurantes" (APIs de IA) operam em uma zona cinzenta. Existem "garçons fantasmas" (chamados de shadow APIs) que dizem ser o restaurante oficial, mas podem estar servindo comida de baixa qualidade ou modificando seu pedido sem avisar.

É aqui que entra o AEX, o protagonista deste artigo.

O Que é o AEX? (A "Etiqueta de Selagem" Digital)

Pense no AEX como um selo de segurança digital que é colado na sua encomenda no momento em que ela sai da cozinha e chega até você. Ele não muda o prato (a resposta da IA), nem o pedido (o que você digitou). Ele apenas adiciona uma etiqueta assinada digitalmente que diz:

"Eu, o Chef (o emissor confiável), garanto que este prato específico foi feito exatamente a partir deste pedido específico, e que ninguém mexeu nele no caminho."

Se alguém tentar trocar a sopa por uma salada no meio do caminho, a etiqueta não vai bater com o conteúdo, e você saberá imediatamente que algo está errado.

Como Funciona na Prática? (Analogias do Dia a Dia)

O artigo descreve três situações principais onde o AEX brilha:

1. O Pedido Original vs. O Pedido Real (Modos de Ligação)

Às vezes, o garçom precisa adicionar um código de rastreamento ou mudar levemente o pedido antes de levar à cozinha.

• Sem AEX: Você não sabe se o garçom mudou o pedido.
• Com AEX: O sistema permite que você escolha o nível de estrita fidelidade.
  • Modo "Tudo Igual": O prato deve ser idêntico ao pedido.
  • Modo "Flexível": O garçom pode adicionar "tempo de espera" ou "número de mesa" sem quebrar o selo, mas não pode mudar os ingredientes principais.
  • A Mágica: O AEX cria um "recibo" que diz: "O pedido original era X, mas o cozinheiro recebeu Y (com essas pequenas mudanças permitidas) e fez o prato Z". Isso evita que o garçom mude o pedido secretamente.

2. A Sopa que Vem aos Pedaços (Streaming)

Muitas IAs não entregam a resposta inteira de uma vez; elas "vazam" a resposta palavra por palavra (como um filme que carrega aos poucos).

• O Problema: Se o filme travar no meio ou se alguém inserir cenas estranhas no meio do fluxo, como saber?
• A Solução AEX: Imagine que cada palavra que sai da IA vem com um pequeno "número de ordem" e um "código de segurança" encadeado.
  • Se a IA diz "O céu é..." e depois "azul", o AEX garante que "azul" veio logo após "O céu é" e que ninguém inseriu "verde" no meio.
  • Se a conexão cair, você sabe exatamente onde parou e se o que você viu até ali era genuíno.

3. O Prato Reembalado (Reescrita Confiável)

Às vezes, um intermediário (como um sistema de segurança) precisa alterar a resposta antes de chegar a você. Exemplo: a IA gera uma resposta longa, mas o sistema de segurança corta partes ofensivas ou resume tudo em um único parágrafo.

• Sem AEX: Você acha que a IA fez o resumo, mas na verdade foi um robô de segurança.
• Com AEX: O sistema cria uma Cadeia de Origem.
  • O selo diz: "A IA original fez o prato completo (A). Depois, o Sistema de Segurança (B) transformou o prato A no prato final (C) que você está comendo."
  • Isso é transparente. Você sabe que o prato foi modificado, mas sabe que foi feito por um intermediário de confiança, e não por um ladrão.

O Que o AEX NÃO Faz (Limitações Importantes)

É crucial entender o que o AEX não é, para não criar expectativas falsas:

• Não é um "Detector de Mentiras": O AEX garante que o prato veio da cozinha X e não foi trocado. Ele não garante que a sopa de tomate é saborosa, que o tomate estava fresco ou que a receita estava correta. Se a IA alucinar (inventar fatos), o AEX ainda dirá "Sim, isso foi o que a IA disse", mas não que "Isso é verdade".
• Não é um Raio-X da Cozinha: Ele não prova que o cozinheiro usou exatamente o mesmo fogão ou as mesmas panelas (o hardware ou o modelo exato), apenas que o pedido e a entrega foram vinculados corretamente.

Por Que Isso é Importante Agora?

O artigo menciona que existem muitos "restaurantes falsos" (Shadow APIs) que fingem ser os grandes provedores de IA, mas entregam resultados ruins ou diferentes. O AEX é como um selo de autenticidade oficial que qualquer cliente pode verificar.

Se você estiver usando uma API de IA para tomar decisões importantes (como diagnósticos médicos ou jurídicos), o AEX é a ferramenta que diz: "Eu garanto que esta resposta veio exatamente do pedido que você fez, e que ninguém a adulterou no caminho."

Resumo em Uma Frase

O AEX é um sistema de "selagem de encomendas" para Inteligência Artificial que garante que o que você pediu é exatamente o que você recebeu, mesmo que o pedido tenha passado por vários intermediários, sem que você precise confiar cegamente no garçom ou no cozinheiro.

Resumo técnico

Resumo Técnico: AEX (Attestation Extension)

1. O Problema

O acesso a Grandes Modelos de Linguagem (LLMs) ocorre cada vez mais através de APIs remotas hospedadas. No entanto, a fronteira dessa API oferece pouca evidência direta de que a saída retornada corresponde realmente à solicitação visível do cliente.

• Fragilidade da Confiança: Auditorias recentes de "Shadow APIs" (endpoints não oficiais que alegam compatibilidade) revelaram que intermediários ou endpoints intermediários podem divergir significativamente do comportamento prometido (até 47% de divergência de utilidade).
• Limitações das Abordagens Atuais: Técnicas existentes como fingerprinting (impressão digital), testes de igualdade de modelos, inferência verificável e atestação baseada em TEE (Ambiente de Execução Confiável) são insuficientes porque:
  • São inferenciais (tentam adivinhar o modelo por trás da saída).
  • Respondem a perguntas diferentes (focam no ambiente de execução ou na identidade do modelo, não na ligação direta solicitação-resposta).
  • Não lidam bem com reescritas legítimas de requisições ou saídas por gateways e middleware.

O problema central abordado é: Como uma API LLM existente pode anexar evidência direta, online e verificável de que uma solicitação específica do cliente está vinculada a um objeto de resposta ou sequência de saída específica, sem alterar a semântica da API?

2. Metodologia e Design do Protocolo

O artigo propõe o AEX (Attestation Extension), uma extensão de protocolo não intrusiva para APIs de LLM baseadas em JSON. O design segue princípios rigorosos para garantir interoperabilidade e segurança:

• Não Intrusivo: AEX preserva a semântica existente de requisição, resposta, chamadas de ferramentas, streaming e erros. Ele adiciona apenas um objeto de atestação assinado no nível superior da resposta JSON.
• Vinculação de Solicitação (Request Binding):
  • O cliente escolhe o modo de vinculação: full (toda a requisição), top_level_exclude (excluindo campos específicos) ou top_level_include (incluindo apenas campos específicos).
  • Inclui mecanismos para detectar a injeção silenciosa de campos ausentes.
  • Suporta Reescrita de Solicitação Confiável: Intermediários confiáveis podem modificar a solicitação (ex: adicionar cabeçalhos de rastreamento) através de recibos assinados (request-transform receipts), mantendo a cadeia de prova intacta.
• Integridade de Streaming:
  • Utiliza uma cadeia de hash de dois âncoras (dual-anchor hash chain) para sequências de chunks JSON.
  • Distingue dois modos de prova de streaming:
    1. Prefixo de Stream de Origem: Prova que os chunks iniciais são uma versão não modificada da fonte.
    2. Genealogia de Saída Completa (Complete-Output Lineage): Se a saída foi reescrita, agregada ou reempacotada por um intermediário confiável, o protocolo prova a linhagem completa desde a saída original até a final, sem permitir provas de prefixo intermediárias que poderiam ser enganosas.
• Reescrita de Saída Confiável: Permite que gateways ou middleware modifiquem a saída (ex: redação de dados sensíveis, conversão de stream para objeto único) através de uma cadeia assinada de recibos de transformação (output-transform receipts), vinculando a saída original à final.
• Tecnologias Subjacentes:
  • Canonicalização JSON (JCS): Para garantir que a representação binária seja invariante a mudanças de ordem de campos ou espaços em branco.
  • Assinaturas Digitais: Ed25519.
  • Descoberta de Chaves: Baseada em conjuntos de chaves públicas (JWKS) publicadas pelo emissor.

3. Principais Contribuições

1. Formulação do Problema: Define claramente a necessidade de atestação na fronteira da API para serviços de LLM hospedados, motivada pela evidência de Shadow APIs.
2. Protocolo AEX: Apresenta um mecanismo de extensão que inclui compromissos de requisição, compromissos de saída completa, modos de vinculação explícitos e metadados de genealogia sensíveis ao modo de saída.
3. Mecanismos Específicos para LLM:
   • Cadeia de hash de streaming com duas âncoras.
   • Cadeia de recibos de transformação de requisição para intermediários confiáveis.
   • Modelo de recibos de origem/saída para reescrita de saída confiável.
4. Análise de Segurança e Privacidade: Posiciona o AEX contra abordagens vizinhas (assinatura de mensagens HTTP, TEE, fingerprinting), definindo claramente o que o protocolo prova (relação solicitante-resposta assinada) e o que não prova (veracidade factual, ausência de prompts ocultos).
5. Protótipo e Validação: Entrega um protótipo de referência em TypeScript, compatível com a API de chat-completions do OpenAI, incluindo testes de conformidade automatizados e microbenchmarks.

4. Resultados e Validação

• Protótipo: Um teste de laboratório foi implementado com um gateway, proxies confiáveis (que reescrevem requisições/saídas) e um simulador de provedor.
• Testes Automatizados: O protótipo passou por 29 testes unitários, 25 testes de integração e 6 testes end-to-end no navegador, cobrindo modos de vinculação, cadeias de transformação, verificações de streaming e estados de falha.
• Desempenho (Microbenchmarks):
  • Em cenários não-streaming, a latência de verificação no gateway foi de aproximadamente 0,5 ms.
  • Em cenários de streaming com cadeia de transformação, a verificação manteve-se baixa (~1,5 ms), mesmo com múltiplos fetchs de chaves JWKS.
  • O overhead criptográfico é considerado insignificante comparado aos atrasos de rede e de processamento do modelo.
• Cenários de Falha: O sistema detectou corretamente manipulações de payload, requisições não correspondentes, truncamento de stream e falta de atestação, fornecendo estados de erro estruturados (ex: tampered, request_mismatch, truncated_after_verified_prefix).

5. Significado e Impacto

O AEX preenche uma lacuna crítica na infraestrutura de confiança de LLMs:

• Viabilidade de Implantação: Ao não exigir mudanças na semântica do corpo da API ou no modelo subjacente, o AEX pode ser adotado incrementalmente por provedores existentes e SDKs.
• Distinção entre Ruído e Ataque: Permite que os sistemas distingam entre modificações maliciosas (que quebram a prova) e modificações legítimas de infraestrutura (que são atestadas através de recibos de transformação).
• Complementaridade: O AEX não substitui a atestação de TEE ou o fingerprinting, mas atua como uma camada de aplicação que vincula a identidade do provedor e a integridade da transação aos objetos de dados reais (JSON) que o cliente consome.
• Padronização Futura: O trabalho estabelece as bases para uma possível padronização de atestação de transações em APIs de IA, oferecendo um caminho prático para garantir a proveniência e a integridade em ecossistemas de LLM complexos e multi-tenants.

Em resumo, o AEX transforma a fronteira da API de um ponto cego de confiança em um ponto de verificação criptográfica, garantindo que o que o cliente pede é exatamente o que o provedor (ou sua cadeia confiável de intermediários) entregou.