A Amazon Web Services está adicionando políticas temporais ao Amazon Bedrock AgentCore, dando aos desenvolvedores uma forma de autorizar a ação atual de um agente de IA com base no que ele fez anteriormente na mesma sessão. O controle foi projetado para fluxos de trabalho em que uma chamada isolada a uma ferramenta pode parecer segura, mas se torna arriscada por causa da sequência que a antecedeu.

A mudança aborda uma lacuna no controle de acesso convencional. As permissões tradicionais de aplicações muitas vezes avaliam solicitações de forma independente, enquanto os agentes de IA escolhem ferramentas, argumentos e ordem de execução em tempo de execução. A AWS diz que sua nova abordagem pode impor etapas obrigatórias do fluxo de trabalho, preservar a integridade dos dados entre chamadas de ferramentas, limitar a exposição financeira acumulada e exigir aprovação humana antes de ações sensíveis.

O que a AWS está mudando

A AWS descreve as políticas temporais como uma extensão com estado dos controles de política existentes no Bedrock AgentCore. Em vez de perguntar apenas se um principal pode chamar uma ferramenta específica, o mecanismo de política pode inspecionar a trajetória recente do agente e decidir se a solicitação atual está autorizada naquele contexto.

Por exemplo, um agente pode usar uma ferramenta de consulta de cliente, receber um número de conta e então passar um número diferente para uma ferramenta de transferência de fundos. Ambas as chamadas poderiam satisfazer permissões sem estado. Uma política temporal poderia exigir que o argumento da transferência correspondesse à saída anterior da ferramenta, bloqueando a solicitação se o agente alterou ou fabricou o valor.

Outros exemplos no AWS Machine Learning Blog incluem exigir uma consulta de carteira antes de uma negociação, garantir que uma consulta de dados ocorreu recentemente o suficiente para embasar uma decisão e interromper uma sessão quando a exposição acumulada de negociação atinge um limite definido. A AWS também descreve controles para evitar ações contraditórias, como um agente aprovar e negar a mesma reclamação de seguro em rápida sucessão.

O recurso faz parte do Amazon Bedrock AgentCore, o conjunto de serviços da AWS para construir e operar agentes de IA. Seu ponto de aplicação é o AgentCore Gateway, que roteia o tráfego suportado de modelo, ferramenta e agente-para-agente por meio de um endpoint central.

Como a autorização temporal funciona

Uma solicitação avaliada por uma política temporal carrega o cabeçalho x-amzn-bedrock-agentcore-policy-session-id. Esse identificador conecta a solicitação a uma trajetória contendo ações, entradas e saídas anteriores relevantes. As equipes de aplicação decidem se uma sessão representa uma conversa, uma tarefa em várias etapas ou um fluxo de trabalho de duração mais longa.

A AWS recomenda manter as sessões relativamente restritas porque apenas uma solicitação de autorização pode estar ativa por sessão de cada vez. O serviço combina o identificador da sessão com a identidade do usuário final, de modo que dois usuários apresentando o mesmo identificador ainda sejam avaliados contra trajetórias separadas. A AWS diz que a janela de retrospectiva é limitada a 24 horas, após as quais eventos mais antigos são excluídos automaticamente.

As políticas temporais são executadas no gateway, e não dentro do próprio código do agente. Essa arquitetura é importante: um agente não pode reescrever a lógica da política nem manipular diretamente o estado usado para autorização. A AWS diz que o mecanismo retorna um resultado determinístico de permitir ou negar, registra o contexto da decisão, nega por padrão e dá precedência às proibições quando regras de permissão e proibição entram em conflito.

Os controles não são uma camada de orquestração. Eles não transformam solicitações, não analisam dados e não decidem qual ferramenta um agente deve chamar. O papel é mais estreito: determinar se uma solicitação roteada pelo gateway é permitida dado o histórico observado.

Evidências e detalhes de implementação

A principal evidência da mudança é o próprio post técnico da AWS, que traz a descrição do recurso e um exemplo desenvolvido envolvendo um agente de private banking. Nesse cenário, o agente recupera informações do cliente, carrega posições de carteira, obtém preços de mercado, realiza análises e executa negociações em nome de consultores financeiros.

A AWS diz que o exemplo usa Amazon Cognito para identidade, JSON Web Tokens para autenticação de entrada e ferramentas MCP expostas via AgentCore Gateway. A linguagem de política usada no exemplo é Dogwood, que a AWS descreve como uma linguagem de governança de código aberto para agentes e suas ferramentas. Segundo a AWS, Dogwood pode avaliar políticas Cedar existentes ao mesmo tempo em que adiciona suporte a condições temporais, permitindo que os clientes mantenham suas regras Cedar atuais em vez de migrar.

