Depois do login: autorização por operação, revogação e recuperação em ferramentas de agentes

Introdução

Um agente pode continuar conversando depois que um usuário perde uma permissão. A pergunta operacional é direta: a próxima chamada de ferramenta ainda pode alterar o recurso? Este artigo propõe um exercício de arquitetura. Ele não relata um deploy nem um teste AWS já executado. Os cenários AWS abaixo estão explicitamente colocados como propostas de teste, não como resultados já medidos.

O ponto de partida é o trabalho de Carlos Biagolini sobre AgentCore Identity (Primeiros passos com Amazon Bedrock AgentCore Identity) e sobre um servidor MCP serverless com autenticação IAM (Construindo um servidor MCP serverless na AWS com autenticação IAM). Esses dois artigos usam mecanismos de identidade diferentes de propósito: o primeiro valida um JWT do Cognito no AgentCore Runtime, enquanto o segundo se apoia em IAM e SigV4 no API Gateway. Esta continuação credita ambos e trata as escolhas abaixo como decisões de projeto que ainda precisam de testes.

Três decisões que você não deve misturar

Autenticação, autorização e aprovação são perguntas diferentes, e um único artefato raramente responde às três:

1. Autenticar identifica o chamador.

1. Autorizar decide se esse chamador pode executar uma operação específica sobre determinado recurso e tenant.

1. Aprovar uma alteração registra consentimento para uma proposta concreta.

Um token válido, uma ferramenta visível ou uma aprovação antiga não substituem as outras decisões. Essa separação é a espinha dorsal de todo o exercício.

A rota é uma fronteira, não toda a política

Em uma HTTP API do Amazon API Gateway, há mecanismos como IAM, JWT authorizers e Lambda authorizers. Este exercício compara duas alternativas:

• Autorização AWS_IAM: exige SigV4 e permissão de invocação para a rota.

• Lambda authorizer: aplica a lógica de autorização da aplicação. O formato 1.0 exige uma policy IAM; o formato 2.0 também permite resposta simples booleana, quando habilitada. O escopo da decisão e a chave de cache exigem desenho explícito.

Esse controle de entrada é real e necessário, mas, em qualquer um dos dois modos, opera no nível da rota, do método e do caminho.

O limite aparece quando várias ferramentas MCP compartilham uma mesma rota, como POST /mcp: o nome da ferramenta e seus argumentos estão no corpo. A permissão de invocação da rota não substitui a decisão sobre essa operação. Neste desenho, a autorização fina fica no executor; outra camada confiável pode aplicá-la desde que conheça a operação, não possa ser contornada e seja obrigatória antes do efeito. Separar operações por rota ajuda o controle de entrada, mas não elimina a validação de recurso e tenant.

De qualquer modo, o executor deve validar a operação e o escopo usando uma identidade confiável. Não aceite o tenant informado pelo modelo como prova de autorização. No fluxo JWT, use claims validados e seu vínculo com o recurso; no fluxo IAM/SigV4, use o principal autenticado e um mapeamento de autorização controlado pelo serviço. Propague esse contexto de forma confiável até o ponto de execução.

A role que permite a uma função Lambda acessar o DynamoDB representa permissões do serviço. Ela não demonstra automaticamente que cada usuário tem direito a cada item que essa função consegue ler. Acesso no nível do serviço e direito no nível do usuário são camadas distintas.

Fluxo de requisição proposto

O diagrama a seguir mostra o pipeline de autorização proposto neste exercício, do chamador autenticado até a evidência durável do resultado.

A revogação tem uma janela observável

A documentação do IAM informa que as permissões de credenciais temporárias são avaliadas a cada solicitação AWS, mas atualizações de política podem levar alguns minutos para surtir efeito. Portanto, checado a cada chamada não significa revogação instantânea.

Se a alternativa usa um Lambda authorizer, um resultado em cache pode ser reutilizado durante o TTL. A chave do cache, a separação por rota e o prazo de vida precisam entrar no desenho e no plano de testes. Um deny para trabalho futuro também não desfaz um efeito que já foi concluído. Operações sensíveis exigem uma política para o trabalho em andamento e uma nova validação junto ao ponto de execução.

Proposta aprovada e efeito aplicado são fatos distintos

Uma aprovação deveria vincular a identidade do revisor, o digest da proposta, o escopo, a validade e o estado esperado do recurso. Se o worker reiniciar, a existência de um registro pending não comprova que a alteração ocorreu. Procure evidência durável no alvo antes de repetir. Sem prova suficiente, mantenha o estado incerto e encaminhe para revisão.

O laboratório público (v0.4.0), disponível no repositório lab-security-remediation, permite estudar essa última fronteira com SQLite e um alvo sintético. Ele não implementa IAM, revogação ou aprovação autenticada. A gravação atômica de alvo e recibo local também não prova execução única quando uma API remota participa. Manter essa separação clara é essencial, para que o material não ensine uma garantia que o código não oferece.

Matriz de testes proposta

Para cada cenário, registre a entrada sintética, o resultado esperado, o resultado observado e o limite conhecido. Não registre tokens, segredos ou dados de clientes. Os testes de autorização AWS abaixo são propostos, não resultados já obtidos.

1. Um principal válido tenta outro tenant: negar antes de consultar dados protegidos.

1. O mesmo endpoint MCP recebe uma ferramenta fora do escopo: negar no executor.

1. Uma permissão é retirada durante a sessão: medir quando as novas chamadas deixam de ser autorizadas.

1. O authorizer possui uma resposta em cache: testar a repetição antes e depois do TTL, com rotas e tenants diferentes.

1. Uma proposta é modificada depois da aprovação: rejeitar o digest divergente.

1. O recurso muda antes da execução: rejeitar a precondição obsoleta.

1. O processo para após o efeito e antes do reconhecimento: reconciliar por evidência; não reaplicar às cegas.

Trade-offs e próximo passo

Revalidar junto ao ponto de efeito aumenta as consultas e a latência; o cache reduz o custo, mas pode ampliar a janela de autorização desatualizada. A decisão deve partir do impacto da operação, da política de revogação e de medições do ambiente. Leituras de baixo risco e remediações destrutivas podem justificar níveis de rigor diferentes.

Antes de adicionar outro agente, eu pediria que a equipe demonstrasse qual identidade decide, qual componente faz cumprir a decisão e como ela recupera uma operação interrompida. O próximo incremento do laboratório deve testar aprovação autenticada e revogação em ambiente isolado, com custo e limpeza definidos desde o início.

Referências

• Controlling access to an HTTP API with IAM authorization
• Disabling permissions for temporary security credentials
• Working with Lambda authorizers for HTTP APIs
• Primeiros passos com Amazon Bedrock AgentCore Identity
• Construindo um servidor MCP serverless na AWS com autenticação IAM
• Laboratório lab-security-remediation (v0.4.0)