Governança de Agentes de IA: Controle de Autonomia em Produção

A maioria das empresas que está colocando agentes de IA em produção não tem um problema de segurança. Tem um problema de arquitetura que se parece com um problema de segurança.

O debate sobre governança de agentes segue um roteiro previsível. De um lado, times de compliance produzem documentos de política com listas de ações proibidas. Do outro, times de engenharia ignoram esses documentos porque eles não são implementáveis no runtime. O agente continua operando com a mesma autonomia de antes. A política existe no papel. A governança real não existe em lugar nenhum.

Governança de agentes de IA é o conjunto de mecanismos de runtime que definem, limitam e auditam a autonomia de um agente durante a execução. Ela não é um documento. É uma camada de software que fica entre a intenção do agente e a execução da ação, decidindo em milissegundos se aquela ação específica, naquele contexto específico, pode prosseguir.

A distinção importa porque agentes em produção não são determinísticos. Um agente de coding que recebe a tarefa "refatore o módulo de autenticação" pode decidir ler arquivos de configuração, modificar credenciais de banco, alterar variáveis de ambiente ou executar migrações. Nenhum documento de política cobre todas as permutações. A governança precisa ser tão dinâmica quanto o agente.

O que é governança de agentes de IA?

Governança de agentes de IA é a arquitetura de controle que opera no caminho de execução do agente, revisando cada ação antes que ela produza efeito, com base no contexto da tarefa, na intenção do usuário e na consequência potencial do erro.

Diferente de um firewall que bloqueia com base em regras estáticas, a governança de runtime avalia a relação entre o que o agente pretende fazer, o que o usuário pediu e o que pode dar errado. O mesmo comando pode ser seguro em um fluxo e inaceitável em outro. O que define o veredito é o contexto.

Essa definição surge da observação de sistemas em produção. Em junho de 2026, o time do Cursor publicou a arquitetura do Auto-review, um classificador que revisa cada ação do agente antes da execução e decide se ela pode seguir, se precisa ser adaptada ou se deve ser bloqueada. O artigo, escrito por David Gomes e Travis McPeak, documenta um sistema que trata autonomia como um espectro contínuo, não como um interruptor binário. A governança deixa de ser uma pergunta de sim ou não. Passa a ser uma pergunta de quanto.

Por que a abordagem de políticas não funciona em produção?

Times de segurança tratam governança de agentes como extensão da governança de TI tradicional. O resultado é previsível: documentos que listam ações proibidas, revisões periódicas, classificações de risco estáticas.

Três falhas tornam essa abordagem inviável para agentes em produção.

A primeira é a cobertura impossível. Um agente de coding pode executar milhares de comandos em uma sessão. As combinações de ação, ferramenta, arquivo e contexto excedem o que qualquer documento estático pode prever. A política cobre as 20 ações mais óbvias. As outras 9.980 ficam sem governança.

A segunda é a fadiga de aprovação. Quando o Cursor analisou clientes enterprise que operavam com revisão manual de ações, encontrou taxas de bloqueio em torno de 40%. O número não significa que 40% das ações eram perigosas. Significa que o sistema não tinha granularidade para distinguir risco real de precaução excessiva. O usuário recebia prompts de aprovação constantes. Depois de algumas dezenas, parava de ler. A aprovação manual, quando aplicada como padrão, produz o oposto do efeito desejado: transforma governança em ruído.

A terceira é a latência. Um loop de aprovação humana adiciona segundos ou minutos a cada ação que requer revisão. Para agentes que executam dezenas de ações por tarefa, o custo acumulado inviabiliza a operação. A governança precisa operar na mesma escala de tempo do agente: milissegundos, não minutos.

O Cursor resolveu essas três falhas com um princípio arquitetural simples. Em vez de um documento de política lido por humanos, um agente classificador que roda dentro do mesmo fluxo de execução. Em vez de aprovação binária, um espectro de autonomia calibrado por contexto. Em vez de interromper o usuário a cada bloqueio, um loop de feedback que permite ao agente pai adaptar a ação sem escalar.

Esse princípio é o que separa governança real de governança documental. A governança de runtime não pergunta "esta ação é permitida pela política?". Pergunta "esta ação, neste contexto, com esta intenção, justifica o risco que ela representa?".

Como funciona a governança embutida no runtime?

O Auto-review do Cursor é o caso de referência mais documentado, e sua arquitetura revela padrões que qualquer time implementando agentes em produção precisa entender.

O sistema funciona em três camadas. A primeira é a triagem: comandos cobertos por allowlists ou sandboxing não passam pelo classificador. São ações de baixo risco cujo contexto já foi validado. Essa camada elimina a maior parte do volume antes que o classificador seja acionado.

