The Agent Baseline: 35 controles, mas por onde começar?

Há duas semanas, publicamos o Agent Baseline com a Docker e a Keycard. Nele, descrevemos seis resultados de segurança, 35 controles e uma arquitetura de referência aberta para operar agentes de IA em escala corporativa. Na semana passada, colocamos o documento à prova: levamos o tema a um painel na Black Hat e passamos cerca de uma hora respondendo a perguntas difíceis.

Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026

A pergunta mais útil veio de alguém que já tinha lido o documento. Ela disse, mais ou menos: Está certo, mas ainda não sei o que fazer na segunda-feira.

E ela tem razão. Também vale a pena responder direito, porque a pergunta aponta para algo que decidimos não incluir no documento. É o tipo de lacuna que esperamos que os leitores encontrem enquanto o Baseline ainda está aberto a comentários.

A confusão é real — e estamos bem no meio dela

Se você procurar ajuda para proteger agentes de IA, vai se deparar rapidamente com uma enxurrada de afirmações, porque todos os fornecedores do mercado (inclusive a Snyk) dizem resolver a segurança de agentes. Cada um descreve algo real, mas quase nunca fica claro que parte do problema está sendo abordada ou como essa solução se conecta às outras de que você ainda precisa.

Mas não se trata de desonestidade. É apenas um sintoma de um mercado que surgiu antes de desenvolver seu próprio vocabulário. Hoje, “governança de agentes” pode significar pelo menos cinco coisas diferentes, dependendo de quem está vendendo. E quem compra não tem uma forma confiável de saber se dois produtos se sobrepõem, se complementam ou deixam uma lacuna entre eles que ninguém mencionou (ou sequer identificou, o que é ainda mais preocupante).

Isso vale para os dois lados. Os fornecedores querem deixar claro onde agregam valor e como sua solução se conecta ao restante da arquitetura do cliente. Mas, sem um vocabulário comum, acabam fazendo a mesma afirmação genérica e indistinta que todos os outros.

E quem atua na área precisa de mais do que um decodificador de mensagens de fornecedores: comparar as soluções com os seis resultados mostra o que precisa ser buscado externamente e onde já existe capacidade interna. Essa é a conversa sobre comprar ou desenvolver internamente — e fica muito mais fácil quando as lacunas têm nome.

Considere dois produtos vendidos como soluções de governança de agentes. As descrições de ambos são corretas.

O primeiro fica na borda da rede. Ele monitora todas as chamadas que um agente faz para o mundo externo, inspeciona o conteúdo dessas chamadas e pode bloqueá-las com base em políticas. Ele informa quando uma solicitação com dados de clientes foi enviada para um destino indevido. Mas não consegue dizer qual arquivo de skill colocou essa instrução na cabeça do agente, por assim dizer, porque nada disso passa por ele.

O segundo é uma camada de identidade. Ele intermedeia credenciais de curta duração e com escopo definido no momento do uso, para que cada ação tenha uma resposta verificável sobre quem a iniciou e com qual autoridade. Ele informa, com precisão, que o agente tinha permissão para fazer o que fez. Mas não consegue dizer se fazer aquilo foi uma boa ideia.

Agora compare os dois com os seis resultados: o primeiro cobre partes de Restringir e Observar; o segundo cobre Autorizar. Nenhum exagera, não há sobreposição entre eles e, juntos, deixam Validar sem cobertura. Ninguém testou se o agente se comporta com segurança sob ataque, nem verificou o que ele produziu. Quem compra os dois, acreditando com toda razão que resolveu a governança de agentes, nunca teve essa conversa — porque ela não surgiu em nenhum dos ciclos de venda.

O Baseline foi criado justamente para possibilitar essa comparação. Ele define o problema pelos resultados de segurança que uma organização precisa alcançar, não por categorias de produtos: Descobrir, Restringir, Autorizar, Observar, Validar e Responder. Compare qualquer plataforma, produto ou solução desenvolvida internamente com esses seis resultados para entender rapidamente onde ela se destaca e onde pode precisar de soluções complementares.

O que não consideramos o suficiente foi a sequência. Seis resultados e 35 controles servem para avaliar a cobertura, mas avaliar a cobertura não é um plano. (Desculpe por falar como o Yoda, mas esse jogo de palavras mostra que a sequência também importa: cobrimos o significado; ele é compreensível, mas a ordem errada faz você levar mais um segundo para entender.)

Se você ler o documento agora como uma lista de tarefas, não vai começar, porque parece um programa de dois anos. Então, esta é a parte que faltou: a ordem.

