O que é o Agent Gateway?
O Agent Gateway é uma camada de aplicação de identidade em tempo de execução dentro do Okta para agentes de IA. Ele valida cada solicitação do agente para a ferramenta em relação às políticas de identidade usando a troca de tokens RFC 8693. Ao contrário dos gateways tradicionais que dependem de chaves de serviço compartilhadas, o Agent Gateway exige credenciais que nomeiem tanto o agente de IA em execução quanto o usuário humano, evitando ataques de “representante confuso” e herança não autorizada de permissões.
Se um agente de IA em seu ambiente saísse do controle neste momento, você saberia dizer em nome de quem ele estava agindo, o que ele acessou e quando? Muitas equipes de segurança não conseguem.
Os agentes de IA estão sendo lançados mais rapidamente do que os controles criados para governá-los. Os gateways podem conectar agentes a ferramentas. No entanto, poucos conseguem dizer em nome de quem um agente está agindo. Essa é uma brecha que os atacantes podem explorar, e ela só aparecerá quando algo já tiver dado errado.
Os gateways são vendidos como um meio de controle, mas a maioria não consegue verificar quem está realmente por trás de uma solicitação. Sem isso, eles não controlam nada — apenas encaminham chamadas e registram o que aconteceu, usando a autoridade que lhes foi concedida. Sem a identidade como fundamento, um gateway é um ponto de controle sem regras a serem aplicadas, sem agente a ser atribuído e sem governança a ser exercida.
O agente Gateway da Okta elimina essa lacuna. Trata-se da camada de aplicação de regras em tempo de execução dentro Okta for AI Agents. Sempre que um agente de IA puder ser configurado para chamar um Protocolo de Contexto de Modelo (MCP) externo, o Agent Gateway valida cada chamada do agente para a ferramenta em relação à política, isola as credenciais no momento da ação e produz uma trilha de auditoria unificada.
O Okta for AI Agents adiciona a base de identidade e governança em torno do Agent Gateway: descoberta de agentes, inscrição como identidades de primeira classe, fluxos de trabalho de acesso, campanhas de certificação e correlação de auditoria entre sistemas. O Agente Gateway já está disponível hoje para o público geral como parte do Okta for AI Agents. Isso responde à terceira pergunta do plano para a empresa agêntica segura: "O que meus agentes estão fazendo?"
Neste blog, você aprenderá sobre um dos principais problemas da maioria dos gateways de agentes: eles conseguem conectar um agente a uma ferramenta, mas não conseguem verificar em nome de quem o agente está agindo. E você verá como o Agent Gateway da Okta é diferente: ele não processará uma chamada a menos que a credencial nomeie tanto o usuário quanto o agente por trás dela, ajudando a garantir que a autoridade não seja emprestada, compartilhada ou herdada acidentalmente.
Por que os gateways de MCP tradicionais não conseguem proteger os agentes de IA?
Os gateways MCP tradicionais podem encaminhar solicitações de agentes para ferramentas, mas geralmente carecem de uma proteção crítica: não conseguem verificar em nome de quem um agente está agindo.
A vulnerabilidade de confused deputy explicada
Vamos começar com um cenário de exemplo em que seus agentes não possuem um gateway:
- Provisionamento abrangente de credenciais: sua equipe cria um assistente de RH para responder a perguntas sobre registros de funcionários. Para que funcione para qualquer pessoa que o solicite, alguém lhe atribui uma conta de serviço com acesso de leitura a todas elas.
- Solicitação de usuário não autorizada: Katie é um prestador de serviços. Ela pergunta ao agente sobre a remuneração do CEO.
- Desvio de política: o agente concede o acesso a ela, usando uma autorização que possui legitimamente.
- Falha na auditoria: a solicitação parece completamente limpa no registro de auditoria.
Nada foi hackeado. A única coisa que separava Katie desses dados era o próprio julgamento do agente.
Esse é o problema do representante confuso: a solicitação carrega a consulta do usuário, mas não sua autoridade. O agente age com base no que consegue acessar, e não no que a pessoa que faz a consulta realmente tem permissão para saber. É uma falha antiga no funcionamento das permissões, e é exatamente isso que acontece quando você concede amplo acesso a um agente e confia que ele se autogovernará.
Limitações das arquiteturas MCP tradicionais
Revogação tudo ou nada
Revogar uma credencial de gateway compartilhada interrompe o acesso para todos os agentes conectados, levando os administradores a deixar credenciais excessivamente permissivas permanentemente ativas:
- O administrador configura um gateway conectado a um servidor MCP do GitHub usando uma credencial compartilhada
- Todos os agentes que se conectam por meio desse gateway herdam o mesmo acesso amplo
- Revogar a credencial interrompe o acesso de todos os agentes que operam por trás dela
- O resultado: Ninguém revoga
Tokens de portador de identidade única
O MCP foi projetado tendo em mente o problema do deputado confuso. Mas existe uma limitação fundamental: o MCP funciona com tokens de portador OAuth 2.1, que identificam apenas uma identidade. Um gateway não pode simplesmente repassar o token do agente — ele precisa gerar um novo. Portanto, mesmo que um gateway queira dizer ao GitHub "este é o agente de codificação de Katie, agindo em nome de Katie", ele não pode. Qualquer identidade que escolher será a única que o GitHub verá.
As medidas de segurança de engenharia de prompt falham
Você pode tentar corrigir isso no prompt, instruindo o agente a nunca acessar os dados de compensação. Provavelmente não. Mas a credencial ainda abre tudo, então a proteção mais eficaz é o agente optar por não verificar — que era o problema original.
Agent Gateway da Okta: uma aplicação nativa de identidade em tempo de execução para agentes de IA que se conectam a ferramentas Enterprise
O Agent Gateway, um novo recurso do Okta para agentes de IA, é o ponto de controle em tempo de execução que define a que um agente pode se conectar e o que ele pode fazer durante cada ação. A chamada não será processada a menos que o chamador apresente uma credencial que identifique ambas as partes: o usuário que solicita a ação e o agente que faz a solicitação. Essa exigência de impor a identidade é o que o diferencia de um gateway que apenas retransmite o tráfego.
Configuração de um Agent Gateway.
Um gateway típico pode autenticar se algo tem permissão para se conectar. O Agent Gateway verifica para qual usuário a solicitação se destina, qual agente de IA está atuando e se esse agente foi autorizado a agir em nome desse usuário— e então aplica a política no momento em que a chamada da ferramenta é feita.
Cada chamada de ferramenta é atribuída a uma identidade de agente gerenciado, a um usuário final, a uma ferramenta e a um resultado.
Suponha que Katie seja uma funcionária e que um agente esteja prestes a fazer uma ligação em nome dela. Alguns gateways autenticam o chamador com uma chave de plataforma e recebem o usuário como parâmetro:
POST /mcp HTTP/1.1
Authorization: Bearer <platform api key>
{ "user_id": "Katie", "tool": "read_file", ... }
Um gateway construído dessa forma pode verificar a chave, mas não pode verificar Katie. O nome dela é apenas um texto na solicitação, digitado por quem fez a chamada, então qualquer pessoa que possua essa chave pode alegar ser qualquer pessoa.
O Agente Gateway não aceita esse tipo de credencial de forma alguma. Em vez disso, o Agent Gateway implementa a delegação RFC 8693, exigindo que cada chamada de ferramenta apresente uma credencial emitida pelo seu provedor de identidade contendo duas declarações de identidade distintas:
- O sujeito (
sub): O usuário final autenticado que solicita a ação - O ator (
act): o agente de IA registrado que executa a solicitação.
Isto é o que o agente Gateway espera em cada chamada:
{
"sub": "00uKatie456",
"aud": "https://acme.gateway.okta.com/mcp/servers/eng-tools",
"act": {
"sub": "0oafxqCAJWWGELFTYASJ",
"sub_profile": "ai_agent web_app"
}
}
A chamada é para sub e act indica quem está fazendo a chamada. sub_profile indica que o chamador é um aplicativo e um agente.
Nada é herdado, portanto o agente gateway não pode criar um usuário. O usuário sub nessa credencial é o único em nome do qual o agente Gateway pode agir nesta chamada. Quando o Agent Gateway precisa de uma credencial para o servidor MCP, ele troca a credencial do agente com o Okta e recebe uma vinculada ao mesmo usuário, o que está de acordo com a semântica “em nome de” definida na RFC 8693. O Okta só pode retornar essa credencial porque o usuário deu consentimento anteriormente no servidor MCP usando uma conexão registrada pelo administrador.
Portanto, um agente não pode convencer o Agent Gateway a agir em nome de outra pessoa. Katie ainda pode perguntar. No entanto, o Agent Gateway agora age em nome dela com uma credencial vinculada a ela, garantindo que o agente só possa fazer o que Katie poderia fazer sozinha.
Matriz de capacidades de aplicação de identidade
Em geral, um gateway só pode agir com base no que já está presente na credencial que recebe. Se essa credencial contém a identidade real do usuário e do agente, ou nenhuma, é decidido no momento em que ela é criada.
| Tipo de credencial recebida por um gateway | Contexto do usuário capturado | Contexto do agente capturado | Contexto do agente capturado |
|---|---|---|---|
| Chave de serviço compartilhado | Nenhum | Nenhum | Baixo: sem possibilidade de governança ou atribuição |
| Token apenas de usuário | Apenas usuário | Nenhum; todos os agentes são iguais | Médio: não é possível distinguir a atividade do agente da atividade do usuário |
| Token delegado (RFC 8693) | Usuário verificado | Agente verificado | Alta: aplicação completa da política em tempo de execução e atribuição |
O agente Gateway da Okta funciona apenas na terceira linha. A chamada não será processada a menos que a credencial seja um token delegado e verificado que nomeie tanto o usuário quanto o agente.
Regras eficazes de acesso de agentes
Na prática, o que um agente pode realmente fazer é limitado pela interseção exata das permissões do Agent Gateway e dos direitos do usuário:
O que o agente pode fazer = O que o gateway permite ∩ O que o usuário já pode fazer
O que o gateway permite ← imposto pelo gateway
O que o usuário já pode fazer ← imposto pelo servidor MCP
O Agent Gateway sabe qual agente está fazendo a chamada e quais ferramentas estão expostas. O servidor MCP conhece seus próprios registros e sabe quais usuários podem acessá-los. Você precisa de ambos.
O próprio Agente Gateway é uma carga de trabalho registrada com sua própria entidade principal e sem permissão permanente para acessar qualquer coisa. Um administrador configura duas coisas antes que qualquer chamada seja resolvida:
- Link de delegação: Concede a um agente específico permissão para delegar a este gateway em nome do usuário. Sem um, a troca é rejeitada.
- Conexão de recurso: Concede a este gateway permissão para acessar um servidor MCP específico e define exatamente quais ferramentas desse servidor estão expostas.
Nenhuma permissão é inferida do solicitante nem concedida pela credencial do agente. O acesso é limitado à delegação e às permissões de recursos que um administrador configura.
Identity Governance também é a base para a governança de custos
Os agentes de IA não apenas criam riscos de acesso, como também podem gerar gastos na velocidade das máquinas. Um agente que acessa repetidamente uma API premium, aciona Workflows dispendiosos ou invoca ferramentas de alto consumo pode gerar custos inesperados muito antes que um humano perceba.
A governança de custos começa com a atribuição. Se vários agentes compartilharem uma credencial, fica difícil responder a perguntas básicas, como: Qual agente gerou a atividade? Para quem estava atuando? Qual ferramenta ou recurso gerou o custo?
O agente Gateway da Okta cria o contexto de identidade necessário para responder a essas perguntas. Como cada solicitação está vinculada tanto ao usuário quanto ao agente que atua em seu nome, as organizações podem correlacionar a atividade do agente com as ferramentas e os recursos que ele acessa. Isso cria uma base mais clara para monitorar o uso, investigar atividades inesperadas e aplicar governança à medida que as implantações de agentes aumentam.
Em breve: suporte ao Cross-App Access e um mecanismo de desativação por meio do agente Gateway
Suporte do Agent Gateway ao Cross App Access
Os agentes precisam acessar aplicativos SaaS comuns, como Slack ou Salesforce, e a Okta possui um protocolo de padrão aberto para isso: Cross App Access. Quando o suporte for lançado, o Cross App Access permitirá que agentes de IA acessem aplicativos com segurança em nome do usuário, mantendo ambas as identidades intactas. O administrador aprova quais apps os agentes podem usar, uma única vez, em vez de cada funcionário aprovar cada app individualmente.
Fazer isso por meio de um gateway oferece uma vantagem real: fornece um ponto de controle central para ativar ou desativar o acesso de um agente, em vez de gerenciá-lo app por app.
O Agent Gateway oferecerá suporte ao Cross-App Access em um futuro próximo. Isso permitirá que o gateway mostre “esta solicitação veio de uma concessão que você já aprovou” e, em seguida, troque essa afirmação por um novo token sem que sejam necessárias alterações por parte do app. Esse mecanismo é proposto no rascunho de afirmação de Continuação de identidade da IETF.
Interruptor de segurança baseado no agente gateway
Finalmente, como cada chamada de ferramenta passa por um único ponto de aplicação em tempo de execução, o Agente Gateway pode interromper solicitações em tempo real. Quando disponível, a funcionalidade de desativação automática (kill switch) tornará a desativação do agente imediata, inclusive dos tokens já emitidos, rejeitando qualquer solicitação que contenha um token emitido para um agente desativado. Como isso será aplicado no limite da Okta, não será necessário esperar que cada app conectado revogue o acesso de forma independente.
Como avaliar um gateway de agentes de IA: quatro perguntas essenciais a fazer
Quatro perguntas lhe dirão em que posição está qualquer gateway:
- Verificação do emissor: Que credencial o servidor MCP recebe e quem a emitiu?
- Comprovação da identidade do usuário: o gateway consegue mostrar para qual usuário a chamada se destina, ou o usuário é um parâmetro fornecido pelo chamador?
- Histórico de consentimento: De quem foi o consentimento que autorizou o acesso do agente a esse servidor MCP?
- Risco de bypass: o agente alguma vez possui uma credencial que funcione sem o gateway no caminho?
O Agente Gateway foi desenvolvido para responder a todas as quatro perguntas.
O agente gateway é apenas uma peça de um quebra-cabeça maior: o Okta for AI Agents é a plataforma mais abrangente que oferece a visibilidade, o controle e a governança necessários para proteger os agentes que sua empresa implementa.
O gateway do agente está disponível com o Okta for AI Agents sem custo adicional.
Clientes atuais: entrem em contato com seu representante de conta para começar a usar hoje mesmo.
Ainda não é cliente do Okta for AI Agents? Baixe nossa ficha informativa para saber como o Okta for AI Agents pode ajudar você a gerenciar seus agentes de IA com segurança em um único plano de controle.
Qualquer menção a produtos, recursos, funcionalidades ou certificações futuras neste blog tem caráter meramente informativo. Esses itens não representam compromissos de entrega e não devem ser considerados para fins de decisão de compra.
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 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 nem se responsabiliza por perdas ou danos resultantes da implementação destas recomendações. Informações sobre as garantias contratuais da Okta para seus clientes podem ser encontradas em okta.com/agreements.
