Resumo executivo
Gerenciar internamente a identidade de agentes de IA Enterprise rapidamente se transforma em um fardo contínuo de governança e conformidade. Isso exige a centralização da autenticação, autorização, gerenciamento do ciclo de vida do token e registro de auditoria em todos os agentes internos, de terceiros e paralelos. Criar uma camada de acesso personalizada leva a pontos cegos de segurança, falhas de conformidade durante auditorias e sobrecarga contínua de engenharia à medida que as especificações do MCP e do OAuth evoluem.
Investir em uma camada centralizada de identidade de agentes permite que as Enterprise desacoplem o acesso às ferramentas do gerenciamento de credenciais, ao mesmo tempo que possibilita a auditabilidade contínua e a segurança Zero Trust — e mantém seus engenheiros focados no desenvolvimento dos agentes que ajudam a executar tarefas essenciais para os negócios.
O que é uma camada de identidade de agente de IA e como ela é construída?
Quando os agentes de IA começaram a agir em vez de apenas responder a perguntas, as equipes de plataforma tiveram que conectá-los rapidamente a ferramentas e dados reais. Muitas equipes acabaram construindo uma camada de acesso por conta própria, que geralmente possui três componentes principais:
- Um gateway de Model Context Protocol (MCP) que encaminha o tráfego de agentes para servidores MCP
- Um corretor de tokens que armazena e atualiza as credenciais de cada usuário para os aplicativos SaaS que os agentes chamam
- Filtragem de escopo baseada em funções que limita quais ferramentas um agente pode usar com base na função do usuário
Essas implementações exigiram meses de trabalho de engenharia, colocaram agentes em produção e mantiveram as credenciais fora dos prompts. Para a maioria das equipes, construir era a única opção na época.
Baixe nosso whitepaper Identidade de agente de IA: construir vs. comprar para descobrir por que adquirir uma camada de identidade desenvolvida especificamente para esse fim é a maneira mais eficaz de gerenciar agentes de IA ao longo de todo o seu ciclo de vida, sem sobrecarregar sua equipe de engenharia com a manutenção contínua de identidades.
As seis questões críticas de identidade para agentes de IA Enterprise
À medida que a adoção de agentes aumenta e eles assumem tarefas mais críticas para os negócios, as equipes percebem que precisam responder a mais perguntas:
- Identidade do agente: Quem é cada agente?
- Propriedade: Quem é o proprietário do agente?
- Delegação: Em nome de quem o agente está agindo?
- Escopo: Que ferramentas e recursos ele pode alcançar?
- Trilha de auditoria: Quais ações específicas foram tomadas?
- Botão de desativação: como as equipes podem revogar acesso ou desativar rapidamente o acesso?
Como o escopo cresce
A primeira versão da construção de uma camada de acesso ao agente é gerenciável. Uma equipe cria alguns agentes, atribui a cada um uma identidade de serviço, armazena os tokens SaaS dos usuários em um broker e mantém uma lista dos agentes existentes e de quem os criou. Para uma única equipe cujos agentes permanecem dentro de sua própria plataforma, esse design funciona bem.
Então, a população de agentes e as necessidades do negócio continuam crescendo. Cada novo app SaaS que seus agentes acessam executa seu próprio servidor de autorização com seu próprio modelo de consentimento, tempo de vida dos tokens e comportamento de revogação, portanto, o broker precisa de uma integração adicional. Outras equipes começam a lançar agentes de acordo com seus próprios cronogramas, e alguns nunca passam pela camada que sua equipe de plataforma construiu.
Os Developers executam agentes de codificação como Claude Code, Codex e Cursor em seus laptops, e esses agentes se conectam diretamente aos servidores MCP e repositórios de códigos colando tokens em um arquivo de configuração local, pois nunca passam pela compilação central. Os agentes nas plataformas dos fornecedores acessam seus dados por meio dos conectores próprios do fornecedor. Agentes incorporados, enxames de agentes e modelos locais expõem novas lacunas, e cada nova integração adiciona carga a uma pilha de identidades da qual agora dependem Workflows mais críticos.
Nessa altura, a equipe que construiu uma camada de acesso para seus próprios agentes já está executando um produto de identidade para o restante da empresa.
Gerenciar sua própria Identity Governance significa que a temporada de auditorias nunca termina.
Muitas organizações começam com um simples registro de agentes: uma lista de cada agente, quem o possui e as ferramentas e apps que ele pode acessar. Isso deixa de funcionar quando outras equipes lançam agentes, os proprietários mudam de função ou deixam a empresa, e os auditores solicitam comprovação de que alguém revisou o acesso de cada agente neste trimestre.
Essas evidências raramente ficam concentradas em um só lugar. O gateway registra uma coisa, o broker registra outra e os apps SaaS acessados pelo agente registram uma terceira; portanto, comprovar o que aconteceu significa extrair registros de cada sistema e correlacioná-los manualmente.
Para realmente dimensionar os agentes, a maioria das equipes descobre que o registro também precisa fazer mais: reatribuir ou desativar agentes cujos proprietários não estejam mais presentes, executar certificações de acesso periodicamente e mostrar quem autorizou uma ação, para quem e sob qual política, meses depois de ela ter ocorrido. Esse trabalho se repete a cada ciclo de auditoria e aumenta a cada agente que sua organização adiciona.
A OWASP classifica o abuso de identidade e privilégios de agentes como o terceiro maior risco para aplicativos com agentes, citando propriedade pouco clara, credenciais herdadas e tokens armazenados em cache. São exatamente essas lacunas que se abrem à medida que um registro interno se expande.
Os padrões de segurança MCP e OAuth continuam evoluindo
Os padrões para autorização de agentes ainda estão sendo definidos. Nos últimos 12 meses, observamos mudanças significativas nas orientações:
| Data | Atualização de especificações/regulamentações |
|---|---|
| Junho de 2025 | A especificação de autorização do Model Context Protocol adotou o OAuth 2.1 e proibiu a transmissão do token do cliente para downstream APIs. |
| Setembro de 2025 | O Grupo de Trabalho OAuth da IETF adotou o Identity Assertion Authorization Grant (Concessão de Autorização de Afirmação de Identidade), que serve como base para delegar o acesso de um provedor de identidade Enterprise a apps de terceiros. |
| Julho de 2026 | A especificação MCP passou a exigir a validação do emissor do servidor de autorização e migrou a inscrição do cliente para documentos de metadados de ID do cliente. |
Além disso, as diretrizes da NSA sobre segurança do MCP observam que o protocolo não especifica a atualização e a revogação de token, portanto, cada equipe que cria sua própria camada precisa design e defender esses comportamentos por conta própria.
Cada alteração nas especificações significa que alguém lê a nova especificação, atualiza o código e realiza novos testes.
Por que os brokers de tokens caseiros falham na autorização de SaaS Enterprise
Um broker desenvolvido internamente pode armazenar e renovar tokens de atualização já emitidos por apps SaaS, mas não pode conceder acesso por conta própria. Cada app SaaS decide em quais provedores de identidade confia para atestar a identidade de seus usuários, e os fornecedores de apps constroem essa confiança em uma lista restrita de provedores de identidade estabelecidos. Se uma corretora que uma empresa utiliza internamente não estiver nessa lista, cada novo app significa mais uma rodada de telas de consentimento por usuário ou concessões manuais de administradores.
O Cross App Access funciona de forma diferente. Seu provedor de identidade concede ao agente acesso com escopo definido diretamente, de modo que a TI configura a política uma única vez, os usuários ignoram a tela de consentimento e o controle de acesso é centralizado. Um número crescente de SaaS apps oferece suporte a isso, e o Model Context Protocol adotou o mesmo padrão como autorização gerenciada por Enterprise.
Construir versus comprar: redirecionando a velocidade da engenharia para as necessidades essenciais do negócio
O valor de um agente reside no que ele faz pelo negócio: o fluxo de trabalho que automatiza, os dados que reúne e as decisões que agiliza. Cada hora que seus engenheiros gastam mantendo a lógica de atualização de tokens, reconstruindo fluxos de consentimento para o próximo app SaaS ou produzindo relatórios de revisão de acesso para auditores é uma hora que eles não dedicam aos próprios agentes.
A maioria dos engenheiros de plataforma prefere desenvolver funcionalidades de agentes a executar um serviço de identidade.
Conserve o que você construiu, compre o que está por baixo
As camadas de acesso que as equipes desenvolveram para seus primeiros agentes resolveram um problema urgente. A camada de identidade subjacente é um compromisso diferente. É preciso abranger todos os agentes da Enterprise, incluindo aqueles que sua equipe nunca criou, alcançar apps que sua Organização não controla, acompanhar os padrões que ainda estão mudando e produzir evidências de auditoria a cada ciclo, enquanto os agentes estiverem em execução.
Investir em uma camada de segurança mantém seus engenheiros focados nos agentes que impulsionam o negócio, oferece às equipes de segurança e TI um local centralizado para visualizar e controlar os agentes e transfere o trabalho contínuo de gerenciamento de padrões, integrações e governança para uma equipe cuja única função é a identidade.
Okta® for AI Agents é uma camada de identidade de agente que funciona em conjunto com o provedor de identidade e os gateways que você já utiliza. Responde a quatro perguntas vitais sobre toda a sua frota de agentes:
- Onde estão os meus agentes? Descoberta e registro
- O que eles podem fazer? Gerenciamento de escopo e direitos
- O que eles estão fazendo? Registro unificado de auditoria
- Como devo responder? Revogação automatizada e isolamento de ameaças
Guia do comprador: análise técnica e estrutura de avaliação de segurança
Para uma análise completa, incluindo as perguntas a fazer a qualquer fornecedor de identidade na sua avaliação de segurança, leia o whitepaper Identidade do agente de IA: criar vs. comprar.
Este material tem caráter meramente informativo e não constitui aconselhamento jurídico, comercial, de privacidade, de segurança ou de conformidade.
O conteúdo pode não refletir os desenvolvimentos mais recentes nas áreas de segurança, legislação e/ou privacidade. É de sua inteira responsabilidade obter aconselhamento de seu próprio consultor jurídico e/ou profissional e você não deve se basear nestes materiais para decisões de conformidade, implementação ou compra.
A Okta não oferece nenhuma garantia ou declaração em relação a este conteúdo e não se responsabiliza por quaisquer perdas ou danos resultantes da implementação destas recomendações. Informações sobre as garantias contratuais da Okta aos seus clientes podem ser encontradas em okta.com/agreements.