A maioria das organizações ainda não opera fábricas de software

Uma coisa em que acreditávamos foi confirmada pelo painel da Black Hat: pouquíssimas empresas operam fábricas de software hoje, e muitas não estão sequer desenvolvendo uma em escala relevante. Vale dizer isso com todas as letras, porque uma arquitetura de referência pode parecer uma crítica para quem ainda não chegou lá. Não é. Se você está perto de dar esse passo — como a maioria —, este é o alicerce para construir. Ele também dá à segurança um papel na preparação para essa automação e esse ganho de produtividade, em vez de deixá-la reagir depois.

O eixo que faltava é o caso de uso

O documento acompanha a curva de autonomia: de um agente de programação em um laptop a um serviço autônomo que aplica patches em dependências às três da manhã. Essa é a maneira certa de explicar por que os controles existem, mas não de decidir quais você precisa primeiro. Isso porque a maioria das organizações não está subindo uma única curva: está usando várias coisas diferentes ao mesmo tempo e chamando todas de “agentes”.

Há três padrões que abrangem a maioria dos casos que vemos:

1. Agentes de programação para desenvolvedores. Alguém na organização baixa um agente de programação e o executa em um repositório real.
2. Agentes internos compartilhados. Há um único agente usado por muitos funcionários, como um assistente de RH, um aprovador financeiro ou um copiloto de operações.
3. Agentes de produção. Esses agentes atuam sobre clientes, transações e sistemas de registro, muitas vezes com pouquíssima “participação humana no processo”.

Você tem 35 controles, mas a ordem em que eles são “acionados” muda radicalmente. O problema começa quando você tenta tratá-los como um único programa: o controle mais importante para o primeiro caso quase não importa para o terceiro, e vice-versa. Se errar a sequência, você pode passar meses criando um registro de agentes enquanto sua exposição real está em outro lugar.

Agentes de programação para desenvolvedores: comece por Restringir e ajuste com Descobrir

Nesse caso, o impulso inicial é começar pela descoberta: encontrar todos os agentes e depois decidir o que fazer. Mas esse é o passo inicial errado para esse caso de uso. O documento explica o motivo em uma frase: um registro e um fluxo de aprovação não servem para nada se o agente for executado em um host que não aplica nenhum dos dois.

Na prática, acontece o seguinte: um desenvolvedor instala um agente de programação, que começa a pedir permissão sempre que precisa ler uma pasta ou executar um comando. As solicitações constantes ficam irritantes, então o desenvolvedor libera comandos comuns, amplia o acesso ao sistema de arquivos ou até desativa o ambiente isolado. A partir daí, o agente vira um processo comum, executado como aquele desenvolvedor e com acesso a tudo o que o shell dele pode alcançar.

O acesso aumenta conexão por conexão: o GitHub inicia um fluxo OAuth, uma ferramenta de nuvem encontra um login existente, um servidor MCP pede um token, o SSH usa a chave que já está carregada na máquina, e assim por diante. Você entendeu.

Cada etapa, por si só, parece razoável. Mas o resultado é um agente com ampla autoridade distribuída por sistemas que não compartilham uma visão uns dos outros, enquanto todos os logs dizem que foi o desenvolvedor quem realizou as ações.

Então, comece pelo limite. A execução isolada e os perfis de capacidade definidos para cada caso de uso (CON-03, CON-04) dão ao agente apenas o que sua categoria de trabalho exige — com definição centralizada e controle de versões, fora do alcance do agente para edição. Depois, crie o registro de componentes (DIS-04): servidores MCP, skills, plugins, modelos e ferramentas, com suas respectivas origens e versões. Em seguida, teste o que sai (VAL-03), pois o código gerado por agentes precisa passar pelos mesmos controles de lançamento que todo o resto.

O que mais surpreende as pessoas é que isso melhora o dia a dia do desenvolvedor, em vez de piorá-lo. Quando as credenciais são fornecidas por um intermediário no momento do uso e limitadas à tarefa, o agente deixa de pedir aprovação para cada comando “inofensivo”, porque esses comandos já não podem causar danos. Você recebe menos solicitações e estabelece um limite mais rigoroso com o mesmo controle — algo raro o bastante para merecer destaque.

E é aqui que a descoberta volta à conversa: não como primeiro passo, mas como aquilo que permite fazer esse passo da melhor forma possível.

