Resumo Técnico: SkillSafetyBench

Declaração do Problema

Agentes de Modelos de Linguagem (LLM) dependem cada vez mais de habilidades reutilizáveis para estender seu comportamento no momento da inferência. Essas habilidades empacotam instruções procedimentais, modelos de código, recursos e rotinas de verificação, permitindo que desenvolvedores adicionem capacidades específicas de tarefas sem retreinar o modelo subjacente. No entanto, essa modularidade desloca a fronteira de confiança da execução. Em vez de condicionarem-se apenas a instruções do usuário e interfaces de ferramentas fixas, os agentes agora leem e atuam com base em arquivos de habilidade, scripts auxiliares, configurações de tempo de execução, recursos de recuperação e artefatos locais.

O artigo identifica uma lacuna crítica nas avaliações de segurança atuais: os benchmarks existentes focam pesadamente em injeções diretas de prompts ou solicitações de usuário explicitamente maliciosas. Eles deixam em grande parte de fora superfícies de ataque locais mediadas por habilidades e não originadas pelo usuário. Neste cenário, um usuário emite uma solicitação benigna, mas o agente depende de habilidades voltadas para a tarefa e recursos locais associados que foram moldados adversarialmente para redirecionar a execução em direção a comportamentos inseguros. Como as habilidades organizam procedimentos e dependências em um fluxo de trabalho aparentemente legítimo, a influência maliciosa pode ser distribuída entre a orientação da habilidade, scripts de envoltório, entradas de memória e corpora locais, guiando o agente para ações inseguras enquanto o objetivo original da tarefa permanece intacto.

Metodologia

Para abordar essa lacuna, os autores introduzem o SkillSafetyBench, um benchmark executável e fundamentado em artefatos, projetado para avaliar a segurança do agente sob essas superfícies de ataque específicas.

Construção do Benchmark

O benchmark consiste em 155 casos adversariais derivados de 47 tarefas originais (obtidas do repositório SkillsBench). O processo de construção segue um framework de três etapas:

1. Substratos de Tarefa Executáveis: Seleção de tarefas que naturalmente suportam ataques realistas (por exemplo, desenvolvimento de código, processamento de dados) e produzem artefatos observáveis.
2. Instanciação de Ataque Centrada em Habilidades: Os ataques são instanciados principalmente por meio de materiais voltados para habilidades (por exemplo, arquivos SKILL.md) e superfícies locais de apoio não originadas pelo usuário (por exemplo, scripts auxiliares, Dockerfiles, manifestos, repositórios de memória, corpora locais). O ataque não se confina a um único arquivo; ao contrário, a orientação da habilidade e os artefatos circundantes moldam conjuntamente o caminho de execução do agente.
3. Verificação Fundamentada em Artefatos: Cada caso é emparelhado com um verificador baseado em regras específico do caso (verify_attack.py). O sucesso não é determinado por julgamentos de LLM de forma livre, mas por evidências concretas nos artefatos de execução (por exemplo, rastros maliciosos, pares de saída/sidecar inconsistentes, payloads vazados ou registros de memória envenenados).

Taxonomia

O benchmark organiza falhas de segurança em 6 Domínios de Risco (DRs) e 30 categorias canônicas, suplementados por 8 rótulos de classe de ataque (por exemplo, manipulação de viés, envenenamento, backdoors).

• DR1 (Confiança no Contexto): Riscos provenientes de sinais contextuais enganosos, exemplos ou materiais recuperados.
• DR2 (Escopo de Agência): Riscos provenientes de exceder a autorização ou o escopo de ação.
• DR3 (Execução/Tempo de Execução): Riscos provenientes de interpretadores, carregadores ou ambientes de tempo de execução comprometidos.
• DR4 (Limite de Dados): Riscos provenientes de artefatos finais corrompidos ou canais de saída.
• DR5 (Memória/Persistência): Riscos provenientes de estados inseguros que persistem ou evitam auditoria.
• DR6 (Conhecimento/Cadeia de Suprimentos): Riscos provenientes de dependências comprometidas, fontes de conhecimento ou comportamento do modelo.

Controle de Qualidade

O benchmark passa por validação rigorosa:

