LLM agents safety: como avaliar riscos em 2026

TL;DR

Em 2026, avaliar segurança de LLM agents deixou de ser só validar a resposta final. O foco migrou para trajetórias multi-turn, uso de ferramentas e mudanças de estado no ambiente, porque é aí que surgem falhas reais de segurança.

O caso mais representativo do recorte é o OpenAgentSafety, um framework acadêmico que combina checagens determinísticas com julgamento assistido por LLM para capturar tanto ações nocivas quanto tentativas e intenções inseguras. Para times brasileiros, isso importa porque o custo de um erro de agente em produção não é abstrato: ele pode afetar fluxos com dados sensíveis cobertos pela LGPD e integrações internas com ferramentas de negócio.

O que mudou na avaliação de segurança

O ponto central é simples: um agent não deve ser avaliado como se fosse apenas um chatbot. O brief mostra que a superfície de risco em 2026 passou a incluir browser, filesystem, terminal bash, execução de código e mensageria, ou seja, ferramentas que podem alterar o mundo fora do texto. Isso desloca o alvo da avaliação do último token para a sequência completa de ações.

Na prática, isso muda o tipo de pergunta que o time faz ao rodar um eval. Em vez de “a resposta soou segura?”, a pergunta vira “o agent tentou apagar, vazar, burlar ou manipular algo ao longo da tarefa?”. Essa mudança é consistente com a descrição do OpenAgentSafety, que foi aceito no ICLR 2026 e foi desenhado para cenários reais com ferramentas.

Por que single-turn não basta

Em um cenário simples de prompt safety, o modelo pode recusar uma instrução perigosa e ainda assim ser considerado seguro. Em um agent, porém, a sequência conta: ele pode abrir páginas indevidas, consultar arquivos errados, tentar uma ação proibida e só depois produzir uma saída aparentemente neutra. É por isso que a avaliação por trajetória ganhou relevância.

Essa diferença é importante para quem monta produto de IA em empresas brasileiras, onde o agente costuma tocar rotinas de atendimento, suporte interno, análise de documentos ou automação operacional. Em ambientes assim, um erro raro pode ser mais caro que uma resposta textual ruim, porque o dano vem da ação executada, não do tom da mensagem.

Como frameworks de 2026 fazem a checagem

O OpenAgentSafety organiza a avaliação em um formato híbrido. Parte do score vem de regras que observam o estado do ambiente e detectam mudanças nocivas de forma determinística. A outra parte usa LLM-as-a-judge para interpretar raciocínio, detectar tentativa e capturar sinais mais sutis que regras simples não pegam.

Essa combinação é útil porque nem todo comportamento inseguro termina em um resultado materializado. Um agent pode tentar algo errado e falhar por limite do ambiente, permissão negada ou intervenção de outro componente. O artigo em HTML do OpenAgentSafety descreve essa lógica híbrida justamente para cobrir tanto o dano efetivo quanto a intenção manifestada na trajetória.

Checagem baseada em estado

Quando a avaliação olha para o estado do ambiente, ela consegue responder perguntas mais concretas. Exemplo: o arquivo foi apagado? O conteúdo foi modificado? A postagem foi enviada? O objeto foi movido para um local proibido? Esse tipo de verificação é muito mais próximo do que um time de segurança precisa medir em produção.

O ganho aqui é operacional. Em vez de depender apenas de match semântico em texto, o benchmark observa sinais observáveis no ambiente. Isso reduz ambiguidade e aproxima o eval da realidade de um produto com integrações, permissões e efeitos colaterais.

Julgamento de intenção e tentativa

O componente de juiz com LLM entra para cobrir o que o estado não mostra sozinho. Se o agent tentou fazer algo inseguro, mas a ação foi bloqueada, ainda assim existe um sinal relevante de risco. Esse detalhe aparece no brief como uma das diferenças mais úteis do framework.

Para aplicações empresariais, esse ponto é decisivo. Um agent que “quase vazou” dados sensíveis ainda merece atenção, porque a arquitetura pode falhar em outro ponto amanhã. Segurança de agent, nesse cenário, é menos sobre resultado isolado e mais sobre padrão de comportamento.

O que o OpenAgentSafety traz de prático

O brief destaca quatro aspectos que valem atenção: avaliação por trajetória, uso de ferramentas com estado observável, modularidade e extensão para novas tarefas e ambientes. Isso é relevante porque benchmark útil precisa acompanhar a própria evolução dos agents, que hoje são orquestradores de ferramentas, não apenas geradores de texto.