Um perfil de capacidade só é tão bom quanto a visão que serviu de base para criá-lo. Se você o definir com base em suposições, pode cometer um de dois erros: deixá-lo amplo demais, e o agente passa a planejar contando com acessos desnecessários para a tarefa; ou restrito demais, e o limite acaba sendo removido aos poucos, um clique em “Sempre permitir” de cada vez. Nos dois casos, a causa é a mesma: criar o perfil sem antes investigar.

Portanto, investigue. O mapeamento de acesso efetivo (DIS-06) mostra a quais identidades e credenciais um agente realmente consegue chegar e o que elas permitem. O registro de componentes mostra quais servidores MCP, skills e modelos estão de fato em uso, em vez daqueles que você apenas supõe que estejam.

E o trabalho não termina no primeiro dia: a reconciliação (DIS-07) mostra quando o perfil sofreu alterações, como a adição de um servidor MCP ou uma mudança no formato de uma tarefa. O documento deixa claro que a descoberta não é um registro estático, mas uma visão operacional continuamente reconciliada.

Restringir é onde você começa a aplicar controles; Descobrir é como aprende o que precisa ser controlado. Siga essa sequência, mas não os separe: Descobrir é um insumo essencial para definir as restrições e deve ser abordado logo no início.

Agentes internos compartilhados: comece por Autorizar

O isolamento quase não ajuda aqui, porque o risco não é o raio de impacto em um host, mas o “confused deputy” (ou “intermediário confuso”). (É um problema de autoridade. O conceito vem de Norm Hardy, em 1988: um programa com autoridade legítima é enganado para exercê-la em nome da parte errada. Nada é comprometido, nada escapa do isolamento, nenhuma vulnerabilidade é explorada; simplesmente, o intermediário não consegue saber em nome de quem está agindo.)

A integração mais rápida dá ao agente uma única conta de serviço e faz todas as solicitações passarem por ela. Funciona na hora... e esse é o problema. Todas as solicitações passam a compartilhar o mesmo conjunto de acessos. Quando uma solicitação chega à API interna, já não é possível saber quem a fez, e um comando baseado nos dados de Alice pode acabar usando a autoridade destinada a Bob. Pedir ao modelo que mantenha o trabalho de cada um separado é uma solicitação, não um limite de segurança.

Neste caso de uso, a autoridade precisa estar definida na estrutura: uma identidade distinta e verificável para cada parte envolvida em uma ação, com atribuição à pessoa que a iniciou ou a uma finalidade autônoma aprovada (AUT-01). A autoridade deve ter escopo limitado à tarefa, em vez de ser herdada da conta (AUT-02): o menor privilégio limita o nível de acesso, e a delegação define por que, para que e por quanto tempo. Além disso, a autoridade precisa ser reduzida ao longo da cadeia (AUT-03), para que um agente subsequente nunca receba mais autoridade do que quem o acionou.

Em seguida, faça a correlação (OBS-02). Em um agente multiusuário, a pergunta de auditoria não é “Algo aconteceu?”, mas “Em nome de quem isso aconteceu?”. Sem um identificador de execução que conecte a solicitação à ação, você não consegue responder depois — e é depois que alguém vai perguntar.

Agentes de produção: comece por Responder e Validar

Para agentes que atuam sobre clientes e transações, os controles mais importantes são aqueles que ninguém implementa até precisar deles. Então, comece com uma pergunta: se você tivesse que interromper esse agente agora, o que aconteceria com o trabalho?

O problema é que a maioria das equipes não consegue responder a essa pergunta — e é aí que identificamos a lacuna. O RES-01 determina que interromper um agente significa bloquear novos trabalhos, parar as execuções em andamento e revogar as credenciais, permissões, concessões delegadas e sessões criadas por essas execuções, seguindo a cadeia de delegação, e não apenas o processo visível. Exclua o contêiner, mas deixe o token ativo, e você não interrompeu nada. O RES-02 acrescenta algo realmente novo: a unidade de quarentena costuma ser um componente, não um host. Um arquivo de skill envenenado ou um servidor MCP comprometido pode ser compartilhado por dezenas de agentes. E, como disponibilizá-lo pode ser tão simples quanto colocar um arquivo em um diretório, remover uma cópia não resolve nada.

Depois vem o RES-04, o controle que apostamos estar ausente em quase toda parte: uma alternativa que não dependa de agentes para trabalhos que não podem esperar. Quando um fluxo de trabalho passa a depender de um agente, a capacidade de executá-lo fica com o agente, não com a plataforma. Interrompa o agente, e o trabalho fica parado. Quais fluxos precisam de um procedimento manual documentado — e qual será esse procedimento — são decisões que você deve tomar antes do incidente.

