Competicao de seguranca para agentes expoe 'lacuna de contexto de autorizacao': posse de token vira execucao indevida
Em um benchmark controlado de ataque a agentes (OpenClaw Agent Security Attack Competition), pesquisadores mostram que um agente pode ser guiado atraves de um fluxo de aprovacao localmente coerente -- sem nenhuma instrucao explicita de bypass de politica -- ate obter um token de aprovacao legitimo e usa-lo para executar uma acao que nao deveria ser autorizada. O padrao funcionou em tres alvos de documentos empresariais e se repetiu em 8 de 9 execucoes de validacao controlada.
Agentes de linguagem que usam ferramentas cada vez mais dependem de servicos locais para acesso a documentos, gerenciamento de aprovacoes e execucao de fluxos de trabalho corporativos. O ataque estudado aqui nao usa nenhuma instrucao explicita de 'ignore a politica anterior' -- a tecnica classica de prompt injection direta -- e sim conduz o agente atraves de um fluxo de aprovacao que parece legitimo passo a passo: uma solicitacao de documento protegido e negada, o agente entao solicita um token de aprovacao normal ao servico local de aprovacoes, e esse token retornado e repassado ao servico de documentos atraves do parametro 'authorized_by', que o servico aceita sem verificar mais nada.
O ponto tecnico central e o que os autores chamam de 'lacuna de contexto de autorizacao': o servico de documentos trata a mera posse de um token de aprovacao como autorizacao suficiente, sem checar conjuntamente se a identidade do solicitante, a autoridade de quem aprovou, o escopo do recurso, o tipo de acao e o destinatario final sao todos consistentes entre si. Ou seja, um token emitido legitimamente para um proposito pode ser reaproveitado para autorizar uma acao totalmente diferente, porque o sistema nunca vincula o token ao contexto especifico em que foi emitido.
Os tracos oficiais de submissao da competicao mostram esse padrao funcionando em tres alvos de documentos da categoria 'Enterprise OA'. Os pesquisadores tambem conduziram 23 experimentos de validacao controlada no ambiente oficial de execucao do OpenClaw: a configuracao original alcancou a transicao de token de aprovacao em 9 de 9 repeticoes e completou a operacao-alvo exata em 8 de 9 repeticoes, e variantes com apenas um componente alterado se mantiveram bem-sucedidas contra os tres alvos de documento testados -- uma taxa de sucesso alta o suficiente para indicar um padrao estrutural, nao um acaso de configuracao especifica.
Isso e relevante para qualquer arquitetura de agente que integre servicos de aprovacao e execucao como pecas separadas conectadas por tokens: o problema nao esta em nenhum dos dois servicos isoladamente, mas na ausencia de vinculacao de contexto entre eles. Os autores propoem como mitigacao tokens vinculados a contexto (context-bound tokens), aplicacao de politica no lado do servico (nao apenas confiar no token apresentado), checagens de autorizacao tambem no lado do agente, e desenho de benchmarks que incluam rastreamento completo da cadeia de aprovacao -- recomendacoes diretamente aplicaveis a qualquer equipe que esteja conectando agentes de LLM a sistemas internos de aprovacao e fluxo de trabalho.