O problema com controles de acesso tradicionais em agentes de IA
Antes dos agentes de IA, era geralmente suficiente que os controles de acesso tratassem cada ação como um evento independente. As aplicações dependiam de lógica de negócio determinística para garantir que as ações acontecessem na ordem correta e que os dados estivessem atualizados.
Agentes de IA se comportam de forma fundamentalmente diferente. Eles decidem em tempo de execução quais ferramentas chamar, com quais argumentos e em qual ordem. Essa flexibilidade, combinada com modelos cada vez mais inteligentes, torna os agentes ao mesmo tempo poderosos e difíceis de controlar.
Uma chamada de ferramenta pode parecer segura quando analisada isoladamente, mas ser prejudicial no contexto da chamada anterior — por exemplo, após ler de uma fonte de dados não confiável. A questão então passa a ser: como aplicar regras de autorização que levem em conta o histórico de sessão do agente, de uma forma que o próprio agente não consiga burlar?
O que são políticas temporais no AgentCore
As políticas temporais no Amazon Bedrock AgentCore permitem definir regras com estado (stateful) que determinam a autorização para os destinos do AgentCore Gateway, avaliando a requisição atual no contexto de eventos anteriores na trajetória do agente. Como essas políticas são executadas no perímetro do AgentCore Gateway, fora do próprio código do agente, o agente não pode interceptá-las nem manipulá-las.
Por que agentes precisam de políticas com estado
Os controles de acesso existentes no AgentCore Policy aplicam regras determinísticas e sem estado (stateless) a cada requisição individual. Esses controles são necessários, mas frequentemente insuficientes para agentes. Considere os seguintes cenários onde controles stateless falham em capturar problemas críticos:
- Um agente chama uma ferramenta de consulta de cliente, alucina um número de conta diferente do retornado, e passa esse valor para uma ferramenta de transferência de fundos — movendo dinheiro para a conta errada.
- Um agente descontrolado executa dezenas de operações em loop porque nada rastreia que a exposição acumulada já ultrapassou o limite de risco.
- Um agente aprova e nega o mesmo sinistro de seguro em segundos.
Cada chamada de ferramenta individual nesses cenários passaria numa verificação de política stateless. O problema só fica aparente quando se observa a trajetória do agente — a sequência ordenada de ações em uma sessão. As políticas temporais estendem o AgentCore Policy com essa camada de aplicação consciente da trajetória, executando no gateway, fora do código do agente, de modo que não podem ser contornadas independentemente do que o agente faça, como foi instruído ou quais bugs existam no código.
Casos de uso comuns
- Integridade de saída entre ferramentas encadeadas: exige que um argumento passado para a chamada atual corresponda exatamente à saída de uma chamada anterior, impedindo que o agente alucine ou substitua valores entre etapas.
- Sequenciamento de chamadas de ferramentas: exige que uma ferramenta seja chamada antes de outra para verificar a aderência a procedimentos operacionais padrão (SOP).
- Aprovação humana antes de ações privilegiadas: bloqueia chamadas destrutivas ou sensíveis até que um evento de aprovação humana explícita seja registrado na trajetória.
- Atualidade dos dados: exige que uma consulta de dados tenha sido concluída dentro de um intervalo de tempo antes que uma ação dependente seja autorizada, evitando decisões baseadas em informações desatualizadas.
Como as políticas temporais funcionam
As políticas temporais se baseiam no mecanismo de políticas já usado para controle de acesso stateless. Elas introduzem o conceito de trajetórias de agentes — sequências delimitadas de ações identificadas por um principal e um ID de sessão. Os agentes nunca veem a lógica das políticas, nunca tocam no armazenamento de estado e não podem alterar os controles. Assim como nas demais funcionalidades do AgentCore Policy, as políticas temporais negam por padrão e a proibição tem precedência sobre a permissão.
Quando o gateway recebe uma chamada de ferramenta, o mecanismo de políticas: consulta o estado da trajetória para ações, entradas e saídas relevantes; avalia cada política temporal contra a requisição atual no contexto de seu escopo histórico; e retorna uma decisão determinística de ALLOW ou DENY, registrando o contexto completo da decisão.
Cada requisição avaliada por uma política temporal deve carregar um cabeçalho x-amzn-bedrock-agentcore-policy-session-id, que identifica a sessão à qual a requisição pertence. O limite pode refletir qualquer unidade de trabalho que faça sentido para a aplicação — uma conversa de usuário, uma tarefa com múltiplas etapas ou um fluxo de trabalho de longa duração.
Uma sessão nunca é definida apenas pelo seu ID. O AgentCore combina o ID de sessão com a identidade do usuário final para produzir uma sessão única — o que significa que duas identidades diferentes podem apresentar o mesmo ID de sessão e ainda assim serem tratadas como sessões completamente separadas. Dentro de uma sessão ativa, as trajetórias de agentes têm uma janela máxima de retrospecto de 24 horas. Qualquer evento de trajetória mais antigo que isso é automaticamente excluído.
Uma regra adicional governa a relação entre sessões e as próprias políticas: sempre que uma mudança é feita nas políticas de um mecanismo de políticas, as sessões existentes são invalidadas, garantindo que cada sessão seja avaliada contra o conjunto atual de políticas.
Aplicando políticas temporais a um agente de gestão de portfólios
Para tornar esses conceitos concretos, a AWS apresenta um exemplo hipotético de um agente de banco privado que ajuda assessores de investimento a gerenciar portfólios de clientes. O agente recupera perfis de clientes, carrega posições de portfólio, busca preços de mercado em tempo real, realiza análises e executa operações em nome do assessor.
No cenário, as seguintes ferramentas MCP (Protocolo de Contexto de Modelo) são expostas através do AgentCore Gateway: get_client_profile, load_portfolio, get_market_price, execute_trade e rebalance_portfolio. Há três perfis de assessores: juniores (autoridade limitada de negociação), seniores (autoridade total) e oficiais de compliance (acesso somente leitura).
Para autenticação, o exemplo utiliza o Amazon Cognito com tokens JWT (JSON Web Token) para autenticação de entrada no AgentCore Gateway. Consulte a documentação do AgentCore Gateway para aprender como configurar a autenticação.
As políticas temporais utilizam o Dogwood, uma nova linguagem de governança open source projetada para agentes e suas ferramentas. O Dogwood suporta a avaliação de políticas Cedar existentes e adiciona suporte a condições temporais. Por ser compatível com Cedar, os clientes podem continuar usando suas políticas atuais sem precisar migrar. Para mais detalhes sobre o Dogwood, consulte a documentação da linguagem ou este post do blog.
Fluxo de requisição pelo gateway e pela política
Quando o agente de portfólio inicia uma chamada de ferramenta, o seguinte ocorre: a requisição chega ao AgentCore Gateway; o assessor já está autenticado via AgentCore Identity; a requisição carrega o ID de trajetória da sessão atual; o mecanismo de políticas recupera o estado acumulado da trajetória; cada política temporal avalia a requisição atual contra esse histórico; se todas as políticas permitirem, a requisição segue para a ferramenta MCP; se qualquer política proibir, a requisição é negada e a negação é registrada; em caso de execução bem-sucedida, a ação e seu resultado são anexados ao estado da trajetória para avaliações futuras.
Os sete padrões de política aplicados ao exemplo
A equipe de compliance do exemplo exige os seguintes controles temporais antes que o agente entre em produção:
Política 1: Sequenciamento de fluxo de trabalho
O agente deve executar get_client_profile, depois load_portfolio, antes que qualquer operação seja executada. Sem o perfil do cliente, o agente não tem contexto verificado sobre quais portfólios pertencem a esse cliente, qual é a tolerância ao risco ou quais restrições de conta se aplicam.
permit (principal, action == AgentCore::Action::"FinTarget___load_portfolio", resource == AgentCore::Gateway::)
when temporal {
formerly within 5m (AgentCore::Action::"FinTarget___get_client_profile"::response{eventResource: resource})
};
permit (principal, action == AgentCore::Action::"FinTarget___rebalance_portfolio", resource == AgentCore::Gateway::)
when temporal {
formerly within 5m (AgentCore::Action::"FinTarget___load_portfolio"::response{eventResource: resource})
}; Política 2: Integridade de saída para entrada
O portfolio_id passado para execute_trade deve corresponder exatamente a um dos IDs retornados por get_client_profile. O agente não pode fabricar ou substituir um ID diferente. Isso impede que um atacante use injeção de prompt para direcionar o agente a operar contra o portfólio de outro cliente.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when temporal {
formerly within 24h (
AgentCore::Action::"get_client_profile"::response{
input.profile_id: context.input.profile_id,
eventResource: resource
}
)
};Política 3: Atualidade dos dados
Uma chamada a get_market_price deve ter sido concluída nos últimos 30 segundos antes que execute_trade seja autorizado. Em mercados voláteis, mesmo uma cotação de 60 segundos atrás pode representar uma variação de preço significativa.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when temporal {
formerly within 30s (
AgentCore::Action::"get_market_price"::response{eventResource: resource}
)
};Política 4: Limite de orçamento acumulado por trajetória
O valor total de operações em uma única sessão não pode ultrapassar $60.000. Um agente comprometido executando dezenas de pequenas operações que individualmente parecem normais ainda pode acumular uma exposição catastrófica.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when temporal {
exists (total: Long).
((sum amount for (amount: Long), (t: Timepoint).
where (formerly within 24h (
AgentCore::Action::"get_market_price"::request{input.cost: amount, eventResource: resource}
&& tp(t)))) == total
&& total < 60000)
};Política 5: Aprovação humana para operações de grande valor (consumo único)
Qualquer operação acima de $25.000 exige a aprovação explícita do assessor. Cada aprovação é consumida por uma única operação. Uma segunda operação de grande valor exige uma nova aprovação, impedindo que o agente interprete uma única aprovação como permissão abrangente para múltiplas operações.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when {
context.input.cost < 25000 ||
temporal {
!(AgentCore::Action::"execute_trade"::response{eventResource: resource})
since within 24h (
AgentCore::Action::"approve_trade"::response{
input.status: "approved",
eventResource: resource}
)
}
};Política 6: Exclusão mútua
O agente não pode comprar e depois vender o mesmo ativo na mesma trajetória se a venda resultar em prejuízo. A contradição em si é o sinal de que algo deu errado e a sessão deve ser revisada.
permit (
principal,
action == AgentCore::Action::"execute_sell",
resource
)
unless {
context.input.profit < 0 &&
temporal {
formerly within 24h (
AgentCore::Action::"execute_buy"{
stock_symbol: context.input.stock_symbol,
eventResource: resource}
)
}
};Política 7: Decaimento progressivo de confiança
Após 15 minutos sem interação do assessor, o agente perde acesso a operações de escrita (execute_trade, rebalance_portfolio). O assessor pode se reengajar a qualquer momento para restaurar o acesso completo. Isso garante que uma operação autônoma prolongada não acumule riscos sem controle.
permit (
principal,
action in [
AgentCore::Action::"execute_trade",
AgentCore::Action::"rebalance_portfolio"
],
resource == AgentCore::Gateway::""
)
unless temporal {
formerly within 15m AgentCore::Action::"interact_advisor"::response{eventResource: resource}
}; Considerações de custo
O modelo de cobrança é baseado nas requisições de autorização realizadas durante a execução do agente. Cada vez que um agente chama uma ferramenta pelo AgentCore Gateway, o Policy verifica a ação contra as regras definidas. As primeiras 100 políticas temporais por mecanismo de políticas estão incluídas no preço existente por requisição de autorização. Consulte a página de preços do AgentCore para mais detalhes.
Limpeza dos recursos
Para evitar cobranças contínuas, os recursos criados devem ser removidos na seguinte ordem: primeiro excluir as políticas temporais do mecanismo de políticas, depois desanexar o mecanismo de políticas do gateway e, por fim, excluir o mecanismo de políticas. Um mecanismo de políticas não pode ser excluído enquanto ainda contiver políticas ou permanecer anexado a um gateway.
Para listar e excluir as políticas, repita o comando de exclusão para cada uma das sete políticas:
aws bedrock-agentcore-control list-policies \
--policy-engine-id
aws bedrock-agentcore-control delete-policy \
--policy-engine-id \
--policy-id Para desanexar o mecanismo de políticas do gateway, atualize o gateway sem uma configuração de mecanismo de políticas:
aws bedrock-agentcore-control create-gateway \
--name my-gateway \
--role-arn arn:aws:iam::123456789012:role/my-gateway-service-role \
--protocol-type MCP \
--authorizer-type CUSTOM_JWT \
--authorizer-configuration '{
"customJWTAuthorizer": {
"discoveryUrl": "https://cognito-idp.us-west-2.amazonaws.com/some-user-pool/.well-known/openid-configuration",
"allowedClients": ["clientId"]
}
}'Para excluir o mecanismo de políticas:
aws bedrock-agentcore-control delete-policy-engine \
--policy-engine-id Opcionalmente, se o gateway e o destino foram criados apenas para este exercício:
aws bedrock-agentcore-control delete-gateway-target \
--gateway-identifier \
--target-id
aws bedrock-agentcore-control delete-gateway \
--gateway-identifier Conclusão
As políticas temporais trazem autorização stateful e consciente de trajetória para sistemas de IA agêntica. Os sete padrões demonstrados — sequenciamento de fluxo de trabalho, integridade de saída para entrada, atualidade de dados, limites de orçamento acumulado, aprovações humanas no loop, exclusão mútua e decaimento progressivo de confiança — se generalizam para qualquer domínio onde agentes interagem com ferramentas sensíveis em tempo de execução.
Como a aplicação acontece no perímetro do AgentCore Gateway, fora do próprio raciocínio do agente, essas proteções permanecem à prova de adulteração independentemente do comportamento do modelo. Isso oferece uma forma declarativa e auditável de aplicar limites operacionais sem restringir a flexibilidade que torna os agentes valiosos. Para começar, consulte a documentação do AgentCore.
Fonte
Securing AI agents with temporal policies in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore/)
Leave a Reply