Okta e AWS mostram um agente agindo por um usuário nomeado e cronometram a revogação

A maior parte do que se escreve sobre identidade de agentes termina quando o token é emitido. Um novo desenho de referência da AWS e da Okta vai além: os autores tentaram tirar o acesso e cronometraram o que aconteceu.

O desenho: dois planos, três tokens

O post combina Okta Cross App Access (XAA) com Amazon Bedrock AgentCore Identity. A Okta atua como o plano de governança: decide qual agente pode agir por qual usuário e contra qual aplicação. O AgentCore Identity é o plano de execução: guarda credenciais e emite tokens de curta duração.

Uma requisição passa por três tokens. O usuário faz login e recebe um ID token. A Okta troca esse token por um ID-JAG, uma concessão de uso único válida por cinco minutos e emitida para um agente específico. O AgentCore troca essa concessão por um token de acesso ao recurso que nomeia o usuário e o agente e carrega os grupos do usuário. O serviço que recebe a requisição consegue, portanto, saber quem pediu, qual agente agiu e o que o usuário tem permissão para fazer.

Os autores testaram as bordas: uma concessão emitida para outro agente foi rejeitada, assim como uma concessão perto do vencimento, uma concessão reutilizada e um pedido de escopos fora da conexão configurada. Comparado com a troca de tokens OAuth comum, o XAA adiciona uma claim de ator, aplica escopos aprovados por um administrador e nega usuários que nunca foram atribuídos ao agente. As etapas de identidade acrescentaram cerca de 0,6 segundo a uma requisição que levava cerca de 30 segundos de ponta a ponta.

Como a revogação acontece de verdade

Depois, eles removeram o acesso e mediram.

Quanto tempo depois da revogação um agente ainda consegue agir?

ImediatamenteMais de uma hora

1. Cerca de 1 segundoA Okta recusa novas requisições de um usuário cuja atribuição foi removida
2. Até 5 minutosTokens já emitidos continuam funcionando até expirarem
3. 86 minutosUma desativação de agente enfileirada na API beta de agentes de IA da Okta

Cada número ensina algo diferente. Remover um usuário funciona rápido para novas requisições. Tokens em voo continuam valendo até o fim da vida útil, então o tempo de vida do token é o piso real para interromper uma ação delegada. A Okta não verifica o usuário de novo quando a concessão é trocada. E desativar o próprio agente, em uma API beta, levou 86 minutos para fazer efeito no teste dos autores.

Os autores fazem questão de dizer que esses resultados refletem a configuração deles e que o código de exemplo não é para produção. A ressalva é justa. O valor não está nos números exatos, mas no hábito de medi-los.

Coloque os números no seu plano de incidentes

Já defendemos que parar um agente só é a parte fácil de um incidente se o plano existir antes do go-live. Este post entrega os insumos de que esse plano precisa:

• Conheça os seus três relógios. Tempo para bloquear novas requisições, tempo máximo de vida dos tokens emitidos e tempo para desativar a própria identidade do agente. Meça cada um no seu próprio tenant.
• Defina o tempo de vida dos tokens pela janela de dano que você aceita. Cinco minutos é razoável para leitura de dados. Para agentes que podem mover dinheiro ou alterar registros, tempos de vida mais curtos ou uma verificação no recurso valem a latência.
• Tenha um interruptor mais rápido que o provedor de identidade. Se a desativação de um agente pode entrar em fila, mantenha um bloqueio no gateway ou no servidor de recursos que faça efeito imediatamente.
• Registre os dois nomes. Tokens que carregam o usuário e o agente tornam possível a revisão do incidente. Garanta que os sistemas que recebem as requisições registrem os dois, não só o usuário.

A parte 2 da série vai adicionar o AgentCore Gateway com políticas Cedar, um segundo agente no Amazon EKS e uma trilha de auditoria no CloudWatch. A parte 1 já faz o ponto principal: a identidade delegada para agentes não termina quando o token é emitido. Termina quando você sabe com que rapidez consegue tomá-la de volta.