Resumo Técnico: SecureClaw

Declaração do Problema

Agentes de Grandes Modelos de Linguagem (LLMs) que utilizam ferramentas enfrentam dois modos de falha de segurança distintos e não intercambiáveis que as defesas existentes frequentemente não conseguem abordar simultaneamente:

1. Efeitos Externos Não Autorizados: O risco de um agente, potencialmente comprometido por injeção de prompt ou comportamento de tempo de execução adversário, executar ações (ex: enviar e-mails, transferir fundos) que não foram autorizadas para o contexto, sessão ou chamador específico.
2. Exposição de Texto Simples em Tempo de Execução: O risco de dados sensíveis (ex: faturas, registros médicos) serem expostos ao tempo de execução não confiável do LLM em texto simples. Mesmo que uma ação subsequente seja bloqueada, o tempo de execução pode já ter "lido" o segredo e pode transmiti-lo através de canais internos (mensagens entre agentes, memória compartilhada, logs) que os mecanismos de auditoria apenas de saída não detectam.

As defesas atuais tipicamente protegem apenas uma fronteira: ou o planejador/tempo de execução (via filtragem de prompt) ou o sumidouro da ação (via verificação de argumentos). O artigo argumenta que proteger o sumidouro não evita o vazamento interno se o tempo de execução já tiver acessado os segredos brutos, e proteger o tempo de execução não evita commits não autorizados se o sumidouro for não mediado.

Metodologia: Arquitetura SecureClaw

O SecureClaw introduz uma arquitetura de dupla fronteira que separa o controle de efeitos externos do acesso a dados sensíveis em texto simples. Ele depende de uma infraestrutura confiável (Gateway, Armazenamento de Handles, Mecanismo de Política, Executor) distinta do tempo de execução não confiável do agente.

1. Caminho de Leitura: Confinamento de Handle Opaco

• Mecanismo: Quando o tempo de execução solicita dados sensíveis, um Gateway Confiável intercepta a leitura. Em vez de retornar o texto simples bruto, o gateway armazena os dados em um Armazenamento de Handles Confiável e retorna um handle opaco (uma referência simbólica de alta entropia) ao tempo de execução.
• Desclassificação: Se o agente exigir informações relevantes para a tarefa para planejar, o gateway fornece um resumo limitado (ex: "fatura do Fornecedor A, $4,2k"). Este resumo é tratado como uma interface de desclassificação explícita, não como um vazamento de texto simples.
• Restrição: O tempo de execução pode rotear e armazenar handles, mas não pode desreferenciá-los para recuperar segredos brutos. Canais internos (C2, C5) carregam referências simbólicas, não segredos.

2. Caminho de Escrita: Protocolo PREVIEW→COMMIT

• Mecanismo: O tempo de execução propõe uma ação com efeito (intenção + entradas). Um Gateway Confiável anexa contexto autenticado (chamador, sessão, campos do sumidouro) e canonicaliza a requisição em um digest de ligação ($h$).
• Autorização: Um Mecanismo de Política autoriza a requisição canônica exata e retorna um artefato de autorização vinculado a $h$.
• Execução: Um Executor Confiável é o único componente capaz de alcançar o sumidouro externo. Antes de realizar o commit, ele:
  1. Recalcula o digest de ligação $h$.
  2. Verifica o artefato de autorização.
  3. Verifica o frescor, o status de replay e a resolução do handle.
  4. Realiza o commit apenas se a requisição corresponder exatamente à forma canônica autorizada.
• Integridade: Qualquer mutação na requisição (ex: alterar um destinatário) após o preview altera a forma canônica, invalidando o artefato de autorização e fazendo o executor falhar de forma segura (fail-closed).

3. Recuperação Consciente de Negação

