Quando eu penso em segurança para agentes de IA, eu não penso só em bloquear chamadas isoladas. Eu penso na trajetória. Um agente não age como uma aplicação comum. Ele escolhe ferramentas, muda a ordem dos passos e monta argumentos em tempo real. Isso abre espaço para erro, abuso e contradição.
Políticas temporais são regras que avaliam o histórico da sessão do agente antes de permitir uma nova ação.
No Amazon Bedrock AgentCore, isso faz diferença porque controles sem estado não bastam. Um pedido de transferência pode parecer válido sozinho e ainda assim enviar fundos para a conta errada. Um trade repetido pode estourar o limite de risco sem que cada operação, vista separadamente, pareça grave. E um agente pode até contradizer uma aprovação anterior se ninguém olhar a sequência completa.
Eu tenho visto esse ponto ganhar força em operações sensíveis. Uma pesquisa sobre agentes autônomos e governança mostrou que 95% das organizações já operam agentes de IA de forma autônoma, mas só 6% têm estratégias avançadas de segurança. Em paralelo, um estudo sobre falhas na gestão do risco digital apontou que muitas empresas nem conseguem detectar agentes comprometidos. Eu não vejo isso como detalhe. Vejo como alerta.
Nesse cenário, o trabalho da Interserv Cloud conversa bem com o tema. Em ambientes que não podem parar, proteger a nuvem significa também controlar como agentes usam ferramentas em produção.
Por que políticas sem estado falham?
Uma política sem estado olha apenas para a requisição atual. Isso serve para validar formato, autenticação e escopo. Mas não responde perguntas como estas:
Esse portfólio foi mesmo retornado por uma chamada anterior?
O agente consultou cotação recente antes de negociar?
Já houve aprovação humana para este trade específico?
O valor acumulado da sessão passou do teto?
Quando o risco depende da sequência de ações, a segurança também precisa depender da sequência.
No AgentCore, essas regras ficam fora do código do agente e operam no AgentCore Gateway. Isso me agrada porque o agente não consegue burlar a política. Cada chamada chega ao Gateway com um session ID, e o motor de políticas consulta o histórico daquela sessão para aprovar ou negar a ação. Se a regra for violada, o pedido é negado na hora.
Segurança boa é a que o agente não contorna.
O escopo da sessão precisa ser bem definido. Para um agente bancário privado, eu costumo pensar na sessão como o atendimento de um cliente, do início ao fim daquela conversa operacional.
Pré-requisitos e fluxo de avaliação
Antes de aplicar as regras, eu preparo quatro pontos:
Conta AWS ativa com Bedrock AgentCore habilitado.
Gateway configurado para receber as chamadas das ferramentas.
Motor de políticas associado ao Gateway.
Permissões IAM adequadas para leitura, escrita e administração.
O fluxo é simples de entender. O agente pede uma ação. O Gateway recebe. O motor consulta o histórico da sessão. As sete políticas são avaliadas. Se todas passarem, a ferramenta é chamada. Se uma falhar, a execução para ali.
Quem quiser amadurecer a base antes pode acompanhar conteúdos sobre agentes de IA, segurança e ainda ligar o tema à resiliência com estratégias para garantir resiliência na nuvem AWS. Eu também gosto de cruzar isso com a visão publicada em artigos sobre agentes de IA e em boas práticas de resiliência em AWS.
As 7 políticas temporais na prática
Vou usar o caso de um agente bancário privado. A ideia é simples: dar autonomia, mas com trilho.
As primeiras 100 políticas ficam incluídas na cobrança por requisição, o que ajuda a testar o modelo sem multiplicar custos logo no início.
Um exemplo curto de estrutura pode ser assim:
<policy name="fresh_quote">when action == "trade.create"allow only if exists session.quote and now - session.quote.ts <= 30s</policy>
-
Sequência correta de chamadas. O agente deve consultar perfil do cliente, depois portfólio, depois propor rebalanceamento. Se tentar rebalancear sem contexto, o Gateway nega.
Permitido: perfil → portfólio → rebalanceamento
Negado: rebalanceamento direto
Negado: portfólio antes do perfil
-
Integridade entre saída e entrada. O ID de portfólio enviado ao rebalanceamento deve ser o mesmo retornado na consulta anterior da sessão.
Permitido: portfolio_id P123 retornado e depois reutilizado
Negado: agente envia P999 sem histórico
Negado: troca de cliente no meio da sessão
-
Cotação com no máximo 30 segundos. Antes de negociar, o agente precisa buscar preço recente.
Permitido: cotação às 10:00:05 e trade às 10:00:20
Negado: cotação às 10:00:05 e trade às 10:00:50
Negado: trade sem consulta de mercado
-
Limite acumulado de US$ 60.000 por sessão. O total de trades da sessão não pode passar desse valor.
Permitido: 20.000 + 15.000 + 25.000
Negado: novo trade de 5.000 após totalizar 60.000
Negado: tentativa de fracionar ordens para fugir da soma
-
Aprovação humana acima de US$ 25.000. Cada aprovação vale para um único trade.
Permitido: trade de 30.000 com aprovação vinculada à ordem
Negado: reaproveitar a mesma aprovação em outra ordem
Permitido: trade de 24.000 sem aprovação adicional
-
Proibição de comprar e vender o mesmo ativo com prejuízo na mesma sessão. Eu gosto dessa regra porque ela freia comportamento errático.
Permitido: compra de XYZ e manutenção
Negado: compra de XYZ a 100 e venda a 95 na mesma sessão
Permitido: venda com lucro ou fora do escopo da mesma sessão, conforme política
-
Perda de escrita após 15 minutos sem interação humana. Depois desse tempo, o agente fica só com leitura.
Permitido: consultas de saldo e portfólio
Negado: criação de trade após inatividade humana
Permitido: retorno da escrita após nova interação humana válida
Em termos de implementação, eu costumo modelar o estado por sessão com campos simples, como último portfólio retornado, horário da última cotação, soma financeira dos trades, lista de aprovações consumidas e timestamp da última ação humana.
Custos e limpeza do ambiente
Eu sempre gosto de fechar testes com higiene operacional. Mesmo com as primeiras 100 políticas incluídas na cobrança por requisição, deixar recurso sobrando gera custo contínuo e confusão.
Depois do teste, eu removo nesta ordem:
Deletar as políticas criadas no motor.
Desassociar o motor de políticas do Gateway.
Apagar gateways, logs e recursos auxiliares do laboratório.
Para empresas com operação crítica, como as atendidas pela Interserv Cloud, esse cuidado faz parte do trabalho. Segurança não é só bloquear risco. É manter clareza, custo sob controle e trilha de auditoria limpa.
Conclusão
Eu vejo essas sete políticas como padrões muito úteis para qualquer agente que opere ferramentas em tempo real em áreas sensíveis. Elas impõem ordem, preservam contexto, exigem aprovação quando faz sentido e cortam ações perigosas sem engessar o agente.
O ganho real está em manter controles auditáveis e seguros no perímetro do Gateway, fora do agente.
Esse desenho protege melhor porque a regra não depende da boa vontade do próprio agente. Ela vive no AgentCore Gateway, lê o histórico da sessão e barra o que fugir do combinado. Em bancos, telecom, e-commerce e outros cenários de alta exposição, isso reduz risco sem apagar a flexibilidade que torna agentes úteis. Se você quer aplicar esse tipo de proteção na sua operação em AWS, vale conhecer melhor a Interserv Cloud e conversar com um arquiteto especializado sobre o seu caso.
Perguntas frequentes
O que são políticas temporais no Bedrock AgentCore?
São regras que decidem se uma ação do agente pode acontecer com base no histórico da sessão. Em vez de olhar apenas a requisição atual, elas verificam a sequência de chamadas, dados já retornados, aprovações anteriores, limites acumulados e tempo entre eventos.
Como implementar políticas temporais em agentes de IA?
Eu implemento essas políticas no AgentCore Gateway, associando um motor de políticas que lê o session ID e consulta o estado daquela sessão. As regras ficam fora do código do agente, o que reduz a chance de desvio. Também configuro IAM, defino o escopo da sessão e testo cenários permitidos e negados.
Quais são as 7 políticas temporais abordadas?
São estas: sequência correta de chamadas, integridade do ID de portfólio, cotação de mercado com até 30 segundos, limite acumulado de US$ 60.000 por sessão, aprovação humana para trades acima de US$ 25.000 com uso único, bloqueio de compra e venda com prejuízo do mesmo ativo na mesma sessão, e remoção de permissão de escrita após 15 minutos sem interação humana.
Para que servem essas políticas em IA segura?
Elas servem para reduzir erros e abusos que só aparecem quando se olha a trajetória do agente. Isso inclui transferências para conta errada, operações acima do risco aceito, reaproveitamento indevido de aprovação e ações feitas com contexto velho ou inconsistente.
Essas políticas são recomendadas para todos os agentes?
Nem sempre no mesmo nível. Eu recomendo com mais força para agentes que acessam dados sensíveis, movimentam valores, alteram sistemas ou operam em tempo real. Em agentes só de leitura, o conjunto pode ser menor. Ainda assim, o padrão de avaliar histórico por sessão costuma valer para quase todo caso sério.
