Governança de Agentes de IA: Os Cinco Pilares Que Você Constrói, Não Escreve

O que a governança de agentes realmente governa

Jane, uma engenheira de suporte, digita uma frase em um copilot de suporte: prepare um resumo de reembolso para o ticket #4521. O copilot a repassa para um agente planejador, que chama um agente de pesquisa (ticket Zendesk, bug Jira vinculado) e um agente de faturamento (registro de pagamento Stripe). Uma solicitação humana, seis chamadas de máquina para máquina, a maioria feita por software que decidiu por conta própria chamar mais software.

Essa cadeia — usuário → aplicação → agente → subagente → ferramenta MCP — é o caminho de chamada agentic, e é isso que a governança de agentes precisa controlar. Todo modelo de acesso empresarial se apoia em três premissas: um usuário está na origem da solicitação, o elemento que faz a chamada é esse usuário, e o escopo é aquele com o qual o usuário consentiu. No terceiro salto, todas as três premissas se tornam falsas, portanto três perguntas deixam de ter resposta:

• Para quem é esta chamada? O usuário se autenticou três saltos atrás. A identidade dele ainda está na solicitação ou uma conta de serviço a substituiu?
• Quem a está realizando? Um token de portador (bearer token) prova a posse de uma credencial, mas não qual dos seus duzentos agentes a detém.
• O que ele pode fazer? Um token gerado para o primeiro destinatário da chamada é superprivilegiado para todos os destinatários seguintes.

Responder a essas três perguntas em cada salto, com evidências, é o que significa governança de IA agentic — cinco sistemas, e não um parágrafo sobre uso responsável.

O agente é um terceiro tipo de principal

A maioria das equipes recorre a um de dois atalhos: permitir que o agente retransmita o token do usuário ou atribuir a ele uma conta de serviço compartilhada. Ambos estão incorretos, porque um agente não é nenhuma dessas coisas.

Atribuir a cada agente sua própria identidade verificável é a decisão da qual todo o resto depende. Isso garante atribuição, pois o receptor consegue identificar qual agente fez a chamada; política por agente, já que o copilot da Jane lendo o Jira e seu agente de engenharia gravando nele são principais diferentes, mesmo que ambos atuem em nome da Jane; e ausência de agentes anônimos, porque uma ferramenta acessível apenas por uma identidade registrada transforma o registro no ponto de aplicação.

A urgência é pragmática: as identidades de máquina já superam os usuários humanos na maioria das empresas por mais de 40 para 1, e os agentes se multiplicam mais rápido do que as contas de serviço jamais se multiplicaram — qualquer pessoa com um framework e uma chave de API pode criar um.

Os cinco pilares

A governança completa consiste em cinco capacidades em ciclo contínuo. As duas primeiras são executadas antes que um agente faça uma única chamada, as duas intermediárias a cada chamada, e a última continuamente — alimentando de volta a segunda.

O Pilar 4 é onde a governança se conecta à execução prática. A cada salto, o gateway resolve o chamador, verifica se este agente pode chamar este destino e atuar em nome deste usuário, gera um novo token delimitado estritamente ao próximo destinatário, executa guardrails e, em seguida, retransmite e registra. Três propriedades surgem naturalmente: atribuição por salto, tokens de menor privilégio (um token vazado serve apenas para um único destinatário e escopo) e revogação centralizada.

Por que o gateway, e não o IdP

Cada pilar poderia residir em uma ferramenta diferente. O que mantém o modelo coeso é a aplicação no gateway presente no caminho da chamada — o único componente que enxerga cada salto independentemente do framework ou da nuvem, propaga a identidade, restringe a autoridade a cada etapa e é neutro em relação à plataforma. O Entra governa agentes do Entra, o Okta governa apps do Okta, o Bedrock governa agentes do Bedrock; o gateway governa o caminho entre todos eles, que é onde reside o risco — um ponto que aprofundamos em governança de agentes de IA em múltiplas plataformas. Um provedor de identidade sem um gateway emite credenciais perfeitas que depois são retransmitidas sem controle; um registro sem um gateway é apenas documentação.

