Resumo Técnico: Integridade de Contexto-para-Execução (CXI) para Agentes de LLM

1. Declaração do Problema

Agentes de Grandes Modelos de Linguagem (LLM) operam cada vez mais lendo contextos passíveis de escrita por atacantes (ex: logs de CI, comentários de issues, fragmentos de recuperação, saídas de ferramentas) para propor ações que disparam efeitos colaterais no mundo real (ex: escrita de arquivos, consultas a bancos de dados, chamadas de API). A falha central de segurança identificada é a lavagem de autoridade (authority laundering): um sistema onde texto não confiável, que deveria servir apenas como evidência, ganha a autoridade para selecionar ferramentas, autorizar operações ou parametrizar efeitos colaterais privilegiados.

As abordagens de segurança atuais frequentemente dependem de validação de esquema ou confiança na chamada completa, o que é insuficiente. Uma chamada de ferramenta pode ser sintaticamente válida (estrutura JSON correta), enquanto seus campos semânticos (ex: tool, operation, approval_state) são derivados de fontes não confiáveis. O artigo argumenta que a fronteira de segurança deve mudar de "o texto é plausível?" para "o valor específico em cada campo protegido possui a autoridade necessária para executar este efeito colateral específico?".

2. Metodologia: Integridade de Contexto-para-Execução (CXI)

CXI é um sistema de fronteira de execução projetado para mediar a transição da proposta do modelo para a execução do sink (destino). Ele impõe uma política de admissão estrita onde um efeito colateral ocorre apenas se três componentes distintos de autoridade se vincularem ao mesmo manifesto de ação canônico:

1. Autoridade de Campo: Campos protegidos do sink (ex: caminhos de arquivos, nomes de ferramentas) devem ser autorizados.
2. Autoridade de Efeito: Payloads interpretados pelo sink (ex: patches, SQL, comandos shell) devem ser autorizados para seu efeito semântico específico.
3. Autoridade de Invocação: O evento de chamar o sink (incluindo tentativas de reexecução, agrupamento e agendamento) deve ser autorizado.

Mecanismos Principais

• Liberações Tipadas (D): O contexto passível de escrita não confiável ($W$) não pode autorizar diretamente campos protegidos ($X$). Em vez disso, código confiável (desclassificadores) deve validar $W$ e cunhar uma Liberação Tipada estreita e com escopo de destino. Por exemplo, uma linha de log pode ser validada para produzir uma liberação de FilePath para o argumento file_path, mas esse mesmo texto não pode autorizar a seleção da tool.
• Dados Opacos (O): Texto não confiável pode ser copiado para "slots de dados opacos" para fins de evidência (ex: comentários, logs), mas não carrega autoridade. Se esses dados reentrarem em uma fronteira de efeito colateral posteriormente, são tratados como contexto passível de escrita novamente.
• Autorização de Efeito Exato: Para payloads construtivos (patches, SQL, YAML de CI), o sistema não verifica apenas os bytes do payload. Ele utiliza Adaptadores de Efeito para computar o efeito semântico exato que o sink aplicará sob um snapshot confiável (ex: estado do repositório, época da política). A execução é vinculada a este compromisso de efeito específico.
• Portão Vinculado ao Manifesto: Um portão determinístico canonicaliza a ação proposta em um Manifesto de Ação. Este manifesto registra o nonce da ação, digests de evidência de campos, digests de autorização de efeito e digests de autoridade de chamada.
• Capacidades de Invocação: O portão consome uma Capacidade de Invocação vinculada ao manifesto (um contrato de arrendamento linearizável) antes da execução. Isso evita ataques de replay, tentativas de reexecução não autorizadas ou mudanças na cardinalidade de lote (batching).

Proveniência e Evidência

O CXI rastreia a proveniência da influência, não apenas a origem dos bytes.

• Caminho de Pesos Abertos (Open-Weight): Para modelos com acesso ao estado interno (ex: vLLM), o sistema gera registros de evidência de backend que vinculam a decodificação de campos protegidos a intervalos de tokens e máscaras de atenção específicos, garantindo que nenhum contexto não confiável influenciou a geração do campo protegido.
• Caminho Hospedado/API: Para APIs onde o estado interno é oculto, o sistema depende de evidência de construção local ao campo. Aqui, o host garante que os escritores de campos vejam apenas o estado confiável e liberações tipadas válidas, enquanto o dado opaco é excluído do contexto do escritor.