A segunda camada é o classificador propriamente dito. Ele roda no mesmo stream RPC do agente pai, sem round trip adicional, usando uma arquitetura similar a subagentes. Quando uma ação requer julgamento contextual, o classificador a recebe junto com o pedido original do usuário, o histórico da sessão e as ferramentas disponíveis.

O classificador é agentivo. Um comando como python script.py não pode ser julgado apenas pelo nome. O classificador inspeciona o arquivo com ferramentas como ReadFile, Grep e Glob antes de decidir. A decisão não é sobre a ação isolada. É sobre a relação entre a ação e a intenção do usuário.

A terceira camada é o loop de feedback. Quando o classificador bloqueia uma ação, ele não gera um prompt de aprovação para o usuário. Ele retorna uma explicação para o agente pai, que pode usar esse feedback para escolher um caminho mais seguro. O agente adapta a abordagem. O usuário não é interrompido.

[IMAGEM TECNICA type: architecture-flow title: Camadas de Governança de Runtime data: > Fluxo da ação do agente da esquerda para a direita. Nó 1: Agente gera ação planejada. Nó 2 (decisão): Allowlist/Sandbox cobre esta ação? Sim → Executa. Não → Encaminha ao classificador. Nó 3: Classificador recebe (ação, intenção do usuário, contexto da sessão, tools disponíveis). Nó 4 (decisão): Ação é consistente com a intenção no contexto atual? Sim → Executa. Não → Gera explicação. Nó 5: Agente pai recebe explicação. Adapta abordagem. Nova ação volta ao ciclo. Nó 6 (escalação rara, ~7% das sessões): Se adaptação falha, usuário é notificado. source: Cursor Auto-review architecture (Cursor Blog, Jun 2026) + Anthropic Building Effective Agents (Dec 2024) language: pt-BR ]

A escolha do modelo que roda o classificador é uma decisão arquitetural de primeira ordem. O time do Cursor descobriu que modelos com menos reasoning nem sempre são mais rápidos. Quando o modelo lutava para entender a política ou o tool call, gastava mais tokens e mais tempo para produzir uma decisão pior. O ponto ótimo foi um modelo pequeno com capacidade de reasoning suficiente para decidir com clareza na primeira tentativa.

O resultado operacional: o classificador bloqueia cerca de 4% das ações que revisa. Desses bloqueios, a maioria é resolvida pelo agente pai sem escalar. Apenas 7% das sessões em modo Auto-review geram qualquer interrupção para o usuário. Para referência, clientes enterprise que operavam com revisão manual viam 40% das ações bloqueadas. A governança de runtime reduziu o atrito em quase 6x enquanto aumentava a cobertura de segurança.

Quais são as camadas de autonomia de um agente?

A autonomia de um agente em produção não é um parâmetro único. É uma pilha de camadas, cada uma operando em um nível diferente de abstração e com um custo diferente em latência e atrito.

A allowlist é a camada mais barata e mais restrita. Funciona para ambientes onde o escopo de ações possíveis é conhecido antecipadamente. Para agentes de coding, a cobertura é baixa: a variedade de comandos, arquivos e ferramentas excede qualquer allowlist mantível.

O sandbox é a camada de contenção. Ele não decide o que o agente pode fazer. Ele limita o dano do que o agente fizer. O Cursor implementou sandboxing para agentes locais em fevereiro de 2026, antes do Auto-review. As duas camadas se complementam: o sandbox reduz o raio de dano potencial, o classificador reduz a probabilidade de ações que explorariam esse raio.

O classificador de runtime é a camada que torna a governança viável para agentes autônomos. Sem ele, a escolha é entre allowlist (restritiva demais) e aprovação humana (lenta demais). Com ele, a autonomia se torna calibravel.

A aprovação humana é a camada de último recurso. No Auto-review, ela só é acionada quando o classificador bloqueia e o agente pai não encontra uma alternativa segura. Isso acontece em cerca de 7% das sessões. O número importa porque define o teto de atrito aceitável: se mais de 10% das sessões geram interrupção, o sistema está forçando o usuário a fazer o trabalho do classificador.

Como calibrar o classificador de risco?

Calibrar um classificador de runtime é um problema de evals, não de engenharia de prompts. O classificador precisa acertar em dois eixos simultâneos: bloquear ações arriscadas sem bloquear trabalho rotineiro.

O time do Cursor construiu seu conjunto de evals a partir de duas fontes. A primeira foram 12 horas de sessões reais de desenvolvimento interno, destiladas e deduplicadas em 6.122 linhas rotuladas. Essas sessões capturam o formato real do trabalho de um agente: a distribuição de comandos, a sequência típica de ferramentas, os padrões de arquivo acessados. Treinar contra essa distribuição é o que impede o classificador de ser excessivamente cauteloso.