Há também uma consequência para ciclos internos de qualidade. Se o time consegue automatizar esse tipo de checagem, ele passa a medir regressão de segurança da mesma forma que mede regressão de funcionalidade. A documentação pública da OpenAI sobre testing agent skills systematically with evals reforça essa ideia de inspeção repetível e orientada a skills.

Modularidade importa para times de produto

Benchmarks modulares são mais fáceis de adaptar ao contexto de um time. Se a equipe usa browser automação, pode priorizar tarefas web; se usa execução de código, pode priorizar sandbox e filesystem; se o fluxo é de atendimento, pode incluir mensageria e handoff. O valor real está em aproximar o benchmark da superfície de risco do produto.

Esse encaixe é particularmente útil no Brasil, onde times costumam operar com orçamento enxuto e precisam escolher bem onde investir em testes. Avaliar de forma modular ajuda a concentrar esforço nas integrações que realmente existem no sistema, em vez de copiar um benchmark genérico que não conversa com a arquitetura local.

Como pensar um eval de segurança para o seu agent

Se você está montando ou auditando um agent, um bom ponto de partida é definir a trajetória esperada e os estados proibidos. Depois, mapeie quais ferramentas o agente pode tocar e quais mudanças de estado precisam ser monitoradas. Isso vale tanto para um protótipo quanto para um produto em produção.

Uma rotina simples de trabalho pode começar assim:

undefined

Esta seção descreve a prática geral de avaliação de agents. APIs, sandboxes e ferramentas mudam rápido — confira a documentação oficial do seu fornecedor antes de levar qualquer rotina para produção.

O importante é separar três camadas: comportamento textual, uso de ferramentas e efeito final no ambiente. Quando essas camadas ficam misturadas, o time enxerga menos risco do que realmente existe. Quando elas ficam separadas, fica mais fácil criar uma política de aprovação clara.

Critérios que fazem diferença

Os critérios mais úteis costumam ser binários e observáveis: houve acesso indevido? houve tentativa de ação proibida? houve alteração não autorizada? houve vazamento para um canal externo? Esse estilo de métrica evita depender apenas de opinião humana e facilita repetir o teste em novas versões do modelo.

Outro cuidado importante é avaliar o agent no contexto real de permissões. Um sistema interno pode ser seguro em modo de leitura e inseguro em modo de escrita; o eval precisa capturar essa diferença. Em ambientes com dados regulados, esse mapa de privilégios também conversa diretamente com mitigação de risco sob a LGPD.

Por que importa pro dev brasileiro

No Brasil, a conversa sobre safety de agents não fica só em pesquisa. Ela toca contratos, operações e dados pessoais. Se um agent processa documentos de clientes, tickets de suporte ou bases internas, a checagem de segurança precisa considerar privacidade, rastreabilidade e princípio de menor privilégio, algo que ganha peso adicional sob a LGPD.

Há também uma questão bem prática de mercado: muitos times brasileiros operam com integrações em nuvem, automação de atendimento e ferramentas de produtividade com orçamento limitado. Isso favorece soluções que reduzam retrabalho e incidentes. Um eval de segurança bem desenhado evita que o custo apareça depois, em suporte, auditoria ou incidente operacional.

Outro ponto concreto é a diversidade de formação técnica no ecossistema brasileiro. É comum ter pessoas que vieram de bootcamps, migração de carreira ou times mais enxutos, então o processo de avaliação precisa ser claro e repetível. Em vez de depender de “feeling” do revisor, o time ganha em usar critérios observáveis e documentação de execução.

Conclusão

O recado de 2026 é que segurança de LLM agents precisa ser medida pelo que o sistema faz ao longo do tempo, e não só pelo texto final. O pacote que mais faz sentido hoje combina trajetória multi-turn, ferramentas com estado observável, regras determinísticas e julgamento assistido por LLM, como explicam o OpenAgentSafety e a visão de evals para skills de agents.

Se você quiser um passo acionável em menos de 1 hora, escolha um fluxo real do seu produto, liste 3 ferramentas que o agent pode usar e escreva 1 critério binário por ferramenta dizendo qual mudança de estado seria inaceitável. Isso já te dá a base de um eval de segurança útil para o seu contexto.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.