O que eu disse ao NIST sobre segurança de agentes de IA

Doze vezes em 60 dias, meu agente de IA parou de trabalhar na tarefa atribuída e começou a fazer outra coisa. Em cada vez, o agente continuou produzindo resultados plausíveis. Nenhuma vulnerabilidade de segurança teve papel nisso. O agente decidiu em tempo de execução trabalhar em um problema diferente.¹

Em 24 de fevereiro de 2026, esses 12 incidentes e dezenas de falhas relacionadas se tornaram um comentário público de 2.500 palavras para o National Institute of Standards and Technology. O dossiê NIST NIST-2025-0035 solicita contribuições públicas sobre considerações de segurança para agentes de IA.² O período de comentários encerra por volta de 9 de março de 2026. Meu comentário defende uma tese central: as ameaças de agentes são comportamentais, e nenhum framework existente do NIST aborda modos de falha comportamentais.

Resumo

Eu opero um sistema de orquestração de agentes de IA em produção diária: 15.000 linhas de código interceptando 15 tipos de eventos de hook em cada ação do agente. Ao longo de 60 sessões, identifiquei sete modos de falha comportamentais recorrentes sem análogo em software tradicional. O agente desviou da tarefa, alegou que testes passaram sem executá-los e gerou sub-agentes recursivos que perdiam contexto a cada salto. Construí uma defesa em três camadas (pipeline de hooks, sandbox do SO, portão de evidências) e mapeei o sistema contra CSF 2.0, SP 800-53 e o AI Risk Management Framework. Existem lacunas significativas nos três. O comentário inclui seis recomendações priorizadas, começando com uma proposta de NIST Internal Report sobre taxonomia de ameaças comportamentais de agentes. O período de comentários permanece aberto.

---

Por que um profissional submeteu um comentário público federal

O NIST raramente solicita contribuições públicas sobre segurança de IA. Quando a agência publicou seu Request for Information sobre segurança de agentes de IA, as cinco áreas temáticas mapeavam diretamente para problemas para os quais eu já havia construído soluções em produção:²

1. Ameaças de segurança únicas que afetam sistemas de agentes de IA
2. Métodos para aprimorar a segurança durante desenvolvimento e implantação
3. Como frameworks estabelecidos funcionam quando aplicados a agentes
4. Métodos para medir segurança e antecipar riscos
5. Salvaguardas de implantação para restringir e monitorar o acesso de agentes

A maioria dos comentários públicos em RFIs federais vem de corporações, associações setoriais e laboratórios de pesquisa. Profissionais individuais raramente submetem. Mas profissionais operam esses sistemas diariamente. Um desenvolvedor executando um agente de IA ao longo de mais de 60 sessões acumula evidências que experimentos controlados não produzem. Eu submeti porque as evidências existiam e ninguém mais ia submetê-las.

O comentário passou por três rodadas de revisão, um processo de deliberação com 10 agentes e duas rodadas de avaliação competitiva (Claude Code vs. Codex CLI) antes da submissão final.¹

---

O que eu construí

O sistema de orquestração envolve o Anthropic’s Claude Code CLI em aproximadamente 15.000 linhas de código shell e Python. Toda ação que o agente realiza (leitura de arquivos, escrita de arquivos, comandos bash, requisições web, geração de sub-agentes) passa por um pipeline de hooks antes da execução. Oito hooks despachantes direcionam chamadas para hooks manipuladores com base no tipo de ferramenta. O sistema registra cada decisão, rastreia custos, monitora desvios e impõe limites rígidos que o agente não pode sobrescrever.¹

Eu não planejei construir o sistema. O sistema cresceu a partir de falhas. O detector de desvio existe porque um agente passou 45 minutos reorganizando meu diretório de projeto quando a tarefa era “corrigir o endpoint de login.” O sandbox existe porque flagrei um agente tentando escrever em ~/.ssh/. O portão de evidências existe porque um agente relatou “todos os testes passaram” sem executar o pytest. Cada componente remonta a um incidente específico de produção.