A segunda fonte foram dados sintéticos para os casos que não aparecem com frequência suficiente em sessões reais: leitura de secrets, manipulação de dados de produção, execução de instruções não confiáveis, ações com efeitos colaterais amplos. Esses exemplos cobrem as falhas que o classificador mais precisa capturar, mas que ocorrem raramente em uso normal.

Dois aprendizados operacionais do processo de calibração. O primeiro é sobre flapping: se o mesmo caso é permitido seis vezes e bloqueado quatro, a política está subespecificada. Rodadas repetidas expõem casos instáveis e forçam o refinamento do prompt ou das regras até que o comportamento se estabilize.

O segundo é sobre evolução da política. Quando a política de classificação muda, o conjunto de evals precisa ser re-rotulado ou regenerado. Testar o classificador atual contra uma compreensão desatualizada do problema produz falsa confiança. O Cursor rodava os evals pelo mesmo backend usado em produção, testando o caminho completo: uso de ferramentas pelo classificador, classificação final, overrides de modelo e falhas de parsing.

Qual o impacto no fluxo do agente?

A governança de runtime altera o loop de execução do agente em um ponto específico: entre a geração da ação e a execução. Esse ponto de inserção é o que permite que a governança opere sem reescrever o agente.

O fluxo padrão de um agente autônomo, como descrito pela Anthropic em seu guia de building effective agents, é: receber tarefa, planejar próximo passo, gerar tool call, executar tool call, observar resultado, repetir. A governança de runtime se insere entre "gerar tool call" e "executar tool call". Se a ação é aprovada, o fluxo segue inalterado. Se é bloqueada, o agente recebe feedback e gera um novo plano.

Essa arquitetura tem uma propriedade crítica: o agente não sabe que está sendo governado. Ele opera com o mesmo loop de planejamento e execução. A diferença é que algumas ações pretendidas recebem um "não" com explicação, e o agente usa seu próprio reasoning para encontrar uma alternativa.

O custo em latência é assimétrico. Ações que passam pela allowlist ou sandbox não sofrem acréscimo. Ações que entram no classificador adicionam o tempo de inferência de um modelo pequeno, tipicamente dezenas a centenas de milissegundos. Ações que sobem para aprovação humana adicionam segundos ou minutos. A distribuição real favorece as camadas mais rápidas: a maioria das ações nunca chega ao classificador, e a maioria das que chegam recebe aprovação na primeira tentativa.

Esse perfil assimétrico é o que torna a arquitetura viável. Se toda ação passasse pelo classificador e toda classificação fosse lenta, o custo acumulado de latência derrotaria o propósito do agente. A triagem por allowlist e sandbox garante que o classificador seja invocado apenas quando o julgamento contextual é genuinamente necessário.

Para um Agent Gateway operando em ambiente corporativo, essa mesma lógica se estende para múltiplos agentes. O gateway roteia cada ação para a camada de governança apropriada, unificando o controle sobre agentes que operam em domínios diferentes com níveis de risco diferentes.

Quais os erros mais comuns na implementação?

Quatro padrões de falha aparecem consistentemente quando times tentam implementar governança de agentes pela primeira vez.

O primeiro é tratar governança como configuração, não como produto. Times instalam uma ferramenta de allowlist, definem algumas regras e declaram o problema resolvido. A allowlist captura o que o time conseguiu prever. O agente continua operando fora desse perímetro. Governança de runtime é um sistema que evolui com os evals, com a política e com o comportamento do agente. Ele exige o mesmo ciclo de melhoria contínua que qualquer outro componente de produção.

O segundo é usar o modelo errado para o classificador. Modelos grandes demais adicionam latência e custo desproporcionais ao valor da decisão. Modelos com pouco reasoning produzem decisões inconsistentes que geram flapping e corroem a confiança do time de engenharia. O ponto ótimo, como o Cursor documentou, é um modelo pequeno com capacidade de reasoning suficiente para aplicar a política com clareza.

O terceiro é não dar ferramentas ao classificador. Um classificador que só recebe o texto do comando está operando com informação insuficiente. Ele precisa inspecionar arquivos, checar o contexto da sessão e entender a intenção original do usuário. Um classificador sem ferramentas é um allowlist probabilístico. Ele vai errar nos casos que realmente importam.

O quarto é ignorar a calibração. O classificador padrão tende a ser conservador demais, bloqueando ações que são seguras no contexto mas que parecem arriscadas em isolamento. Sem evals que capturem a distribuição real de trabalho do agente, o sistema produz fadiga de bloqueio. A calibração não é uma etapa única. É um processo contínuo que acompanha a evolução das capacidades do agente e das ameaças.

