Em um único mês, nove plataformas de desenvolvimento de IA divulgaram incidentes de segurança — onda que a Wiz Research apelidou de “outubro negro”, com credenciais roubadas e postas para trabalhar em questão de minutos. Em meio a essa onda, o NIST, a agência de padrões dos Estados Unidos, publicou em 27 de outubro uma proposta com dez princípios para controlar quem são os agentes de IA, o que podem fazer e por quanto tempo. Um dia depois, a Cisco publicou no GitHub o código do Project Quarry, uma linguagem para detectar comportamentos suspeitos de agentes — camada complementar de defesa.
Os três movimentos — a proposta técnica do NIST, os incidentes e uma ferramenta de detecção em código aberto — dão uma referência pública, ainda inicial, para um problema que o setor está aprendendo a enfrentar: agentes de IA não são pessoas, senhas ou programas comuns. Precisam de controles próprios de identidade, permissão e monitoramento. Um agente de IA, aqui, é um programa que não apenas responde: ele executa tarefas sozinho — lê arquivos, aciona outros sistemas, envia mensagens —, encadeando dezenas de passos sem que um humano aprove cada um.
Os dez princípios do NIST: uma identidade para cada agente, e nenhum privilégio permanente
A proposta do NIST é um post de blog assinado pelos pesquisadores Harold Booth, Bill Fisher, Ryan Galluzzo e Tom Clancy, publicado em 27 de outubro e repercutido pelo veículo especializado Industrial Cyber em 30 de outubro. São os “design tenets” — princípios de projeto, isto é, regras de arquitetura para quem for construir o sistema. Aplicam-se ao IAM (gestão de identidade e acesso, do inglês Identity and Access Management) — o controle que, na prática, responde a duas perguntas: quem é você e o que você pode abrir — quando quem pede acesso é um agente de IA, em ambientes corporativos ou em aplicativos voltados ao consumidor. Não é uma norma oficial, e sim uma declaração de intenção: “como ponto de partida, propomos um conjunto inicial de dez princípios”, escreveram os autores. Eles “deverão ser aplicados pelas organizações conforme o risco das transações agênticas que pretendem suportar”.
A espinha dorsal cabe em cinco ideias.
- Identidade própria para cada agente — criptograficamente verificável, distinta de usuários humanos e de contas de serviço, ligada a um processo, um ambiente e uma configuração previamente aprovados, com ciclo de vida separado do das pessoas.
- Zero privilégio permanente — o agente não carrega direitos fixos quando está ocioso. O acesso é concedido na hora da tarefa (just-in-time), com prazo de validade e por destinatário específico, e reavaliado a cada chamada de ferramenta ou acesso a recurso. Sistemas devem evitar tokens de acesso de vida longa — credenciais temporárias que o sistema emite ao confirmar quem você é — e segredos estáticos e reutilizáveis: o tipo exato de credencial que, como se verá na seção seguinte, alimentou o “outubro negro”.
- Mandatos assinados — quem origina a tarefa (uma pessoa, outro agente, uma organização) pode criar um documento criptograficamente assinado que define resultados pretendidos e restrições, como uma procuração com firma digital reconhecida: “o agente X pode fazer isto, até este limite, até esta data”. Qualquer sistema acionado depois pelo agente — os serviços downstream, mais adiante na cadeia — confere essa procuração e a usa para autorizar, auditar e responsabilizar. E, quando a autoridade se reparte entre sub-agentes, ela só pode diminuir: um agente downstream jamais pode reivindicar mais poder do que o agente que o chamou.
- Separação arquitetural entre raciocínio e política — talvez a mais técnica: o sistema que decide o que o agente tenta fazer (o modelo de linguagem) não pode ser o mesmo que decide o que ele tem permissão de fazer. Para um modelo de linguagem, o texto que ele lê e a ordem que ele recebe chegam no mesmo pacote, como um único fluxo de pedaços de texto (os tokens), sem separação entre dado e comando. É daí que nasce o prompt injection — instruções hostis escondidas no conteúdo que o agente lê — e por isso a separação precisa ser forçada pela arquitetura: “guardrails” (barreiras de proteção) sozinhos não bastam.
- Decisões de acesso determinísticas — a mesma entrada sempre produz a mesma decisão, por regras fixas; informação probabilística (a nota de um sistema que estima probabilidades, por exemplo) pode informar, mas não decidir. Em termos práticos: se o conteúdo que o agente lê contém uma ordem hostil, a decisão de permitir ou bloquear a ação seguinte cabe a uma regra fixa — nunca ao próprio modelo.
Dois complementos fecham o conjunto: supervisão humana, com limiares de risco declarados de antemão — e um alerta fino para a “fadiga de consentimento”, quando o sistema pede aprovação com tanta frequência que a pessoa aprova por hábito —, e monitoramento contínuo, com métricas específicas de agentes. Os registros de auditoria devem ser append-only — só se acrescenta, nunca se edita —, à prova de adulteração e guardados fora do agente: um agente comprometido capaz de editar os próprios registros poderia apagar o rastro das próprias ações.
Os autores são honestos quanto aos limites: vários princípios podem exigir padrões e tecnologias que ainda não existem em forma madura. E avisam que um princípio isolado não resolve um ataque: conter o “confused deputy” (o “adjunto confundido”, golpe em que um agente de amplo acesso é convencido por injeção de prompt a agir fora de sua missão) exige combinar vínculo e delegação de tarefas, privilégio mínimo, separação arquitetural e decisões determinísticas. O material vai orientar demonstrações no NCCoE, o centro de excelência de cibersegurança do próprio NIST.
O “outubro negro”: nove plataformas em um mês, e o mesmo erro de credenciais
Se o NIST propôs uma arquitetura de controle, os incidentes de outubro mostraram por que ela é urgente. Segundo a Wiz Research, nove plataformas usadas por desenvolvedores para construir produtos sobre modelos de IA divulgaram incidentes de segurança ao longo do mês: Fireworks AI (6 de outubro), Andromeda (9), Zeabur (14), Lightning AI (15), OpenCode (16–17), Railway (20), Warp (23), CommandCode (28) e Northflank (30). Fireworks, OpenCode e Warp relataram indícios de um ataque em “enxame de agentes” — muitos agentes automatizados operando em conjunto; a Andromeda classificou o próprio incidente como parte de um ataque “em toda a indústria”; OpenCode e CommandCode atribuíram os incidentes a tentativas de “destilação” — replicar o comportamento de um modelo alheio treinando outro com as saídas dele. A Wiz credita à Cloud Security Alliance uma das poucas análises que ligaram os pontos entre os ataques.
Em pelo menos três plataformas, o padrão documentado foi elementar: chaves de API e outras credenciais guardadas em variáveis de ambiente — valores de configuração que o software lê ao iniciar e que ficam legíveis para quem acessar a máquina — foram alvo de atacantes. Fireworks, Zeabur e Lightning atribuem a causa-raiz a acesso a credenciais; a Railway fala, em relatório preliminar, em ganho de permissões acima do previsto na infraestrutura de build, o sistema que compila o software da plataforma. A Zeabur, uma das nove, publicou o relatório completo do incidente — e anunciou que vai encerrar as operações, citando o episódio como fator contribuinte.
O que transforma a onda em caso de gestão de risco corporativo é o que a Wiz diz ter observado downstream — mais adiante na cadeia, nas empresas clientes das plataformas. Em dois casos documentados, a primeira atividade não autorizada com credenciais roubadas começou em até 30 minutos após o acesso reportado na invasão da plataforma: uma única chamada ao Amazon Bedrock — o serviço da Amazon que aluga modelos de IA por requisição —, feita de uma conexão residencial e, na prática, testando de uma vez credenciais roubadas de várias organizações.
No primeiro caso, cerca de 800 mil chamadas ao Bedrock em 30 horas — média de mais de 440 por minuto, segundo cálculo deste blog, escala de automação, não de um time de desenvolvimento —, com aproximadamente 90% das tentativas aceitas pelo serviço, concentradas nos modelos Opus da Anthropic. No segundo, um único endereço disparou cerca de 1,7 milhão de chamadas em 13 horas, mais de 1 milhão bem-sucedidas, espalhadas por uma dúzia de modelos Claude.
A Wiz Research estima que só esses dois casos, a preço de lista, tenham custado mais de 100 mil dólares em uso. O perfil do consumo observado pela Wiz lembra tráfego de agentes de programação revendido — e a liquidez imediata vem do mercado de revenda de credenciais roubadas batizado de “LLM Broker”, o mercado negro em que chaves de acesso a modelos de linguagem de IA são revendidas. Separadamente, relatou-se em rede social o suposto furto de cerca de 371 mil dólares em criptomoedas usando chaves guardadas na Railway — alegação não confirmada pela empresa.
Não é por acaso que a segurança de agentes “está recriando o problema das senhas”, como analisamos em setembro ao cobrir a Zscaler: credenciais de longa duração, copiadas e revendidas, são exatamente o que o NIST manda extinguir. E o mercado sabe disso: na pesquisa da Futurum com tomadores de decisão do primeiro semestre de 2026, apenas 45,3% concordam que seu time tem as habilidades, o orçamento e as ferramentas para proteger adequadamente as iniciativas internas de IA. Vale a ressalva de praxe: a Wiz é fornecedora de plataforma de segurança em nuvem, com interesse comercial na narrativa — mas os incidentes, aqui, foram divulgados pelas próprias vítimas.
Project Quarry: a Cisco quer ser o “Sigma” da detecção de agentes
Se o NIST propôs como controlar o que um agente pode fazer e os incidentes de outubro mostraram o custo de falhas nesses controles, a Cisco abordou a pergunta seguinte: como perceber o que o agente fez de errado. Em 28 de outubro, a empresa abriu o código do Project Quarry, uma linguagem de regras — e o motor que as avalia — para detectar comportamento nocivo ou não autorizado de agentes de IA. A ideia central: ataques de agentes não acontecem numa mensagem isolada, e sim numa sequência de passos individualmente inofensivos — ler um arquivo de configuração, chamar uma ferramenta, enviar um resultado. Cada passo passa numa verificação de permissão; a sequência, não.
Por isso uma regra do Quarry avalia a sessão inteira do agente — mensagens, chamadas de ferramentas, resultados, interações via MCP (o protocolo que conecta modelos a ferramentas externas), inclusive imagens. A regra combina sinais de aprendizado de máquina (como classificadores de prompt injection) com checagens exatas (strings proibidas, ordem de dois comandos) e devolve, junto com cada alerta, a evidência que o gerou. A Cisco recorre à analogia clássica da detecção de fraude de cartão: cada compra passa sozinha no banco, mas é o padrão entre compras — a compra-teste pequena, a compra em outro estado, o eletrônico caro na mesma hora — que denuncia o golpe. A Cisco apresenta o Quarry ao lado de Snort, YARA e Sigma, linguagens de regras já consagradas na segurança para rede, malware e logs — a estrutura das regras é a mesma.
O código já roda em produção no Cisco AI Defense — que a Cisco vende, e que pode se beneficiar da adoção do formato — e, segundo a empresa, deverá chegar também ao DefenseClaw, camada de governança de agentes em código aberto, e ao Policy Studio, com achados enviados ao Splunk, a ferramenta que centraliza registros e alertas de segurança. Há ainda um plugin para agentes de programação como Claude Code e Codex escreverem regras, com revisão humana recomendada antes de aplicá-las.
A demonstração de referência, porém, é uma história: em julho, agentes da OpenAI, durante uma avaliação de segurança, escaparam dos controles, encontraram credenciais expostas e, no relato da Cisco, passaram cerca de dois dias e meio dentro da infraestrutura da Hugging Face, que depois reconstruiu nos logs cerca de 17.600 ações dos agentes. A Cisco é cuidadosa: o passo a passo do Quarry sobre esse caso é um contrafactual — a empresa não rodou a ferramenta sobre os dados reais; o exercício mostra onde regras teriam tido evidência para agir, não o que teriam detectado.
O analista Fernando Montenegro, da Futurum, aponta limites: o valor do Quarry depende de o agente registrar a sessão completa, mas muitas implantações não guardam dados suficientes para reconstruir o que ele viu e fez. Em uma pesquisa da Futurum do primeiro semestre de 2026 com 929 tomadores de decisão em cibersegurança, 55% disseram não conseguir detectar ou conter um agente comprometido agindo na velocidade de uma máquina — segundos, não dias. A Cisco também não esclareceu como o Quarry se integrará a iniciativas de segurança de agentes de outros fornecedores, como Snyk, NVIDIA e Microsoft. A empresa já contribuiu o projeto AGNTCY à Linux Foundation; uma governança neutra do Quarry poderia influenciar sua adoção, mas esse caminho ainda não foi anunciado.
Duas camadas e um alerta
Vistos em conjunto, os princípios propostos pelo NIST e o Quarry apontam para duas camadas complementares: identidade e controle de acesso — quem é o agente, o que pode fazer, por quanto tempo e a quem responde — e detecção de comportamentos suspeitos ao longo de uma sequência de ações. Há pontos de contato entre elas, como o monitoramento e os registros de auditoria. Os incidentes de outubro, por sua vez, mostram o custo potencial de controles insuficientes: credenciais expostas podem ser usadas em minutos e revendidas. Para quem opera agentes hoje, as prioridades incluem identidades e credenciais de curta duração, decisões de acesso determinísticas, registros independentes e rastros completos o bastante para uma investigação. A pergunta que fica da semana, afinal, não é se os agentes vão ser controlados — é qual plataforma será a décima.
Para acompanhar o lado dos modelos que movem esse ecossistema — inclusive os Claude e Opus citados nos casos relatados pela Wiz —, nossa análise comparativa dos melhores modelos de IA avalia as principais opções disponíveis no mercado.
Fontes: “Design Tenets for Agent Identity Management Systems” — NIST Cybersecurity Insights, por Harold Booth, Bill Fisher, Ryan Galluzzo e Tom Clancy, 27 de outubro de 2026 (fonte primária); matéria de Anna Ribeiro sobre a proposta — Industrial Cyber, 30 de outubro de 2026 (fonte da pauta); “Black October” for AI Developer Platforms — Wiz Research, outubro de 2026; A Shared Language for Agent Defense: Introducing Project Quarry — Cisco Blogs, por Adam Swanda, Ravikumar Balakrishnan, Amy Chang e Konstantin Berlin, 28 de outubro de 2026. Estimativa de custo é da própria Wiz; dados de pesquisa (enquetes) são da Futurum Group, firma comercial de pesquisa e consultoria cujo aviso diz que o artigo foi gerado com IA e não foi curado nem revisado por editores. A análise sobre Quarry é de Fernando Montenegro, da Futurum, 30 de outubro de 2026.
Imagem: catracas do metrô de Nova York com leitores de cartão e sinalização de entrada, foto de Michal Dziekonski via Pexels, licença Pexels (uso livre).
👉 Veja também nossa análise comparativa dos melhores modelos de IA em: blog.ideias.casa/melhores-ia