3. Principais Contribuições

O artigo define e avalia três contribuições primárias:

1. Definição de CXI: Um requisito formal de que as seleções protegidas, os efeitos interpretados pelo sink e os eventos de invocação devem cada um carregar autoridade para a mesma ação canônica antes que uma proposta de modelo se torne executável.
2. Sistema de Admissão Vinculado ao Manifesto: Um design que compõe evidência de campo protegido, autorização de efeito exato e capacidades de invocação consumíveis em uma única decisão de sink, aplicada por um portão determinístico.
3. Avaliação Abrangente: Uma avaliação através de caminhos de projeção de campo de pesos abertos, episódios ao vivo do AgentDojo, um benchmark de efeito exato de agente de código, injeção de falhas de razão (ledger) e traços de compatibilidade de API/hospedado.

4. Resultados da Avaliação

A avaliação separa a utilidade da tarefa (o agente resolveu o problema?) da integridade de admissão (autoridade não autorizada cruzou a fronteira?).

• Episódios ao Vivo do AgentDojo: Em 720 episódios ao vivo e 1.739 chamadas de LLM, o CXI observou zero escapes de campo, efeito ou invocação em admissões protegidas.
• Benchmark de Efeito Exato de Agente de Código: Em 400 episódios de repositório, o sistema gerou 231 conclusões de tarefas seguras. Crucialmente, houve zero escapes observados de campo, efeito ou invocação.
  • Nota sobre Falhas: As não-conclusões foram atribuídas a falhas de parsing (73 casos), falta de autorização de efeito (61 casos) ou problemas de qualidade da tarefa (35 casos), não a brechas de segurança.
• Pressão de Proposta: O sistema observou significativa "pressão de proposta", onde modelos tentaram selecionar campos não autorizados (ex: 196/300 propostas não autorizadas em cenários adversariais de utilidade). No entanto, o portão bloqueou com sucesso todas as tentativas, resultando em zero execuções de escape.
• Falhas de Razão (Ledger Faults): Em testes de razão vinculados ao manifesto, o sistema rejeitou com sucesso admissões duplicadas e suprimiu gastos duplos (double-spends), confirmando a integridade do consumo da capacidade de invocação.
• Comparação com Baselines:
  • Validação apenas de esquema: Permitiu 100% das execuções não autorizadas (valores derivados de W preencheram campos protegidos).
  • Aproximações de proveniência de papel de argumento: Falharam em bloquear falhas de evento de chamada e de vínculo de backend.
  • CXI: Bloqueou 20/20 casos de ataque enquanto preservou 6/6 casos de utilidade em baselines de mecanismo.

5. Significância e Alegações

O artigo posiciona o CXI como uma propriedade de sistemas concreta para sinks mediados, em vez de uma solução geral para todos os problemas de segurança de agentes.

• Fronteira Explícita: O CXI torna a transição de contexto para execução explícita, verificável e com falha segura (fail-closed). Não pretende tornar os validadores completos, as tarefas corretas ou os internos do provedor observáveis; em vez disso, garante que, se uma ação é executada, é porque a cadeia de autoridade específica para aquela ação está completa.
• Escopo Modesto: Os autores afirmam explicitamente que a qualidade da tarefa, a completude do validador e a entrega de entrega exata externa são obrigações separadas. O CXI garante que a autoridade para executar seja correta, não que o conteúdo da execução seja desejável ou que o raciocínio do modelo seja sólido.
• Centrado em Política: O sistema depende de trabalho de política confiável (classificação de campos, contratos de desclassificador, validadores de efeito). Ele não infere política ausente; se um campo não é classificado ou um sink não é mediado, a garantia não se sustenta.
• Variância de Evidência: O artigo reconhece que a evidência difere por regime de implantação. Implantações de pesos abertos podem provar a aplicação de backend via máscaras de atenção, enquanto implantações hospedadas/API podem apenas provar fronteiras de construção observadas pelo host. Ambos, no entanto, alimentam a mesma lógica de portão vinculado ao manifesto.

Em resumo, o CXI fornece um mecanismo para evitar a lavagem de autoridade ao garantir que o texto não confiável possa influenciar efeitos colaterais apenas através de canais explicitamente validados e com escopo (liberações tipadas, compromissos de efeito exato e capacidades de invocação) que estão vinculados a um único manifesto de ação canônico.