Um quinto erro, menos técnico mas igualmente letal, é separar a decisão de governança da decisão de arquitetura. Times que delegam governança para compliance e arquitetura para engenharia produzem sistemas onde a governança é um overlay, não uma camada integrada. O resultado é o documento de política que ninguém implementa. A governança de runtime só funciona quando é projetada junto com o loop de execução do agente, pela mesma equipe, com os mesmos critérios de qualidade.

FAQ: Governança de Agentes de IA

Qual a diferença entre governança de agentes e AI guardrails?

AI guardrails operam no nível do modelo: filtros de conteúdo, limites de token, detecção de prompt injection. Governança de agentes opera no nível da ação: o que o agente pode fazer com as ferramentas que tem acesso. As duas camadas são complementares. Guardrails sem governança de ação protegem o modelo mas não protegem o sistema. Governança de ação sem guardrails protege o sistema mas deixa o modelo vulnerável a jailbreak.

Agentes menores precisam de governança de runtime?

Sim. O risco não escala linearmente com a capacidade do modelo. Um agente simples com acesso a um banco de produção pode causar mais dano que um agente sofisticado operando em sandbox. A governança se dimensiona pelo raio de dano potencial, não pela complexidade do agente.

Quanto custa implementar governança de runtime?

O custo principal é o de inferência do classificador. Usando um modelo pequeno com reasoning suficiente, o custo por ação revisada fica na faixa de frações de centavo. Para um agente que executa milhares de ações por dia, o custo mensal de governança é inferior ao custo de uma única hora de engenharia gasta apagando um incidente.

Governança de runtime substitui revisão humana?

Não. Ela reduz a revisão humana ao conjunto de casos onde a adaptação automatizada falha. No Auto-review, isso representa 7% das sessões. A revisão humana continua sendo a camada de último recurso para decisões de alto impacto sem alternativa segura. A diferença é que ela deixa de ser o mecanismo padrão.

Como começar com governança de runtime em um time pequeno?

Comece com sandboxing. É a camada de menor custo de implementação e maior redução de risco. Em seguida, implemente um classificador simples para as 10 ações mais arriscadas que seu agente executa. Rode em shadow mode por uma semana, comparando as decisões do classificador com o que o time teria decidido manualmente. Ajuste os evals. Só então ative o bloqueio.

A direção da governança de agentes

Três tendências convergem para tornar a governança de runtime o padrão da indústria nos próximos 18 meses.

A primeira é a aceleração da autonomia. Agentes estão passando de execução de tarefas unitárias para orquestração de workflows completos, onde um agente coordenador delega para múltiplos agentes especializados. Nesse cenário, um agente decide o que outros agentes farão. A superfície de risco se expande com o quadrado do número de agentes. A governança de runtime é o único mecanismo que escala nessa geometria.

A segunda é a pressão regulatória. Frameworks como o EU AI Act classificam sistemas agentivos como potencialmente de alto risco quando operam com autonomia sobre infraestrutura crítica. A exigência de auditoria em tempo real (saber exatamente qual ação foi tomada, por qual agente, com qual justificativa) é atendida por governança de runtime, não por política documental.

A terceira é a economics do modelo. Classificadores pequenos e rápidos estão ficando mais baratos e mais capazes. O custo de rodar governança de runtime está caindo mais rápido que o custo de rodar os agentes que ela governa. Em algum momento nos próximos 12 meses, a governança será mais barata que o seguro cibernético que as empresas pagam para cobrir o risco de não tê-la.

O padrão que emerge dessas três forças é claro. Governança de agentes não será uma categoria de produto separada. Será uma camada de infraestrutura integrada a qualquer plataforma de agentes, tão fundamental quanto logging ou autenticação. Times que implementarem essa camada agora estarão competindo em autonomia real. Times que esperarem estarão competindo em redução de dano.

Plataformas como o Nexforce Agents já incorporam essa lógica na arquitetura de runtime. O Nexforce Work, ambiente de workspace para agentes de negócio, inclui camadas de permissão e aprovação que operam no caminho de execução. O Nexforce Code, plataforma de agentes para desenvolvimento, executa agentes em sandbox com governança configurável por projeto. Em ambos os casos, a governança é parte do loop de execução, não um overlay aplicado depois.

Referências e Leitura Complementar

• Governing agent autonomy with Auto-review, David Gomes e Travis McPeak, Cursor Blog, Junho 2026
• Building Effective Agents, Erik Schluntz e Barry Zhang, Anthropic Engineering, Dezembro 2024
• Implementing a secure sandbox for local agents, Ani Betts, Yash Gaitonde e Alex Haugland, Cursor Blog, Fevereiro 2026