Nos dois artigos anteriores, a pergunta era onde a governança de agentes quebra. Primeiro, no tempo: um agente pode estar autorizado quando recebe uma tarefa e perder essa autoridade antes de executá-la. Depois, no caminho: a ação pode atravessar ferramentas, APIs e outros agentes, ampliando a capacidade operacional sem que a autoridade tenha sido ampliada junto. Resta o problema de construção: como criar um sistema que impeça as duas coisas.
A resposta não está em mais uma política de uso responsável de IA, nem em acrescentar agentes a uma matriz tradicional de IAM. A empresa precisa começar a tratar a autoridade como uma propriedade operacional, que acompanha cada ação desde a intenção até o efeito. Quem autorizou? Para quê? Por quanto tempo? Com quais limites? O que pode ser delegado? O que precisa ser revalidado? E como revogar tudo quando a autorização deixa de existir?
Antes de detalhar as camadas, é preciso definir onde elas atuam. O ponto de controle passa a ficar entre a intenção do agente e a chamada da ferramenta. A política continua sendo escrita fora do sistema. A decisão sobre aplicá-la precisa acontecer dentro do sistema, naquele intervalo, quando uma camada de autorização ainda pode avaliar identidade, contexto, escopo, risco e cadeia de delegação antes de liberar a ação. É aí que se materializa a governança em tempo de execução. É nesse ponto que as informações dessas camadas precisam se encontrar antes de a ação ser liberada.
Primeira camada: inventário
Não basta saber quais modelos ou agentes a empresa contratou. É preciso saber quais agentes podem agir, em nome de quem, sobre quais sistemas e com quais consequências. Um agente que consulta um CRM não tem a mesma exposição de outro que altera preços. Um que prepara uma transferência não deveria carregar a mesma autoridade daquele que efetivamente a executa. A classificação precisa sair do modelo e chegar à ação.
Isso exige uma espécie de passaporte de autoridade para agentes. Não necessariamente um documento, mas uma identidade verificável que acompanhe cada agente e permita responder, em tempo real, a quatro perguntas: quem é, quem o autorizou, qual é o escopo dessa autorização e qual é a cadeia de delegação que trouxe aquele poder até ele. Sem isso, a empresa pode até saber qual credencial foi usada. Não sabe necessariamente de onde veio a autoridade.
Segunda camada: atenuação
Se um executivo autoriza um agente a consultar dados de clientes, esse agente não deveria poder transferir para outro um poder maior do que recebeu. A delegação precisa carregar limites consigo. O agente seguinte pode ter menos autoridade, nunca mais. Pode perder acesso a determinadas ferramentas, operar dentro de um valor máximo, executar apenas determinadas classes de ação ou exigir aprovação antes de produzir efeitos irreversíveis.
Essa atenuação já tem base técnica. Extensões do OAuth, como a troca de tokens (RFC 8693) e a autorização rica (RFC 9396), já oferecem mecanismos para representar delegação e restringir o escopo de uma autorização. Há inclusive um caminho mais elegante: tokens que carregam suas próprias restrições e podem ser atenuados sem consultar quem os emitiu, como Macaroons e Biscuit. O mercado, porém, se concentrou no OAuth, enquanto esses modelos criptograficamente mais rigorosos permaneceram de nicho. O princípio da atenuação é padrão; aplicá-lo de ponta a ponta em cadeias de agentes ainda não é.
Terceira camada: revalidação
Uma autorização não deveria ser considerada válida apenas porque a credencial continua válida. Antes de uma ação relevante, o sistema precisa conseguir verificar se a autoridade ainda existe naquele contexto. O orçamento mudou? O fornecedor entrou em bloqueio? O usuário retirou o consentimento? Outro agente já executou a operação? O risco da ação subiu? Se a resposta for sim, a ação precisa parar ou voltar para aprovação.
Quarta camada: revogação
Em arquiteturas tradicionais, revogar uma credencial pode ser suficiente. Em uma arquitetura multiagente, não necessariamente. Se A delegou autoridade a B, que acionou C, retirar a autorização de A precisa produzir um efeito em B e C. A revogação precisa viajar pela mesma cadeia pela qual a autoridade viajou.
Um exemplo torna o problema concreto. Um diretor financeiro (A) autoriza um agente de compras (B) a fechar pedidos com fornecedores homologados até um teto de R$ 50 mil. Para cumprir a tarefa, B aciona um segundo agente (C), encarregado de emitir a ordem de pagamento no sistema bancário. A autoridade partiu de A, passou por B e chegou a C, perdendo escopo a cada passo: C só pode pagar o que B contratou, dentro do teto que A definiu. Se A revoga a autorização no meio do processo, porque o fornecedor entrou em bloqueio ou o orçamento foi congelado, retirar apenas a credencial de A não basta. B já delegou a tarefa. C está prestes a executar o pagamento. A revogação precisa alcançar C antes da chamada final, percorrendo a mesma cadeia pela qual a autoridade chegou até ele. Se não alcançar, o sistema executará uma ordem que já não estava autorizada, e o log registrará um pagamento tecnicamente válido, feito sob uma autoridade que havia deixado de existir.
Quanto mais longa a cadeia, mais importante se torna saber se essa revogação é imediata, propagada ou apenas registrada para posterior auditoria.
Essa propagação é, em agosto de 2026, um problema em aberto. Os padrões existentes resolvem apenas partes. O mecanismo de revogação do OAuth (RFC 7009) invalida um token isolado, não os que dele derivaram. A troca de tokens delega bem um único salto, mas não a cadeia inteira. Na prática, a indústria contorna o problema com autorizações de vida curta, que expiram sozinhas em vez de serem revogadas. A infraestrutura de certificados digitais percorreu o mesmo caminho: em dezembro de 2024, o Let’s Encrypt anunciou o fim do OCSP, o protocolo que checava revogação em tempo real, e migrou para certificados de duração curta. É uma pista de que, para agentes, uma solução de curto prazo pode ser reemitir autoridade com frequência, em vez de depender de revogação em cadeia.
Quinta camada: o humano no ponto certo
A última camada é humana, o que não significa colocar uma pessoa para aprovar tudo. Isso destruiria justamente o ganho de escala que tornou os agentes atraentes. O objetivo é definir onde a máquina pode decidir sozinha e onde a autoridade precisa voltar para um humano. Ações reversíveis e de baixo impacto podem seguir automaticamente. Ações financeiras, jurídicas, reputacionais ou irreversíveis podem exigir uma confirmação. O desenho coloca o humano no ponto certo do circuito, não em todo o circuito.
A camada que prova por que a ação era legítima
As cinco camadas só funcionam se deixarem rastro. Isso muda o papel da auditoria. O log não pode registrar apenas “quem chamou qual API”. Precisa preservar a proveniência da autoridade: qual intenção originou a ação, quem delegou o poder, quais políticas estavam vigentes, quais agentes participaram da cadeia e qual decisão liberou a execução. O registro deixa de ser a fotografia do que aconteceu e passa a permitir reconstruir por que aquele agente estava autorizado a fazer aquilo.
Há uma consequência organizacional. A autoridade de agentes não cabe mais apenas ao CIO, ao CISO ou ao jurídico. IAM, segurança, dados, risco, compliance e negócio passam a compartilhar uma mesma pergunta: quem pode fazer o quê, em nome de quem, em qual contexto e por quanto tempo? A governança de agentes começa a parecer menos com um comitê e mais com uma infraestrutura transversal.
O mercado ainda está construindo as peças dessa arquitetura, e a cronologia mostra o quanto isso é recente. A OpenID Foundation publicou seu documento sobre identidade para IA agêntica em outubro de 2025. A Auth0 e a Okta levaram produtos de identidade para agentes à disponibilidade geral entre novembro de 2025 e abril de 2026. Os primeiros perfis de autorização para a era dos agentes foram aprovados como rascunho em junho de 2026. Fornecedores de identidade, motores de política, corpos de padrões e a Cloud Security Alliance trabalham em paralelo, com especificações que se sobrepõem. Ainda não emergiu uma arquitetura dominante. A consultoria Forrester resume o estado da arte: os padrões individuais avançam, mas a integração entre eles ainda não é responsabilidade de ninguém.
O custo de adiar esse desenho já aparece nas projeções. O Gartner estima que, até 2027, 40% das organizações rebaixarão ou desligarão agentes autônomos diante de lacunas de governança reveladas por incidentes. A projeção é menos interessante pelo número do que pelo mecanismo que revela: a adoção pode avançar mais rápido que a capacidade de controlar o que os agentes fazem.
Para um executivo, portanto, o primeiro passo não é comprar uma nova plataforma de governança de IA. É mapear a autoridade que já está circulando. Escolher alguns fluxos de alto impacto e reconstruir a cadeia: quem inicia a ação, qual agente recebe a tarefa, quais ferramentas ele pode chamar, quais outros agentes pode acionar, quais dados atravessam o percurso e qual mecanismo pode interromper a operação antes que ela produza efeito.
Esse exercício provavelmente revelará algo desconfortável. A empresa talvez saiba quem contratou cada agente, mas não saiba quem pode agir em nome de quem. Pode conhecer as permissões registradas no IAM, mas não a autoridade efetiva produzida pela combinação entre agentes, ferramentas e APIs. Pode ter logs completos e, ainda assim, não conseguir explicar por que uma determinada ação era legítima quando aconteceu.
É aí que a nova governança começa. A pergunta deixa de ser “o que a IA pode fazer?” e passa a ser: como garantir que ela só faça aquilo que continua autorizada a fazer, pelo caminho que continua autorizado a percorrer?
A próxima fronteira da governança de agentes não será um novo conselho, uma nova política nem mais uma matriz de risco. Será a infraestrutura que transforma autoridade em algo verificável, limitado, rastreável e revogável antes que a ação aconteça.