Tempo estimado para leitura: 14 minutos
Agentes de IA começam a mudar de categoria dentro das empresas. Enquanto assistentes generativos recebem uma solicitação e devolvem uma resposta, agentes podem acessar sistemas, consultar dados, chamar ferramentas e executar ações que antes dependiam de pessoas ou de fluxos determinísticos.
Essa mudança amplia o potencial da IA, mas também altera a arquitetura necessária para operá-la com segurança. Quando um agente deixa de apenas recomendar uma ação e passa a executá-la, já não basta controlar o usuário que iniciou o processo. A organização precisa saber qual agente está agindo, em nome de quem, com quais permissões, sobre quais sistemas e sob quais limites.
Essa é uma das ideias centrais do conceito de Agentic Enterprise apresentado pela WSO2: APIs, integração, identidade e observabilidade continuam sendo fundamentais, mas precisam ser estendidas para que agentes operem como participantes identificáveis e governáveis da arquitetura empresarial.
Para quem decide arquitetura e investimento em tecnologia, a pergunta que define o projeto vem antes da adoção:
Quais controles precisam existir antes que esses agentes recebam autonomia para agir?
Por que agentes de IA mudam a arquitetura corporativa
Arquiteturas corporativas foram construídas durante décadas em torno de duas categorias relativamente previsíveis.
De um lado, pessoas autenticadas por sistemas de identidade. De outro, aplicações e serviços executando integrações, APIs e processos previamente definidos.
Agentes introduzem uma terceira categoria. Em 2025, a WSO2 estruturava sua visão de modernização em torno do conceito de Platformless Modernization. Em 2026, essa arquitetura passou a incorporar infraestrutura específica para agentes, incluindo identidade, ciclo de vida e governança.
Eles são software, mas podem receber objetivos de pessoas, decidir quais ferramentas utilizar durante a execução, trabalhar em nome de diferentes usuários e modificar seu comportamento conforme o contexto recebido.
Isso torna insuficiente tratar um agente apenas como uma conta de serviço ou reutilizar as credenciais de quem iniciou a tarefa.
A arquitetura precisa conseguir distinguir:
- a identidade do usuário;
- a identidade do agente;
- a autoridade que foi delegada;
- o escopo dessa autorização;
- os recursos acessados;
- os demais agentes e ferramentas acionados durante a execução;
- e a sequência de decisões que levou à ação final.
Na arquitetura proposta pela WSO2 para a empresa agêntica, esse problema aparece como uma combinação de caminhos controlados de entrada e saída, identidade e políticas, conectividade com ferramentas, integração entre sistemas, observabilidade, avaliações e guardrails. A mudança importante está em criar novos pontos de controle para workloads que agora podem decidir e agir autonomamente, preservando a infraestrutura que já funciona.
Identidade de agentes de IA: “quem é você, agente?”
Imagine um agente de atendimento de um banco autorizado a consultar a situação de um cliente e, em determinadas condições, solicitar uma alteração cadastral.
Quando essa chamada chega à API, saber apenas que existe um token válido não resolve o problema.
O sistema precisa conseguir responder:
- Qual agente fez a solicitação?
- Em nome de qual cliente ou funcionário?
- Que autoridade foi delegada a ele?
- Essa autorização vale para consultar dados ou também para alterá-los?
- Por quanto tempo ela permanece válida?
- Outro agente foi acionado durante o processo?
Essa distinção importa porque identidade e autorização respondem a problemas diferentes.
Reconhecer o agente prova quem está executando a ação. Delegação estabelece de onde veio a autoridade para executá-la. Escopo determina até onde essa autoridade chega.
A WSO2 passou a tratar agentes como identidades de primeira classe em sua camada de identidade. O Agent ID permite registrar, autenticar, autorizar e auditar agentes separadamente, incluindo cenários em que atuam autonomamente e situações em que executam tarefas em nome de um usuário.
Essa separação tem uma consequência importante para ambientes regulados: a trilha deixa de registrar apenas que determinada credencial acessou um sistema e passa a poder preservar a relação entre o agente que executou a ação e a autoridade que a originou.
Delegação de autoridade sem entregar a credencial do usuário
Um dos riscos de adaptar modelos tradicionais de autenticação aos agentes é fazer com que eles operem usando credenciais emprestadas ou permissões excessivamente amplas.
Nesse modelo, o sistema consegue reconhecer a conta, mas perde parte da informação necessária para distinguir o executor da ação de quem a autorizou.
Fluxos de delegação On-Behalf-Of procuram resolver esse problema mantendo o agente identificado durante a execução e vinculando a ele a autoridade concedida pelo usuário. A documentação atual da WSO2 demonstra justamente os dois cenários: agentes que operam com identidade própria e agentes que recebem autorização para agir em nome de outra identidade.
O princípio é mais relevante do que a implementação específica.
Em qualquer arquitetura com agentes, a organização deveria conseguir demonstrar:
Quem iniciou a delegação, qual agente recebeu a autoridade, quais permissões foram concedidas, quais recursos foram acessados e qual ação foi executada.
Quanto mais longa a cadeia entre humanos, agentes, subagentes e ferramentas, mais importante se torna preservar essa relação de ponta a ponta.
Agent Manager: governança do ciclo de vida dos agentes
Identidade responde quem é o agente. Ela não responde quantos agentes existem, quem responde por cada um e o que cada um está autorizado a fazer.
Essa pergunta aparece quando áreas diferentes começam a construir agentes com frameworks, modelos e runtimes distintos. Sem uma camada que registre o conjunto, a empresa descobre a resposta por incidente.
É essa camada que produtos como o WSO2 Agent Manager endereçam. Ela governa o agente como entidade que persiste no tempo: o registro de que ele existe, o dono que responde por ele, a versão que está em produção, o escopo que recebeu e a decisão de retirá-lo de operação.
O ciclo de vida define a governança. O agente entra em produção por aprovação, muda por versão, amplia o escopo por decisão registrada e sai por revogação, sempre com data, responsável e evidência. A analogia com API Management tem limites porque, em vez de apenas governar interfaces passivas, o agente é o próprio componente governado ao decidir quais ferramentas usar e em que ordem. Na prática, o Agent Manager declara a política definindo agente, dono, escopo e versão, enquanto o enforcement a valida em tempo de execução, evitando políticas vazias ou regras sem responsável.
Integração e MCP: sistemas expostos como ferramentas de agentes
A segunda mudança acontece na camada de integração.
Durante anos, integrar significou conectar aplicações, dados, eventos e APIs dentro de fluxos relativamente conhecidos. Com agentes, essas mesmas capacidades passam a ser consumidas dinamicamente como ferramentas.
O Model Context Protocol (MCP) surgiu como um dos padrões para criar uma interface comum entre agentes e recursos externos. Nesse modelo, sistemas corporativos podem expor capacidades que um agente descobre e utiliza durante a execução de uma tarefa.
O WSO2 Integrator atualmente combina esse modelo com mais de 600 conectores e suporte a MCP servers, permitindo que agentes participem de fluxos junto com aplicações e serviços tradicionais.
O número de conectores é menos importante que a mudança arquitetural por trás dele.
Integração deixa de servir apenas para movimentar dados entre sistemas e passa também a definir quais capacidades da empresa podem ser consumidas por agentes.
Isso aumenta o valor estratégico da camada de integração, mas também aumenta sua responsabilidade.
Expor uma função interna como ferramenta acessível por MCP envolve mais que conectividade. A decisão cobre:
- contrato;
- identidade;
- autorização;
- contexto;
- classificação de dados;
- limites de uso;
- observabilidade;
- consequências da execução.
Um agente é tão útil quanto as ações que consegue executar. Pela mesma razão, seu risco cresce conforme aumenta seu alcance.
Guardrails e governança de egress: aplicação de políticas durante a execução
A camada anterior define o que um agente pode fazer. Esta define o que cada chamada pode fazer no momento da execução.
Durante esse processo, o agente pode enviar contexto para um modelo externo, consultar uma API, acessar um banco de dados, acionar um servidor MCP ou outro agente. Cada interação pode movimentar dados, transmitir instruções ou gerar efeitos fora do sistema que iniciou o fluxo.
Governança de egress responde por onde a chamada pode sair: qual é o destino autorizado, sob qual regra de residência do dado, com qual limite de volume. Guardrails respondem o que ela pode carregar e provocar: qual dado atravessa no prompt, qual ferramenta fica acionável, qual ação exige aprovação antes de acontecer.
Heinrich Eberhardt | Chief Technology Officer - TreeID
A segurança empresarial tradicional foi construída para controlar quem entra. O agente torna o mesmo rigor necessário na saída, porque é ali que o dado deixa o perímetro e a ação produz efeito.
Para serviços financeiros e seguros a diferença é operacional. Uma política aplicada depois da execução explica um incidente. Uma política aplicada no caminho da execução pode impedir que ele aconteça.
Na WSO2Con 2026, a WSO2 apresentou um Policy Hub com mais de 40 políticas e guardrails para tráfego de IA, com mecanismos de PII, segurança de prompt e verificações aplicadas às interações com modelos. O número absoluto de controles importa menos que o ponto onde eles são avaliados.
Como essas políticas são escritas, avaliadas e testadas é o tema de AI agent guardrails: runtime enforcement.
O que muda para uma empresa que já possui APIs, IAM e integração
A adoção de agentes não significa necessariamente reconstruir a arquitetura empresarial.
Instituições que já operam API Management, integração corporativa, IAM, observabilidade e controles de segurança têm parte importante da fundação necessária.
A questão é verificar se esses componentes conseguem responder às novas características do workload.
Por exemplo:
- Identidade: o agente possui identidade própria ou utiliza uma conta genérica?
- Delegação: é possível provar de onde veio a autoridade utilizada em cada ação?
- Autorização: as permissões são específicas para o agente, usuário, contexto e ferramenta?
- Integração: as capacidades expostas a agentes possuem contratos e controles adequados?
- Egress: chamadas para modelos, APIs e ferramentas externas passam por enforcement?
- Observabilidade: é possível reconstruir uma execução envolvendo modelo, agente, API, integração e sistema de registro?
- Governança: existe inventário dos agentes em produção, owner definido e processo para revogar acessos ou retirar um agente?
Essas perguntas são mais úteis do que começar a discussão escolhendo uma nova plataforma.
Em alguns ambientes, as capacidades existentes podem ser estendidas. Em outros, uma camada específica de gerenciamento e identidade para agentes reduz a quantidade de controles que precisariam ser construídos internamente.
No ecossistema WSO2, Agent Manager e Agent ID passam a ocupar justamente essa função: um controla o ciclo operacional e a governança dos agentes; o outro trata sua identidade, autenticação, autorização, delegação e auditoria. A documentação atual da WSO2 mantém Agent ID também dentro da Identity Platform, ao lado de Identity Server e Security Token Service.
ThunderID faz parte dessa evolução tecnológica, mas deve ser entendido separadamente. A WSO2 o apresentou em 2026 como um novo runtime IAM open source, desenvolvido em Go e preparado para cenários como identidade de agentes, identidade descentralizada e criptografia pós-quântica. Isso não significa, porém, que organizações precisem substituir automaticamente o Identity Server para adotar identidade de agentes.
A fundação de dados e operação que sustenta esses workloads em escala é o tema de Como escalar agentes de IA em bancos.
O que decidir agora antes de colocar agentes em produção
Nem toda organização precisa implantar imediatamente uma arquitetura completa para milhares de agentes, mas algumas decisões ficam progressivamente mais caras de corrigir depois que os agentes chegam à produção.
- A primeira é identidade. Agentes não deveriam nascer compartilhando contas técnicas genéricas se depois a empresa precisará atribuir ações individualmente.
- A segunda é delegação. Autoridade transferida entre usuário, agente, subagente e ferramenta precisa permanecer rastreável.
- A terceira é escopo. Um agente deveria receber somente o acesso necessário para executar a tarefa. Herdar toda a capacidade da pessoa ou do sistema que o iniciou amplia o risco sem necessidade.
- A quarta é observabilidade. Logs precisam acompanhar a execução de ponta a ponta, atravessando a fronteira de cada API no caminho.
- A quinta é governança de integração. Expor APIs, sistemas e dados como ferramentas disponíveis para agentes amplia a superfície operacional e exige controles antes da exposição.
- A sexta é egress. A empresa precisa saber quais dados e instruções estão deixando seu perímetro durante as chamadas feitas pelos agentes.
A escolha entre WSO2, hyperscalers ou outras plataformas vem depois dessas definições.
Uma arquitetura durável começa determinando qual autonomia a organização pretende conceder e quais evidências precisa manter sobre cada decisão executada. A pergunta sobre qual ferramenta gerencia agentes vem na sequência.
Perguntas frequentes
Governança de APIs define contratos, autenticação, autorização, políticas de tráfego e condições de consumo de uma interface. Governança de agentes acrescenta controles sobre o ator que utiliza essas interfaces: identidade, ownership, delegação, ferramentas autorizadas, comportamento, ciclo de vida e rastreabilidade das ações.
As duas camadas são complementares. Agentes bem governados ainda precisam consumir APIs governadas.
Não necessariamente. O ponto inicial deve ser avaliar se a infraestrutura atual consegue reconhecer agentes separadamente, emitir credenciais adequadas, aplicar autorização granular, preservar delegação e produzir uma trilha de auditoria suficiente. A necessidade de extensão ou substituição depende dessa análise.
No ecossistema WSO2, por exemplo, Agent ID aparece atualmente integrado à própria Identity Platform e ao Identity Server.
Contas de serviço podem autenticar uma chamada, mas tendem a ser insuficientes quando vários agentes, usuários e cadeias de delegação compartilham a mesma identidade técnica. Nesse cenário, provar exatamente qual agente executou uma ação e de onde veio sua autoridade torna-se mais difícil.
Não. MCP padroniza a forma como agentes encontram e utilizam ferramentas, mas não elimina a necessidade de identidade, autorização, políticas, classificação dos dados, observabilidade e governança das capacidades expostas. Justamente porque MCP facilita o acesso às ferramentas, esses controles se tornam mais importantes.
Pelo caso de uso e pela decisão que o agente deverá executar.
Antes de ampliar sua autonomia, mapeie quem autoriza a ação, quais sistemas serão acessados, quais dados atravessam o fluxo, quais permissões são necessárias, quais ações são reversíveis e quais evidências precisam permanecer disponíveis depois da execução.
Antes de escalar agentes de IA, prove quem está agindo
A utilidade de um agente cresce com o número de sistemas que ele consegue acessar e com as ações que consegue executar. O risco cresce pelas mesmas duas dimensões.
Por isso, a discussão sobre Agentic Enterprise deveria começar pela capacidade da arquitetura de identificar, limitar, observar e interromper cada agente quando ele deixa de apenas recomendar e passa a agir. A quantidade de agentes que a organização pretende construir vem depois.
Para bancos e outras operações críticas, há uma pergunta ainda mais objetiva: se um agente executar hoje uma ação relevante sobre um cliente, dado ou sistema, a organização consegue provar qual agente agiu, em nome de quem, com qual autorização e dentro de qual política?
Se essa cadeia ainda não pode ser demonstrada de ponta a ponta, a próxima decisão é fortalecer a fundação que deverá sustentar essa autonomia, antes de ampliá-la.
Seu desafio merece uma conversa estratégica
A prática de Integração & APIs da TreeID atua justamente nessa camada de decisão: avaliando identidade, integrações, APIs, observabilidade e controles existentes para determinar o que pode ser reaproveitado, o que precisa evoluir e quais componentes fazem sentido para colocar agentes em produção sem que autonomia vire perda de controle.