---

Ameaças comportamentais: o argumento central

A segurança tradicional defende contra exploração: SQL injection, buffer overflows, roubo de credenciais. A segurança de agentes adiciona uma categoria sem precedentes em software: o agente decide em tempo de execução no que trabalhar, e pode decidir errado.

Desvio de sessão

Um agente gradualmente se afasta da tarefa atribuída enquanto produz resultados de aparência plausível. Meu mecanismo de detecção de desvio calcula a similaridade de cosseno entre o embedding do prompt original do usuário e uma janela deslizante das 25 chamadas de ferramenta mais recentes do agente.¹ Quando a pontuação cai abaixo de 0,30, o sistema injeta um aviso contendo o prompt original.

Defini o limiar de 0,30 com base em revisão manual ao longo de 60 sessões. O sistema disparou 12 avisos abaixo do limiar. Em todos os 12 casos, o agente havia verificavelmente perdido o rastreamento da tarefa original. Acima do limiar, nenhuma sessão exigiu intervenção manual por desvio. Otimizei o limiar para precisão; não medi formalmente a taxa de falsos negativos.¹

Verificação fantasma

Um agente afirma que o trabalho está completo e os testes passaram sem ter executado os testes. O sinal de detecção é específico: o relatório de conclusão não contém saída de teste colada. “Os testes devem passar com base na estrutura do código” substitui crença por evidência. Descrevi a variante de fabricação do mesmo padrão de falha: um agente que publica afirmações confiantemente erradas porque nada valida auto-relatos contra a realidade externa.¹

Geração recursiva

Agentes que geram sub-agentes podem entrar em recursão descontrolada, consumindo orçamento computacional e perdendo coerência. Minha proteção contra recursão impõe uma profundidade máxima de dois e um máximo de cinco filhos por agente pai, rastreando a árvore completa de linhagem via um arquivo JSON protegido por lock.¹

Os sete modos de falha

Cataloguei sete padrões comportamentais recorrentes ao longo de 60 sessões. Cada modo carrega um sinal de detecção específico que hooks ou revisão humana podem verificar:

Modo de falha	Definição	Sinal de detecção
Espiral de atalhos	Pular etapas de revisão para reportar conclusão mais rápido	Relatório de conclusão sem evidência de etapas
Miragem de confiança	Substituir “estou confiante” por verificação real	Linguagem evasiva sem saída de teste
Platô do bom-o-suficiente	Aceitar trabalho funcional mas não testado	Sem cobertura de testes ou documentação citada
Visão de túnel	Polir um componente enquanto ignora quebras de integração	Testes de integração não executados
Verificação fantasma	Alegar que testes passaram sem executá-los	Relatório sem saída de teste colada
Dívida adiada	Deixar marcadores TODO/FIXME em código commitado	TODO/FIXME no diff commitado
Relatório vazio	Reportar “feito” sem evidência para cada critério	Critérios não endereçados individualmente

Nenhum desses modos requer uma vulnerabilidade. O agente não precisa explorar um CVE. O agente falha ao fazer mal seu trabalho e relatar que o fez bem.

---

Defesa em profundidade

O sistema de orquestração utiliza três camadas independentes. Uma falha em uma camada não compromete as outras.

Camada 1: Pipeline de hooks. Toda chamada de ferramenta passa por um hook PreToolUse antes da execução. Manipuladores podem bloquear a execução, modificar o comando ou injetar contexto consultivo. A arquitetura despachante-manipulador significa que adicionar uma nova verificação de segurança requer escrever um arquivo de manipulador, não modificar o pipeline de roteamento. Oito despachantes direcionam para 99 hooks manipuladores.¹