Onde as equipes erram

Tratar o registro como uma planilha. Um registro que os agentes podem ignorar inventaria apenas os agentes que você já conhecia. Ele ganha força quando atua como o ponto de controle: sem identidade registrada, não há chamada.

Retransmitir um token poderoso para todos os lugares. A maneira mais rápida de fazer as chamadas funcionarem e a rota mais rápida para um vazamento. Os agentes podem sofrer injeção de prompt (prompt injection) para fazer uso indevido de qualquer credencial que possuam, portanto ela nunca deve ser mais abrangente do que a próxima chamada exige.

Revisar contas em vez de cadeias. Três agentes em um fluxo de compras — um cria registros de fornecedores, um lê dados bancários de fornecedores, um inicia pagamentos — parecem aceitáveis isoladamente. Encadeados, eles formam um caminho de pagamento que nenhum revisor teria aprovado: a separação de funções, recriada por software.

Assumir que o escopo de um agente é estático. Um agente financeiro que recebe acesso a um novo módulo de ERP pode começar a atuar sobre dados que seu escopo nunca cobriu — não por uma falha, mas porque adaptar-se é o que os agentes fazem. O comportamento precisa ser comparado com a autoridade definida continuamente, e não trimestralmente.

Quer isso como um sistema em execução em vez de um diagrama?

Registre um agente, atribua uma identidade a ele e conceda acesso a um servidor MCP.

Comece gratuitamente

A parte difícil: duas respostas para "quem fez isso?"

Quando o agente de pesquisa lê os tickets no Jira da Jane, a resposta honesta para quem fez isso inclui ambos: Jane e o agente de pesquisa. Remova qualquer um dos dois e você perderá informações essenciais. Existem duas maneiras de carregar isso em um token, e essa escolha determina se você terá uma trilha de auditoria completa ou não.

Para agentes, você quase sempre desejará delegação. O token delegado mantém o usuário como sub e indica o agente atuante em act; chamadas encadeadas aninham as claims, sendo a mais externa o agente atuante mais recente:

Duas claims complementares dividem essa função. may_act é o controle preventivo — se este agente atuante pode atuar por este sujeito — verificado antes que o token seja emitido. act registra quem realmente atuou. Autorize com base no agente atuante atual, no sujeito e na política; mantenha a cadeia aninhada para análise forense.

O mecanismo por trás disso é a troca de tokens (token exchange). A RFC 8693 a define: apresente um token de sujeito e, opcionalmente, um token de agente atuante, e receba um novo token delimitado ao público de destino. Os provedores chamam isso de On-Behalf-Of (OBO). Uma propriedade vale a pena memorizar — uma troca de tokens nunca amplia a autoridade. O token emitido concede a interseção do que o usuário pode fazer, do que o agente pode fazer e do que o destino aceita, de modo que cada salto é mais restrito do que o anterior. Entre domínios de confiança, a concessão ID-JAG da IETF (Cross App Access da Okta) assume o controle, emitindo uma concessão de curta duração no seu IdP que o próprio servidor de autorização do destino resgata.

Como isso funciona na TrueFoundry

A TrueFoundry mapeia os cinco pilares nas superfícies do produto. Ser claro sobre o que existe hoje importa mais do que uma tabela com aparência completa, portanto a disponibilidade é indicada de forma transparente.

O registro

Cada agente recebe uma entrada, independentemente de onde seja executado — Bedrock, Vertex, LangGraph, um serviço HTTP personalizado, um agente A2A ou um copilot no SaaS de terceiros. Nada muda de lugar, nada precisa ser reescrito.

O registro é um assistente de quatro etapas: Metadata, Agent Identity, Config, Access Control.

Identidade

