Resumo Técnico: aiAuthZ – Autorização Fora do Host e Vinculada à Identidade para Agentes de IA

1. Declaração do Problema

Agentes de IA com acesso a ferramentas traduzem linguagem natural em ações (ex: operações de arquivos, chamadas de API, comandos de shell). A segurança dessas ações depende de duas perguntas: Quem está pedindo? e Eles têm permissão para realizar esta ação?

Sistemas atuais frequentemente respondem a essas perguntas de forma probabilística dentro do próprio modelo, instruindo-o a seguir políticas. Essa abordagem é frágil devido à injeção de prompt indireta, onde um adversário controla o texto que o modelo lê (ex: documentos recuperados, páginas da web ou mensagens de outros usuários) para forjar a aparência de autoridade. O artigo demonstra que:

• As taxas de recusa do modelo variam significamente entre diferentes modelos (de 100% a 38%) para ataques idênticos.
• A recusa não se correlaciona com o custo do modelo; os modelos mais caros avaliados recusaram apenas 50% dos ataques.
• Defesas que residem no mesmo processo ou domínio de confiança que o agente (ex: controle de privilégio in-process) são comprometidas se o contexto do agente for manipulado.

2. Metodologia e Arquitetura

O artigo propõe o aiAuthZ, um gateway de autorização que move as decisões de segurança para fora do host do agente e para um domínio de confiança separado e não confiável. O sistema opera via Protocolo de Contexto de Modelo (MCP) ou HTTP puro.

Componentes Principais

• Fronteira de Confiança Fora do Host (Off-Host): O gateway, o banco de dados de políticas, as chaves do usuário e o corretor de segredos residem em uma infraestrutura onde o agente não possui credenciais. O agente é tratado como um emissor não confiável de requisições.
• Identidade por Mensagem:
  • Cada mensagem do usuário é assinada com um HMAC-SHA256 sobre uma codificação JSON canônica do ID do usuário, ID da sessão, hash do conteúdo da mensagem, um nonce de uso único e um timestamp.
  • O gateway verifica a assinatura, checa o nonce (para evitar replay) e valida a janela de tempo.
  • Vinculação de Sessão: O usuário ativo da sessão é vinculado à mensagem humana verificada mais recente, não a um token de longa duração. As chamadas de ferramenta devem ecoar o identificador desta mensagem verificada.
• Avaliação de Política Fora do Host:
  • As políticas são documentos YAML avaliados no gateway. O agente não pode ler ou modificar as políticas.
  • Três Portões (Gates):
    1. Portão de Função (Role Gate): Verifica se a função do usuário (proprietário, membro, convidado, sistema) tem permissão para invocar a ferramenta específica.
    2. Restrições de Argumentos: Impõe listas de permissão/bloqueio (allowlists/denylists) para caminhos de arquivos, URLs, destinatários e tamanhos de payload de escrita.
    3. Limites de Taxa (Rate Limits): Impõe limites de chamadas por ferramenta e por workspace.
• Auditoria com Evidência de Adulteração: Cada decisão é anexada a um log de auditoria encadeado por hash SHA-256. A retenção de dados utiliza "cripto-apagamento" (crypto-erasure), onde os payloads criptografados são limpos, mas a estrutura da cadeia permanece intacta para preservar a auditabilidade.
• Recibos Sobreviventes: Ações autorizadas geram um código QR autenticado por HMAC. O recibo é projetado para permanecer verificável após recompressão (JPEG), redimensionamento, captura de tela e recorte, ao contrário de assinaturas digitais destacadas ou marcas d'água padrão.
• Corretor de Credenciais (Credential Broker): Segredos de API são injetados apenas após a autorização. O host do agente não possui credenciais de longa duração, impedindo que um agente comprometido acesse segredos diretamente.

3. Principais Contribuições

O artigo afirma não propor novas primitivas criptográficas, mas contribui com uma composição específica de técnicas estabelecidas na granularidade de mensagens individuais:

1. Camada de Identidade por Mensagem: Vincula uma assinatura, nonce e timestamp a cada mensagem do usuário, garantindo que a autoridade da chamada de ferramenta derive da última vez de interação humana verificada, em vez de um contexto não confiável.
2. Política Fora do Host: Um mecanismo de política avaliado em um host inacessível ao agente, combinando listas de permissão baseadas em funções com restrições de nível de argumento.
3. Cadeia de Auditoria com Cripto-Apagamento: Um log encadeado por hash que suporta a exclusão de dados regulatórios (limpeza de payloads) sem quebrar a trilha de auditoria.
4. Recibos de Ação Robustos: Um recibo via QR que sobrevive ao manuseio do mundo real (capturas de tela, compressão) onde outros métodos de proveniência falham.
5. Corretor de Credenciais: Um mecanismo para garantir que hosts de agentes comprometidos não acessem segredos.
6. Avaliação Reprodutível: Um benchmark abrangendo 15 modelos, a suíte AgentDojo e o corpus "Agents of Chaos".

