Okta e AgentCore colocam agentes de IA sob controle: revogacao de acesso em 1 segundo

Um agente que atualiza um ticket ou consulta o cadastro de um cliente opera em nome de uma pessoa e dentro de aplicativos aos quais essa pessoa tem acesso. Isso levanta uma pergunta incomoda para as equipes de seguranca: exatamente qual agente tem o direito de agir por qual usuario em qual aplicativo, e como interrompe-lo? O consentimento OAuth separado em cada aplicativo e as contas de servico compartilhadas nao respondem a essa pergunta. Na primeira parte de seu passo a passo, a AWS propoe uma resposta baseada em Okta Cross App Access (XAA) e Amazon Bedrock AgentCore.

Quem e responsavel pelo que

A divisao e simples. A Okta e o plano de controle: ela decide qual agente pode agir por qual usuario e sobre qual recurso. O AgentCore Identity e o plano de execucao: armazena as credenciais do agente, converte a decisao da Okta em um token aceito pelo recurso e preserva nele as duas identidades, a do usuario e a do agente.

Tres tokens participam de cada solicitacao. O token de ID informa quem e o usuario. O ID-JAG e a propria decisao da Okta: ele e de uso unico e tem validade de 5 minutos. O token de acesso e o que o recurso de destino aceita; ele tambem dura 5 minutos, identifica tanto o usuario quanto o agente e carrega os grupos do usuario.

A cadeia funciona assim. O usuario entra no frontend (BFF) por meio do OpenID Connect. O BFF troca o token de ID do usuario por um ID-JAG na Okta conforme a RFC 8693, autenticando-se como o agente.

A Okta verifica se o agente esta ativo, se o usuario esta atribuido a ele e se um administrador conectou o agente ao servidor de autorizacao correto com os scopes necessarios. Em seguida, o BFF invoca o agente no runtime do AgentCore, usando o ID-JAG como token bearer, e o autorizador JWT do runtime aceita apenas ID-JAGs emitidos pela Okta especificamente para aquele agente. Depois, o AgentCore Identity troca o ID-JAG por um token de acesso conforme a RFC 7523, que o agente usa para acessar servidores MCP.

O gerenciador de tarefas verifica se o token foi obtido por um agente registrado e se o grupo e o scope do usuario permitem a ferramenta especifica.

Onde e facil tropecar

Os autores enumeram com franqueza as armadilhas em que eles mesmos cairam.

Primeiro, a Okta rejeita uma solicitacao de ID-JAG se ela contiver scopes do OpenID Connect como openid ou profile, retornando o erro invalid_scope. E necessario pelo menos um scope personalizado e nenhum scope padrao.

Segundo, o token de ID deve vir do mesmo aplicativo associado ao agente. Um token de outro aplicativo interrompe a troca com um erro informando que o cliente nao esta registrado para delegacao.

Terceiro, cada agente precisa de seu proprio provedor de credenciais da Okta. A tentativa de resgatar o ID-JAG de um agente em nome de outro e rejeitada porque os valores de client_id nao correspondem.

Quarto, o SDK armazena o workload access token no BedrockAgentCoreContext, e nao nos cabecalhos da solicitacao. A primeira versao dos autores procurava o token nos cabecalhos, nao o encontrava e encaminhava todas as 21 solicitacoes testadas para uma rota alternativa com uma segunda workload identity. O token precisa ser lido a partir do contexto.

Por fim, na politica do IAM, o segmento do ARN e escrito como oauth2credentialprovider, sem hifen; com hifen, todas as chamadas falhavam com AccessDeniedException. A funcao do agente precisa de apenas dois statements: GetResourceOauth2Token e permissao para ler o segredo do provedor.

Numeros e limitacoes

Depois que um administrador removeu a atribuicao do usuario ao agente, a Okta passou a rejeitar novas solicitacoes em aproximadamente 1 segundo, enquanto os tokens ja emitidos expiraram em ate 5 minutos. A primeira chamada, incluindo o resgate do ID-JAG, levou cerca de meio segundo, e o AgentCore Identity acrescentou ao todo aproximadamente 0,6 segundo a uma solicitacao de cerca de 30 segundos. Uma segunda chamada para outro servidor MCP devolveu o mesmo token do armazenamento em uma media de 58 ms, sem resgatar novamente o ID-JAG de uso unico. Um novo ID-JAG para o mesmo usuario gera um novo token, portanto cada solicitacao reflete a decisao atual da Okta.

Ressalvas: o codigo e um exemplo didatico e nao destinado a producao; os trechos demonstram o padrao, nao uma solucao pronta. Os testes foram executados no nivel gratuito Okta Integrator, em uma unica regiao da AWS (Oregon). O passo a passo leva cerca de uma hora. Para producao, sao necessarios MFA, rotacao do segredo —ou Private Key JWT em vez de um segredo compartilhado— e aprovacao das equipes de seguranca e juridica.

O que fazer

Se seus agentes acessam sistemas internos por meio de uma conta de servico compartilhada, e hora de reconsiderar a arquitetura. Registre o agente como uma entidade separada no IdP, restrinja seus scopes, mantenha os tokens com curta duracao e verifique as permissoes do usuario dentro das proprias ferramentas, nao apenas na entrada. A segunda parte promete aplicar a mesma abordagem ao AgentCore Gateway, as politicas Cedar, a um agente no EKS e a auditoria no CloudWatch.