A etapa dois define como o agente prova quem ele é. TrueFoundry-backed significa que a TrueFoundry emite e assina o token, a opção padrão ideal para agentes que você mesmo executa. Identity provider-backed significa que o agente apresenta um token do Okta, Entra, qualquer provedor OIDC ou um endpoint SPIFFE/SPIRE, com os valores de claim mapeados para o agente.

A etapa Config define se o Agent Gateway fica à frente. Proxy via Gateway significa que os chamadores acessam uma URL da TrueFoundry e o gateway autentica, aplica políticas e retransmite. Embedded significa apenas governança: uma identidade e permissões, sem proxy de entrada. É assim que você governa um copilot dentro de um produto de terceiros — não é possível controlar a porta de entrada dele, mas suas chamadas de saída ainda passam pelos seus gateways.

Controle de acesso do agente

O acesso é baseado em listas de permissões (allow-lists); não há configuração de negação, porque a ausência de permissão já é a negação. Os colaboradores podem ser um usuário, uma equipe ou outro agente, com as funções Agent Manager (visualizar e editar) ou Agent Access (invocar e ser representado por ele). Owner é um campo opcional separado que deve ser uma equipe — o ponto focal de responsabilidade.

Observe o que essa lista faz: ela define tanto quem pode chamar o agente quanto quem o agente pode representar. Conceder essa permissão para a equipe nativa everyone atribui ao agente um alcance de delegação por todo o tenant — mais amplo do que a maioria dos agentes precisa.

A outra direção funciona de forma idêntica: adicione o agente como colaborador em cada servidor MCP ou modelo, com o sujeito agent:<name>, no mesmo seletor usado para usuários e equipes.

Para restringir um agente a um subconjunto de ferramentas de um servidor, organize esse subconjunto como um Virtual MCP Server e conceda acesso a ele; a limitação do escopo de ferramentas por agente na concessão estará disponível em breve.

Guardrails, em cada salto

O controle de acesso decide se uma chamada acontece. Os guardrails decidem o que ela pode conter e não fazem distinção de quem está chamando. Os agentes aumentam os riscos por um motivo: um chatbot com uma resposta ruim gera constrangimento, enquanto um agente com uma resposta ruim executa ações baseadas nela. O resultado de cada ferramenta entra novamente no contexto do modelo e pode carregar uma injeção de prompt, portanto as entradas precisam ser verificadas mesmo quando o usuário é de confiança.

Uma linha de base viável: ocultação de PII e detecção de injeção de prompt na entrada do LLM, detecção de segredos na saída, higienizadode SQL e linter de segurança de código antes da ferramenta, e ocultação após a ferramenta. Inicie cada regra no modo Audit antes de promovê-la — um salto bloqueado pode interromper toda a cadeia.

Auditoria

Como a aplicação das políticas e a observação ocorrem no mesmo local, a trilha é completa por construção. Cada rastro (trace) registra qual agente fez a chamada e em nome de qual usuário ele atuou — ambas as metades do problema de duas respostas.

Cada guardrail executado aparece como um span próprio: o que foi verificado, se foi aprovado, o que foi identificado ou ocultado. Solicitações bloqueadas também são registradas — um salto negado é uma evidência, não uma lacuna.

Acima dos rastros, um único painel cobre todos os agentes registrados, independentemente de onde sejam executados: contagem de solicitações, percentuais de latência, taxas de erro e uso ao longo do tempo. A detecção de desvios (drift) e os alertas de anomalia são desenvolvidos sobre isso e estarão disponíveis em breve.

Um exemplo prático

Vamos governar o copilot de resumo de reembolso mencionado no início deste post.

Registre os agentes. O planejador, o de pesquisa e o de faturamento recebem, cada um, uma entrada com uma descrição e uma equipe Owner. O copilot do fornecedor é registrado como Embedded — sem URL, apenas governança, mas suas chamadas de saída agora são governadas.