4. Resultados Experimentais

Segurança do Modelo vs. Gateway

• Recusa do Modelo: Em 15 modelos e 8 cenários de ataque, as taxas de recusa variaram de 100% a 38%. O modelo mais caro avaliado recusou apenas 50% dos ataques.
• Eficácia do Gateway: Com o aiAuthZ implementado, o sucesso residual de ataques caiu para 0% para todos os 15 modelos. O gateway bloqueou deterministicamente todas as chamadas de ferramentas perigosas ao negar as funções exclusivas de proprietário ou as restrições de argumentos.
• Latência: A latência de decisão adicionada foi insignificante, variando de 0,006 ms a 0,030 ms (aproximadamente 5 ordens de magnitude mais rápida que uma chamada de modelo).

Estudos de Caso e Benchmarks

• Corpus Agents of Chaos: Em 9 estudos de caso dentro do escopo (cobrindo falsificação de identidade, conformidade não autorizada e exfiltração de dados), o aiAuthZ bloqueou 9/9 ataques.
  • Comparação com uma política de "apenas argumentos" (estilo Open Agent Passport) bloqueou apenas 4/9.
  • Comparação com um design de "token de delegação" (estilo Agent Identity Protocol) bloqueou 0/9.
  • O componente de identidade por mensagem foi crítico para bloquear ataques de falsificação de identidade que as políticas de apenas argumentos perderam.
• Suíte Bancária AgentDojo: O gateway bloqueou todas as 7 chamadas de ferramentas direcionadas por atacantes (pagamentos, redirecionamentos, mudanças de senha).
  • Compromisso (Trade-off): Um pagamento legítimo de primeira vez para um novo beneficiário foi bloqueado devido às listas de permissão estritas, reduzindo a utilidade limpa de 100% para 80%.
• Degradação de Contexto Longo: À medida que o comprimento do contexto aumentava (até 48k tokens), as taxas de recusa do modelo para instruções de exfiltração enterradas diminuíram (alguns modelos começaram a cumprir). O veredito do gateway permaneceu invariante ao comprimento do contexto, bloqueando todas as 12 tentativas observadas.
• Robustez do Recibo: O recibo QR assinado alcançou 94% de média de verificação através de 8 canais de transmissão (incluindo compressão JPEG e capturas de tela). Em contraste, as assinaturas Ed25519 destacadas falharam completamente após a reencodificação, e as marcas d'água incorporadas falharam sob transformações geométricas (recorte/redimensionamento).

5. Significância e Limitações

Significância:
O artigo argumenta que, embora os modelos não possam ser confiáveis para autenticar o contexto, um domínio de confiança separado pode aplicar autorização de forma determinística. O sistema fecha a lacuna entre "quem está pedindo" e "o que eles têm permissão para fazer" sem depender do comportamento do modelo. Ele aborda especificamente o modo de falha onde um agente é enganado por um prompt injetado, mas ainda age dentro dos limites da identidade real do usuário verificada.

Limitações (conforme declarado pelos autores):

• Não é um Detector de Injeção de Prompt: O texto injetado passa pelo sistema; a defesa é que a injeção não pode alterar a identidade vinculada.
• Risco de Bypass: Se um ambiente de execução de agente mantiver ferramentas integradas sobrepostas (ex: um shell local) que ignorem o gateway, o sistema pode ser contornado. O artigo enfatiza que fechar esse bypass é uma obrigação de implementação (usando verificadores de conformidade e bloqueio de saída), não um recurso automático.
• Ataques de Composição: Uma sequência de chamadas individualmente permitidas ainda pode se compor em um resultado indesejado.
• Não-Repúdio: O sistema usa HMACs simétricos para baixa latência. Embora o gateway possa verificar a autenticidade, ele não fornece não-repúdio para terceiros (ao contrário de assinaturas de chave pública) porque o gateway detém a chave.
• Escopo: Não impede a geração de conteúdo prejudicial, alucinações de resultados de ferramentas ou usuários autorizados tomando decisões destrutivas que lhes são permitidas.

Os autores concluem que o aiAuthZ ocupa uma fenda específica na pilha de segurança, complementando defesas in-process e salvaguardas de conteúdo ao fornecer uma camada de autorização fora do host com um rastro de auditoria sobrevivente.