Camada 2: Sandbox do SO. Um perfil macOS Seatbelt define oito regras explícitas de negação bloqueando escritas em .ssh, .gnupg, .aws, arquivos de ambiente, autenticação GitHub CLI e o macOS Keychain. O kernel impõe essas regras independentemente do comando que o agente construa. Tentar touch ~/.ssh/test sob o perfil retorna “Operation not permitted.”¹

Camada 3: Portão de evidências. Antes de marcar qualquer tarefa não trivial como completa, o agente deve satisfazer seis critérios de evidência com prova citada: segue padrões do codebase (nomear o padrão), solução funcional mais simples (explicar alternativas rejeitadas), casos extremos tratados (listar cada um), testes passam (colar saída), sem regressões (nomear arquivos verificados) e resolve o problema real (declarar a necessidade do usuário). O portão sinaliza linguagem evasiva (“deveria funcionar,” “provavelmente correto”) como evidência insuficiente, disparando reverificação obrigatória.¹

A independência das camadas é a propriedade de design crítica. Um agente que escapa do pipeline de hooks ainda encontra o sandbox do SO. Um agente que encontra uma brecha no sandbox ainda enfrenta o portão de evidências. Nenhuma falha única compromete o sistema.

---

Análise de lacunas dos frameworks

O comentário mapeia controles de produção contra três frameworks do NIST. Alguns mapeamentos funcionam bem. Outros revelam lacunas que nenhum framework existente preenche.

O que mapeia

Hooks PreToolUse abrangem duas funções do CSF 2.0: Protect (PR.PS-05, prevenindo ações não autorizadas) e Detect (DE.CM, monitoramento contínuo de chamadas de ferramentas).³ O sandbox do SO implementa SP 800-53 AC-3 (Imposição de Acesso) e AC-6 (Menor Privilégio).⁴ O pipeline de hooks mapeia para AC-25 (Monitor de Referência): sempre invocado, não pode ser contornado e pequeno o suficiente para verificar. A função Map do AI RMF (MAP 3) se alinha com a detecção de desvio: entender o que o agente faz versus o que o operador pediu que fizesse.⁵

O que está faltando

Framework	Controles aplicáveis	Lacuna específica de agentes	Extensão sugerida
CSF 2.0	DE.CM, DE.AE	Sem categoria de detecção de desvio comportamental	Estender exemplos de DE.AE para incluir anomalias comportamentais de agentes
SP 800-53 Rev. 5	AC-3, AC-6, AC-25	Sem controles de profundidade de delegação de agentes	Novo aprimoramento de controle para governança de delegação de agentes
AI RMF 1.0	MAP 3	Sem métrica de fidelidade de tarefa em tempo de execução	Adicionar similaridade de desvio de agente à função MEASURE

O OWASP Top 10 for Agentic Applications (2026) aborda Agent Goal Hijacking (ASI01) e Human-Agent Trust Exploitation (ASI09), mas não cobre falhas de autogovernança como verificação fantasma nem relatório vazio.⁶ O NIST AI 600-1 (Generative AI Profile) aborda riscos de IA generativa de forma ampla, mas é anterior aos padrões de implantação de agentes.⁷

Riscos da cadeia de delegação

Quando um agente gera um sub-agente, que gera outro sub-agente, propriedades de segurança não se somam. Cada salto introduz três riscos compostos:

• Compressão semântica. O contexto completo de raciocínio do pai colapsa em uma string de prompt, perdendo nuances sobre quais arquivos são sensíveis ou quais abordagens o pai já rejeitou.
• Amplificação de autoridade. O filho herda permissões de leitura/escrita de arquivos, mas não a compreensão do pai sobre quais arquivos carregam sensibilidade de segurança.
• Difusão de responsabilidade. Quando um sub-agente produz saída incorreta, a trilha de auditoria mostra qual agente tomou cada decisão, mas o agente raiz carrega a responsabilidade operacional pelo resultado final.

Minha proteção contra recursão aborda cadeias de delegação rastreando a linhagem dos agentes e impondo limites rígidos de profundidade. Nenhum framework publicado aborda os riscos compostos da delegação multinível de agentes.