Atribua uma identidade a cada um. TrueFoundry-backed para os três que você executa; o copilot embarcado aponta para o seu IdP, com os valores de claim mapeados.

Conceda o menor privilégio, em ambas as direções. No agente de pesquisa, adicione a equipe de suporte com Agent Access — definindo tanto quem pode invocá-lo quanto quem ele pode representar. Em seguida, adicione agent:research-agent como colaborador nos servidores MCP do Zendesk e do Jira, e em nenhum outro. O agente de faturamento recebe acesso ao Stripe. Nenhum dos dois acessa as ferramentas do outro, pois a ausência de uma concessão resulta em um 403.

Propague a identidade em cada chamada. Uma chamada delegada carrega dois tokens de portador: o usuário no cabeçalho Authorization e o agente em x-tfy-agent-authorization. Cada agente insere seu próprio cabeçalho de agente e repassa o token do usuário, permitindo que o gateway verifique cada salto em relação ao agente que realmente está fazendo a chamada.

Ative os guardrails e monitore. Associe a detecção de injeção de prompt aos modelos e a ocultação pós-ferramenta aos servidores; em seguida, confirme em Request Traces que uma chamada de research-agent exibe research-agent como chamador e Jane como a usuária em cujo nome ele atuou.

Uma limitação real: atualmente, o token do usuário passa junto com o cabeçalho do agente em vez de ser trocado por um novo token delimitado ao público de destino a cada salto. A troca completa de tokens por salto estará disponível em breve.

Pronto para colocar um agente sob um ponto de controle real?

Registre o agente, limite seu escopo a um servidor MCP e analise o rastro.

Comece gratuitamente na TrueFoundry

Cuidados importantes que você deve saber

Um agente não pode concluir um fluxo de código de autorização OAuth2. Não há um ser humano para aprovar a tela de consentimento e, de qualquer forma, o token pertenceria a essa pessoa. Esse tipo de servidor retorna MCP server authentication required para um token de agente, mesmo quando o agente é um colaborador. Em vez disso, utilize credenciais de cliente (client credentials).

Os guardrails de saída são ignorados em respostas via streaming. Eles precisam da resposta completa para serem avaliados, portanto, para etapas de agentes cuja saída alimenta uma chamada de ferramenta, prefira usar stream: false.

O token do agente é o próprio agente. Mantenha-o fora do controle de versão e de qualquer conteúdo que o modelo possa ler. Um agente que pode sofrer indução via prompt para divulgar seu próprio token pode ser personificado.

Leituras relacionadas

• Governança de Agentes de IA em Múltiplas Plataformas — quando a governança para na fronteira da plataforma
• Engenharia de Grafos para Agentes de IA — avaliando o nó versus governando as arestas
• Controle de Acesso MCP com um Gateway MCP — permissões no nível de ferramenta e de servidor
• RBAC vs ABAC para Agentes de IA — o modelo de acesso por trás das concessões
• Construindo uma Estrutura de Governança de IA — o panorama geral de políticas

Conclusão

A maior parte do conteúdo sobre gerenciamento de agentes de IA corporativos trata a governança como um exercício de redação: definir uso aceitável, nomear um comitê e publicar o padrão. Nada disso resiste ao terceiro salto de um caminho de chamada, onde a questão não é se uma ação foi apropriada, mas se a sua infraestrutura consegue identificar quem a realizou.

Os cinco pilares são úteis justamente porque cada um nomeia um sistema em vez de um princípio. A descoberta é um scanner. O registro é um banco de dados que o gateway se recusa a ignorar. A autenticação representa duas credenciais em uma solicitação. A autorização é uma permissão que retorna 403 quando ausente. A auditoria é um rastro contendo tanto o agente quanto o usuário. Ao construir esses sistemas, a pergunta complexa — quem fez isso e em nome de quem — terá uma resposta clara que você poderá demonstrar.

Governe seu primeiro agente na TrueFoundry

Gratuito para começar