O ponto cego da segurança da IA na sua Enterprise
A capacidade de responder a três perguntas determina se seus agentes de IA estão sob controle:
- Onde estão os meus agentes?
- O que eles podem acessar?
- O que eles podem fazer?
Para a maioria dos líderes de segurança, não há uma resposta clara para a segunda pergunta.
O motivo pelo qual é tão difícil responder a essa pergunta é que os agentes que executam tarefas essenciais para os negócios geralmente não são desenvolvidos internamente. Até agora, não havia uma maneira padrão para o Claude Code, o GitHub Copilot ou o Salesforce Agentforce solicitarem credenciais ao Okta, permanecerem dentro do escopo ou fazerem o registro do que fazem.
A solução mais comum é o uso de chaves de API de longa duração: amplo acesso, sem atribuição de usuário, sem trilha de auditoria, e basta uma credencial vazada para que ocorra uma violação. E quando algo dá errado, é muito provável que você não consiga fornecer ao auditor as informações essenciais de que ele precisa, como qual agente acessou os dados, em nome de quem o agente agiu e sob qual política operou.
O resultado: uma maior probabilidade de violação. E, quando ocorre uma violação de segurança, o usuário pode enfrentar problemas regulatórios, reprovação em auditorias e o custo operacional de revogar manualmente o acesso em todos os sistemas que o agente acessou.
Veja como isso funciona na prática. Um Developer precisa de um agente para acessar o GitHub e o Slack. Eles inserem um token de acesso pessoal e um token do Slack na configuração do agente. Agora existe um agente com acesso permanente ao controle de versão e aos canais internos.
As credenciais estão armazenadas em um arquivo desprotegido. Ninguém pode afirmar quais ações foram do agente e quais foram do humano. Se um prompt envenenado causar o comprometimento desse agente, os tokens serão comprometidos junto com ele.
As credenciais ativas não expiram nem deixam trilha de auditoria, o que as torna uma violação esperando para acontecer. Multiplique isso por cada Developer e cada assistente de programação que suas equipes utilizam.
Por que a governança de agentes de IA requer identidade em tempo de execução?
A governança de agentes exige a aplicação de identidade em tempo de execução. Sem ela, perde-se a capacidade de responder às perguntas mais importantes quando algo dá errado.
O local mais eficiente para capturar informações importantes — como qual agente acessou esses dados, em nome de quem e sob qual política — é no momento em que uma chamada de ferramenta é executada, não no momento da configuração, nem posteriormente. Isso requer uma camada de identidade no caminho da requisição.
Gateways tradicionais versus gateways nativos de identidade
| Capacidade | Gateway de API/MCP Tradicional | Gateway de Agent nativo em identidade |
|---|---|---|
| Foco primário | Roteamento de tráfego, balanceamento de carga e limitação de taxa. | Verificação de identidade e aplicação de políticas |
| Atribuição de usuário | Nenhum (rastreia IP/sistema, não usuários individuais) | Mapeia cada chamada para um agente e usuário humano específicos. |
| Gerenciamento de credenciais | Armazena ou transmite chaves de API estáticas e de longa duração. | Brokers tokens isolados e de curta duração dinamicamente |
| Revogação de acesso | É necessário realizar a rotação de chaves em todos os apps downstream. | Revogação instantânea no endpoint do gateway |
Como o Agente Gateway protege as chamadas de ferramentas com suas políticas de acesso
O Agent Gateway, um novo recurso do Okta para Agentes de IA, preenche essa lacuna. Os agentes de IA podem acessar ferramentas Enterprise com segurança por meio de um único endpoint protegido pela Okta. O agente gateway intermedia credenciais em tempo de execução, atribui chamadas de ferramentas e não requer alterações no-code no agente. O resultado: as equipes de segurança podem responder às suas perguntas de auditoria e as equipes de IA podem entregar resultados mais rapidamente.
A Okta é o provedor de identidade no caminho: ela verifica o agente, controla quais ferramentas ele pode usar, armazena as credenciais para que o agente não possa acessá-las e faz o registro das chamadas de ferramentas em uma identidade gerenciada.
O Agent Gateway fica no caminho das chamadas de ferramentas feitas pelos agentes e responde a uma pergunta crucial do plano para uma Enterprise agêntica segura: a que os agentes podem se conectar?
O Agent Gateway aplica a política em tempo de execução. Mas a aplicação de políticas em tempo de execução exige saber quem são seus agentes, a que eles devem ter acesso e quais políticas os regem. Okta for AI Agents fornece a base de identidade e governança, descobrindo, realizando a integração, protegendo e governando agentes em toda a Enterprise.
A arquitetura do Gateway de Agentes
O agente Gateway proporciona três resultados essenciais:
- Aplicação de políticas: O senhor controla o acesso do agente às ferramentas Enterprise em um único local e pode revogá-lo instantaneamente.
- Segurança: Os agentes armazenam apenas tokens de curta duração, impedindo que adversários extraiam credenciais downstream.
- Visibilidade: Todas as ações são auditáveis com atribuição completa em todos os sistemas.
Não é necessário possuir o código do agente. O Agente gateway oferece proteção neutra em relação a fornecedores em todas as plataformas e nuvens, incluindo Claude Code, Cursor, GitHub Copilot, Salesforce Agentforce e qualquer agente que suas equipes possam direcionar para um endpoint MCP.
Integrando o gateway de agente à sua infraestrutura existente.
O agente Gateway não substitui seu MCP ou API gateway existente. Em vez disso, adiciona uma camada de identidade e política sobre sua infraestrutura atual.
Seu gateway atual continua a lidar com roteamento, limitação de taxa e conectividade. O Agent Gateway gerencia a aplicação da aplicação das regras de identidade.
Suas equipes direcionam seus clientes agentes para o endpoint do Agent Gateway. Não são necessárias alterações de código nos agente, nem modificações nos sistemas downstream. O agente faz uma chamada e recebe uma resposta. O que muda é que todas as chamadas de ferramentas agora passam pela política do Okta.
Padrões de credenciais suportados
O Agente gateway atualmente suporta dois padrões de credenciais:
- Cross-App Access (XAA): O novo protocolo que permite acesso seguro do agente ao app para recursos habilitados para Okta.
- Consentimento intermediado: o Secure serviço de token (STS) da Okta intermedia dinamicamente o consentimento OAuth para sistemas externos como GitHub e Slack.
A experiência do agente é idêntica em ambos os casos.
Atenda aos requisitos de segurança locais com o MCP Bridge.
Organizações com requisitos regulatórios rigorosos — como conformidade com o FedRAMP, redes privadas ou restrições de residência de dados — podem implementar o MCP Bridge.
Disponível através do Okta Professional Services, o MCP Bridge oferece recursos semelhantes de aplicação de identidade e isolamento de credenciais dentro da sua própria infraestrutura.
Como começar a usar o Agent Gateway hoje mesmo
Se sua equipe de segurança revisasse as chamadas da ferramenta de agente de IA da semana passada, ela conseguiria determinar qual agente atuou, em nome de quem, quais dados foram acessados e se alguma credencial foi exposta?
Um gateway MCP tradicional pode encaminhar chamadas de ferramentas, mas não consegue fornecer o contexto de identidade necessário para responder a essas perguntas.
Um gateway nativo de identidade pode. Mostra qual agente acessou quais dados, para quem e sob qual política, no momento em que cada chamada é executada.
Seja um dos primeiros a testar o agente gateway. Estamos oferecendo esta nova funcionalidade do Okta for AI Agents como uma versão experimental. Para manifestar seu interesse, solicite sua inscrição em nosso Programa de Parceiros de Pesquisa.
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.