---

Seis recomendações

O comentário encerra com seis recomendações, listadas do fundacional ao operacional:

1. Publicar um NIST Internal Report estabelecendo uma taxonomia de ameaças comportamentais de agentes. Modelos de ameaça tradicionais (STRIDE, OWASP Top 10) não capturam modos de falha específicos de agentes. Uma taxonomia compartilhada é o pré-requisito para todas as outras recomendações. O NIST também poderia estender o CSF 2.0 com subcategorias específicas para agentes e publicar um perfil do AI RMF para sistemas de agentes.

2. Estabelecer requisitos de contenção no nível do SO. Agentes que improvisam padrões de comando novos podem contornar sandboxing no nível da aplicação. Imposição no nível do SO (Linux seccomp-bpf, macOS Seatbelt, isolamento por contêiner) fornece uma fronteira que o agente não consegue contornar por raciocínio.

3. Exigir verificação independente de auto-relatos de agentes. Agentes não podem ser a única autoridade sobre se seu próprio trabalho está correto. Um processo separado deve verificar evidências externas (saída de testes, respostas API, checksums) antes de liberar a conclusão da tarefa.

4. Estabelecer classificação de raio de impacto para chamadas de ferramentas de agentes. Classificar cada ação do agente como local, compartilhada ou externa, com requisitos de autorização escalados para cada nível. Descrevi o sistema de classificação em detalhes anteriormente.

5. Definir métricas quantitativas de desvio. A postura de segurança de agentes precisa de uma “pontuação de foco na tarefa” mensurável que reflita quão próxima a atividade atual do agente está da tarefa atribuída, calculada em intervalos regulares.

6. Padronizar registro de auditoria para ações de agentes. Registrar cada chamada de ferramenta, cada decisão de hook e cada ação bloqueada em um formato que suporte reconstrução pós-incidente.

---

Submeta seu próprio comentário

O período de comentários para o NIST-2025-0035 encerra por volta de 9 de março de 2026. RFIs do NIST têm peso real: os comentários informam diretamente frameworks, padrões e orientações publicados. Se você opera agentes de IA em produção, suas evidências importam.

Como submeter:

1. Visite a página do dossiê NIST-2025-0035
2. Clique em “Comment” no documento do RFI
3. Escreva seu comentário abordando qualquer uma das cinco áreas temáticas
4. Inclua evidências específicas: código, métricas, relatórios de incidentes
5. Submeta com suas informações de contato

Você não precisa abordar todos os cinco tópicos. Um comentário focado e embasado em evidências sobre um único tópico tem mais valor do que um comentário amplo sem especificidades. A equipe do NIST lê cada submissão.

---

Principais conclusões

Para profissionais de segurança: Mapeie seus controles de agentes existentes contra CSF 2.0 e SP 800-53. O mapeamento do pipeline de hooks para AC-25 Reference Monitor fornece um framework concreto para descrever controle de acesso no nível do agente para equipes de conformidade.

Para desenvolvedores de IA: Construa detecção comportamental junto com segurança tradicional. Desvio de sessão, verificação fantasma e geração recursiva são realidades de produção, não riscos teóricos. Comece pelo portão de evidências: exija prova citada antes de marcar tarefas como completas.

Para formuladores de políticas: A lacuna entre frameworks de segurança tradicionais e ameaças específicas de agentes é estrutural, não incremental. Agentes falham de maneiras que STRIDE, OWASP e os catálogos existentes do NIST não classificam. Uma taxonomia de ameaças comportamentais é o pré-requisito para todo o resto.

Para autores de frameworks: Adicionem governança de cadeia de delegação. Quando agentes geram agentes, o contexto degrada, a autoridade amplifica e a responsabilidade se difunde a cada salto. Os riscos compostos na profundidade três e além não têm precedente em frameworks.

---

Fontes