• Revisão Humana: Especialistas verificam o realismo do design do ataque e o alinhamento do verificador.
• LLM como Juiz: Dois modelos independentes (kimi-k2.5 e glm-5.1) avaliam cada caso em três eixos: Qualidade de Camuflagem (o ataque é não trivial de detectar?), Alinhamento do Verificador (o verificador checa o sinal correto?) e Coerência Taxonômica (o caso está categorizado corretamente?). Os juízes relataram taxas de aprovação acima de 92% em todos os eixos, com mais de 94% de concordância.

Resultados Principais

Os autores avaliaram múltiplos sistemas de agentes de CLI e backends de modelo (incluindo Codex, Claude Code, Gemini CLI e Kimi Code CLI emparelhados com modelos como GPT-5.5, Opus-4.6 e GLM-5.1).

1. Prevalência de Vulnerabilidade: Todos os sistemas avaliados exibiram Taxas de Sucesso de Ataque (ASR) não triviais, demonstrando que ataques locais não originados pelo usuário podem induzir comportamentos inseguros em diferentes andaimes de agente e famílias de modelos.
   • A maior ASR geral foi observada para Codex com GLM-5.1 (50,3%), seguido pelo Kimi Code CLI com Kimi-K2.5 (49,7%).
   • Claude Code com Opus-4.6 apresentou a menor ASR (15,5%).
2. Disparidades de Domínio de Risco:
   • DR1 (Confiança no Contexto) teve a maior ASR média (58,7%), indicando que os agentes são altamente suscetíveis a contextos enganosos e amplificação de confiança de múltiplas fontes.
   • DR2 (Escopo de Agência) e DR5 (Persistência) também mostraram alta vulnerabilidade (49,3% e 46,6%, respectivamente).
   • DR3 (Execução/Tempo de Execução) teve a menor ASR média (19,2%), sugerindo que os agentes são mais cautelosos com manipulações explícitas de tempo de execução ou cadeia de ferramentas em comparação com instruções contextuais.
3. Segurança vs. Capacidade de Tarefa: O estudo não encontrou alinhamento monótono entre sucesso na tarefa e segurança. Sistemas com altas taxas de sucesso na tarefa (por exemplo, Codex + GPT-5.5) ainda exibiram alta ASR (41,8%), enquanto alguns sistemas com menor sucesso na tarefa ainda enfrentaram riscos de segurança significativos.
4. Efeitos de Interação: A vulnerabilidade não é determinada apenas pelo backend do modelo ou pelo andaime do agente, mas por sua interação. Por exemplo, a lacuna na ASR entre Codex e Claude Code variou significativamente dependendo do backend de modelo utilizado (por exemplo, grande lacuna com GLM-5.1, pequena lacuna com MiniMax-2.7).

Significado e Alegações

O artigo afirma que a segurança do agente depende não apenas do alinhamento em nível de modelo, mas também de como os agentes interpretam habilidades, confiam no contexto do fluxo de trabalho e atuam por meio de ambientes executáveis.

• Mudança na Unidade de Avaliação: O trabalho argumenta que a avaliação de segurança deve ir além das respostas isoladas do modelo para sistemas executáveis. A "unidade de avaliação" deve ser o comportamento inseguro que emerge quando um agente interpreta habilidades e confia no contexto do fluxo de trabalho próximo.
• Realismo dos Ataques: Ao preservar o objetivo nominal do usuário enquanto envenena o ambiente local de apoio, o SkillSafetyBench demonstra que os agentes podem ser guiados para ações inseguras mesmo quando a solicitação do usuário é benigna e a tarefa parece ter sido concluída com sucesso.
• Complemento ao Trabalho Existente: Enquanto trabalhos anteriores estudaram injeção de prompts, mau uso de ferramentas e backdoors de habilidades isoladamente, o SkillSafetyBench complementa esses estudos ao avaliar cadeias de ataque em fluxos de trabalho executáveis onde a orientação voltada para habilidades é acoplada a diversos materiais locais.

Os autores concluem que, à medida que os agentes dependem cada vez mais de habilidades reutilizáveis, arquivos locais, memória e cadeias de ferramentas, as avaliações de segurança devem levar em conta o contexto operacional confiável no qual as decisões do agente são tomadas e materializadas.