Para manter a utilidade quando as ações são bloqueadas, o sistema emprega um mecanismo de recuperação consciente de negação. Em vez de encerrar o fluxo de trabalho, o sistema retorna uma negação estruturada com um motivo genérico e uma dica de próximo passo segura (ex: "rascunho para confirmação" em vez de "enviar"), preservando a continuidade do fluxo de trabalho sem relaxar os invariantes de segurança.

Principais Contribuições

1. Decomposição de Segurança: O artigo identifica dois requisitos de segurança não substituíveis para agentes que utilizam ferramentas: autorização vinculada à requisição de efeitos externos e confinamento de texto simples sensível longe do tempo de execução não confiável.
2. Arquitetura de Dupla Fronteira: O SecureClaw implementa esses requisitos via um gateway confiável (para confinamento de leitura) e um executor confiável (para autorização de escrita), utilizando handles opacos e desclassificação explícita.
3. Avaliação de Harness Comum: Os autores avaliam o SecureClaw contra quatro baselines (Plain, IPIGuard, DRIFT, Faramesh) através de três benchmarks (AgentDojo, AgentLeak, ASB) usando um harness correspondente para garantir uma comparação justa.

Resultados Experimentais

Avaliado em gpt-4o-mini com temperatura 0:

• Agent Security Bench (ASB): O SecureClaw alcançou 0% de Taxa de Sucesso de Ataque (ASR), superando significativamente as baselines (ex: DRIFT com 87,75% de ASR). Manteve 88,90% de utilidade em tarefas benignas.
• AgentDojo: Alcançou 0,64% de ASR (4/629 ataques), comparado a 2,38% para a próxima melhor baseline (DRIFT).
• AgentLeak: Alcançou 3,23% de vazamento total na lane de paridade atacada. Crucialmente, reduziu os vazamentos de retransmissão interna (C2 e C5) para quase zero (0,20% e 0,00% respectivamente), enquanto baselines como Faramesh (que carece de confinamento de leitura) mostraram alto vazamento interno (92,74% em C2).
• Estudos de Ablação: Remover o mecanismo de handle fez o vazamento C2/C5 reaparecer, enquanto remover a fronteira de execução não afetou o vazamento interno, mas falhou em impedir commits não autorizados. Isso confirma que os dois mecanismos protegem superfícies distintas.
• Robustez: Em um conjunto de bypass de 29 cenários adversários (tampering de artefatos, replay, mistura de sessões), o SecureClaw negou todas as 25 tentativas de ataque enquanto permitiu 4 controles legítimos.
• Overhead: A verificação do executor é de sub-milissegundo; a autorização de serviço único adiciona cerca de ~15ms. Esses custos são insignificantes comparados às latências de inferência de LLM (500–2000ms).

Significância e Alegações

O artigo alega que assegurar agentes de LLM requer separação estrutural em vez de defesas locais de tempo de execução.

• Não Substituibilidade: A avaliação demonstra que a autorização no lado do sumidouro e o confinamento no lado da leitura são complementares; um commit bloqueado não pode desfazer um segredo já transmitido através da memória, e um handle não pode impedir um tempo de execução comprometido de tentar ações não autorizadas.
• Modelo de Confiança: O SecureClaw transfere a confiança do tempo de execução não confiável para um conjunto mínimo de componentes confiáveis (Gateway, Armazenamento de Handles, Mecanismo de Política, Executor). Não pretende garantir a correção semântica de ações permitidas pela política (ex: se uma política for muito genérica, o agente ainda pode agir sobre o objeto errado), nem sobreviver ao comprometimento de seus componentes confiáveis.
• Residuais: As falhas restantes concentram-se no plano de desclassificação (resumos autorizados revelando informações) ou desalinhamento de política (ações autorizadas que são semanticamente erradas para a intenção do usuário), em vez de bypasses dos invariantes de segurança principais.

Os autores concluem que o SecureClaw é o único sistema avaliado em seu estudo que simultaneamente leva efeitos externos não autorizados a zero/quase zero e elimina a retransmissão de texto simples interno, mantendo alta utilidade de tarefa através da recuperação consciente de negação.