E, na categoria Validar, há o VAL04: um agente pode concluir uma ação com sucesso e ainda assim chegar ao resultado errado, porque ter permissão não significa estar correto. Especialmente no caso de ações irreversíveis, valide o resultado proposto antes de finalizá-lo, não depois.

É dessa parte da arquitetura que cuidamos na Snyk. Não apenas de verificar se o código e as dependências de um agente são seguros, mas também se o comportamento dele permanece dentro dos limites da sua autoridade durante a execução: o que ele pode fazer, em nome de quem e o que acontece quando ultrapassa esses limites. Boa parte do Baseline está fora do nosso escopo — e esse é justamente o objetivo de um modelo independente de fornecedores.

O equilíbrio é uma escolha de design, não necessariamente um compromisso

Quando a situação assusta, o impulso é bloquear tudo: banir as ferramentas, esperar o mercado se estabilizar, dizer "vamos retomar isso no ano que vem".

Mas isso não funciona — e não pelo motivo que costumam alegar. O problema não é apenas que a adoção pelas sombras vai continuar (porque vai), mas que o bloqueio tira sua visibilidade justamente sobre aquilo que preocupa você, enquanto a empresa adota a tecnologia mesmo assim. No fim, você continua com o mesmo risco, só que com menos informações sobre ele.

Mas o impulso oposto é ainda pior: aprovar tudo, acrescentar um pouco de monitoramento e chamar isso de "governança". Monitorar um agente não é o mesmo que limitar o que ele pode fazer.

Na prática, a solução se parece menos com uma decisão e mais com uma arquitetura. Os controles do Baseline foram projetados para ficar fora do modelo, pois não podem depender de o agente seguir instruções. Isso torna viável discutir produtividade: em vez de decidir quanto confiar no agente, você define quanta autoridade o trabalho exige e impõe esse limite em um lugar que o agente não possa contestar. Dentro desse limite, deixe-o trabalhar.

Os níveis também importam. Uma negativa que diz apenas "Não" incentiva novas tentativas e soluções improvisadas. Já uma negativa que explica o motivo e indica o caminho aprovado — registra o componente, solicita uma elevação de escopo justificada, obtém aprovação independente e direciona a execução de volta aos limites sem encerrá-la. Entre redirecionar e interromper, é possível reduzir a autoridade da execução enquanto uma pessoa decide. Se você recorrer primeiro à interrupção total, qualquer anomalia vira uma interrupção do serviço.

O que ainda não está no documento

Faltam duas coisas no Agent Baseline. Preferimos falar delas abertamente, em vez de deixar que você as descubra por conta própria.

Primeiro, não há um modelo de maturidade. Os controles mostram como é uma boa prática, mas não explicam o que significa estar em um "bom estágio um" em comparação com um "bom estágio três". Cada organização que lê este material está em um ponto diferente, e um teste de cobertura que trata da mesma forma uma empresa da Série B e um banco global não é muito útil para nenhuma das duas. Definir a sequência por caso de uso, como fizemos acima, é só o começo desse trabalho — não o ponto de chegada.

Além disso, a perspectiva dos casos de uso não está na versão 1.0. Você a encontrou aqui porque ela surgiu em conversas como a que tivemos na Black Hat. Isso mostra, de forma razoável, que o processo de revisão está funcionando — e, de forma ainda mais convincente, que provavelmente deveríamos ter percebido isso antes.

Leia e contribua

Acreditamos muito neste ponto de partida. Também sabemos que há pessoas que gerenciam e avaliam esse trabalho há mais tempo do que existe o Baseline, com opiniões fortes e evidências para sustentá-las. É exatamente dessas pessoas que precisamos ouvir — e o momento é agora: o Baseline está aberto a comentários até 30 de setembro e continuará sendo open source de qualquer forma.

O Baseline é um rascunho, aberto a comentários até 30 de setembro. Os controles têm identificadores permanentes, para que você possa citá-los em uma constatação de auditoria, um documento de políticas ou uma resposta a uma RFP, e a referência continue válida no futuro.

Abrir uma issue é uma forma duradoura de discordar. Se um controle não funciona na prática, se deixamos algo passar ou se implementá-lo custa mais do que o risco que elimina, esse é exatamente o tipo de feedback que o período de revisão pretende receber. O objetivo é criar um único modelo, independente de fornecedores, que todos possamos começar a adotar e usar para avaliar nosso próprio progresso.

Conheça o Agent Baseline, leia o whitepaper e comente no GitHub para contribuir.