A fonte não fornece resultados de testes independentes, números de adoção por clientes ou evidências de que os controles impedem todas as classes de falha dos agentes. Alegações sobre resistência a bypass e comportamento operacional são reivindicações de produto e arquitetura da AWS. O item de mídia disponível repete o título do anúncio, mas não acrescenta detalhes reportados de forma independente.

Também há restrições operacionais para equipes que avaliam o recurso. A ausência de um cabeçalho de sessão pode fazer com que o AgentCore gere uma nova sessão, o que significa que o mecanismo de política vê uma trajetória vazia em vez do histórico pretendido. A AWS diz que mudanças de política invalidam sessões existentes para que decisões subsequentes usem o conjunto de políticas atual e o esquema de eventos esperado. Esses comportamentos tornam o gerenciamento de sessões e a implantação de políticas parte do design de segurança, não apenas detalhes de configuração.

Por que isso importa para construtores e empresas

Para construtores de IA, as políticas temporais fornecem um ponto de controle para um problema difícil de resolver de forma confiável com prompts ou verificações no lado da aplicação: manter invariantes ao longo de uma sequência de ações escolhidas pelo modelo. Uma política pode exigir que uma chamada de ferramenta use uma saída previamente verificada, que uma ação de alto impacto siga um procedimento definido ou que um evento de aprovação humana anteceda a execução.

Para as empresas, o principal valor é a consistência na fronteira onde o tráfego de agentes chega a ferramentas e modelos. Um gateway compartilhado pode aplicar regras a chamadas MCP, chamadas de inferência de modelo e interações agente-para-agente quando essas solicitações passam pelo AgentCore Gateway. Isso pode reduzir a necessidade de cada implementação individual de agente reproduzir controles de fluxo de trabalho, embora as equipes ainda precisem projetar políticas, modelo de identidade, limites de sessão e processo de aprovação.

A abordagem também pode ajudar com riscos financeiros ou operacionais limitados. Uma regra sem estado pode limitar o tamanho de uma negociação, por exemplo, mas não pode por si só determinar quanto de exposição foi acumulado ao longo de uma sessão. O estado temporal torna esse tipo de restrição cumulativa expressável. A contrapartida é a dependência adicional de captura precisa de eventos e de trajetórias cuidadosamente delimitadas. Uma nova sessão também pode eliminar o histórico que uma política esperava inspecionar.

Isso posiciona o AgentCore mais diretamente contra plataformas de agentes que enfatizam governança em tempo de execução, permissões de ferramentas e controles com humano no circuito. As evidências disponíveis não são suficientes para comparar a implementação da AWS com produtos concorrentes em latência, expressividade de políticas ou custo de implantação.

O que observar em seguida

Os próximos sinais serão práticos, não promocionais. Os construtores devem procurar documentação mais ampla sobre Dogwood e sua semântica temporal, exemplos além do fluxo bancário e detalhes sobre latência de avaliação de políticas e registro em escala de produção.

Compradores corporativos também devem examinar como as equipes podem testar regras dependentes da trajetória, recuperar-se de sessões falhadas ou abandonadas e gerenciar mudanças de política sem interromper fluxos de trabalho legítimos. Relatos independentes de clientes ajudariam a estabelecer se a aplicação no nível do gateway reduz incidentes ou esforço de implementação em comparação com controles incorporados ao código do agente.

A abrangência do tráfego suportado também será importante. A AWS diz que políticas temporais podem governar chamadas de modelo, de ferramenta MCP e de agente-para-agente roteadas pelo gateway; a adoção dependerá de quanto da arquitetura de agentes de uma organização pode usar esse caminho sem criar gargalo.

Perspectiva Creati.ai

A AWS está respondendo a uma fraqueza real na segurança de agentes: decisões de autorização muitas vezes precisam de memória. O risco mais consequente nem sempre é uma chamada proibida a uma ferramenta, mas uma chamada permitida após uma consulta não confiável, recuperação de dados desatualizados, falta de aprovação ou atividade anterior excessiva.

Políticas temporais não tornam os agentes confiáveis por si só. Elas criam uma fronteira de aplicação mais forte ao redor do comportamento do agente, desde que os desenvolvedores definam identidades de sessão confiáveis, capturem os eventos certos e testem políticas contra sequências de falha. Para equipes que levam agentes para finanças, atendimento ao cliente ou outros fluxos de trabalho de alto impacto, essa distinção — aplicação de política em vez de conformidade do modelo — pode ser o desenvolvimento mais significativo.