Controle de agentes de IA além de uma única ação: novidades no Amazon Bedrock AgentCore

O problema que ninguém estava resolvendo

Agentes de Inteligência Artificial (IA) estão ficando cada vez mais autônomos, e as empresas estão rodando mais deles. O problema é que a confiança e a segurança não acompanharam esse ritmo. De acordo com a McKinsey, cerca de 80% das organizações já enfrentaram comportamentos de risco vindos de agentes de IA. Não por acaso, preocupações com segurança e risco lideram a lista de barreiras para escalar IA agêntica.

O que torna isso complicado é que a maioria dos mecanismos de controle existentes foi projetada para software previsível. Agentes decidem seu próprio caminho à medida que executam tarefas — e cada passo pode parecer legítimo individualmente, enquanto o conjunto das ações passa completamente despercebido.

Considere três exemplos concretos que ilustram bem o problema:

• Um agente consulta a conta de um cliente e transfere dinheiro para um número de conta diferente — porque cada chamada foi avaliada isoladamente e aprovada.
• Um agente realiza uma série de pedidos, cada um abaixo do limite de aprovação — porque nada estava somando o total contra o orçamento da sessão.
• Um agente encontra uma ferramenta com falha e fica tentando novamente a noite toda, consumindo todo o orçamento de tokens — porque nada limitou o quanto ele poderia consumir.

Cada requisição era legítima. O problema aparece apenas no padrão — e o próprio agente é a última coisa em que você deveria confiar para detectar isso.

Amazon Bedrock AgentCore: segurança na camada de infraestrutura

A AWS desenvolveu o Amazon Bedrock AgentCore para dar às equipes o que elas precisam para construir, conectar e otimizar agentes em escala, sem precisar montar a infraestrutura por conta própria. Um princípio guia o serviço desde o início: controles de segurança pertencem à camada de infraestrutura, aplicados de forma consistente em todos os agentes — e não no código da aplicação, onde cada equipe os implementa de maneira diferente.

O gateway do AgentCore é onde essa ideia se concretiza. Trata-se de um ponto de entrada totalmente gerenciado e serverless para o tráfego de IA, roteando requisições para servidores Protocolo de Contexto de Modelo (MCP), Modelos de Linguagem de Grande Escala (LLMs), agentes e bases de conhecimento. Como toda chamada passa por ele, o gateway é o lugar natural para aplicar limites que valem independentemente de como um agente se comporta.

A AWS anunciou agora dois avanços importantes nesse trabalho: políticas temporais, alimentadas pelo Dogwood — uma nova linguagem de políticas open source criada especificamente para agentes de IA — e rate limiting no gateway.

Políticas temporais: controle sobre sequências de ações

As políticas do AgentCore já ofereciam controle determinístico sobre o comportamento dos agentes, verificando cada ação antes de ser executada para avaliar quem pode chamar qual ferramenta e sob quais condições. Essas verificações são stateless por design — cada requisição é julgada por seus próprios méritos, de forma rápida e verificável.

Mas à medida que os agentes assumem tarefas mais longas com menos supervisão, surge uma nova pergunta: as ações tomadas em conjunto somam algo que deveria ser permitido? Essa visão só é possível quando se observa a sequência de ações, não apenas as individuais.

As políticas temporais estendem as políticas do AgentCore para preencher essa lacuna. Em vez de julgar uma requisição de forma isolada, o motor de políticas também analisa o que o agente já fez naquela sessão e então permite ou nega a chamada com base nessa sequência de ações.

Na prática, isso significa que:

• Uma transferência para o número de conta errado pode ser bloqueada por uma política que exige que o valor passado em uma chamada corresponda ao que uma chamada anterior retornou.
• Uma política pode somar o que um agente gastou em uma sessão e bloquear a próxima compra assim que o orçamento for atingido — mesmo que essa compra esteja abaixo do limite individual.
• É possível exigir que as etapas aconteçam em uma ordem definida, ou que uma ação significativa precise de aprovação humana registrada.
• Permissões podem ser reduzidas automaticamente quando uma pessoa não está mais engajada na sessão.

Um ponto crucial: as políticas temporais são aplicadas na camada do gateway, fora do código do próprio agente. O agente não vê a lógica da política e não consegue raciocinar ao redor dela, independentemente de como é instruído ou de quais defeitos carrega. Para líderes de segurança que precisam aprovar sistemas autônomos, essa é a distinção que importa. É a diferença entre confiar que um agente vai se comportar e saber que o limite vale ao longo de todas as suas ações. As decisões são determinísticas, negam por padrão e são registradas com todo o contexto por trás delas.

Dogwood: a linguagem de políticas por trás das políticas temporais

Alimentando as políticas temporais está o Dogwood, uma nova linguagem de políticas criada especificamente para agentes de IA. Construído sobre a fundação do Cedar, o Dogwood foi projetado para lidar com uma nova dimensão de controle de agentes: avaliar se uma sequência de ações de um agente está em conformidade com uma política à medida que ela se desenrola.

O Dogwood incorpora o Cedar e adiciona construções temporais para governança de agentes, incluindo rate limits, janelas de tempo, etapas de pré-requisito e gatilhos de escalação. Ele está disponível como especificação open source e implementação de referência sob a licença Apache 2.0. Isso dá visibilidade total a como as políticas são avaliadas e permite que o ecossistema mais amplo construa ferramentas de suporte.

Rate limiting: controle sobre o que os agentes consomem

O custo de IA é uma questão de governança por si só, e com agentes ele começa por quão rapidamente eles consomem tokens e chamadas. Um agente executa quantas etapas julgar necessárias — então o custo de uma tarefa depende de como ele escolhe trabalhar, e não de uma taxa predeterminada. Sem limites, um loop de retry ou uma sessão incomumente pesada consome no ritmo que o agente decidir. Essa imprevisibilidade é uma restrição real para aprovação.

Uma pesquisa da Forrester identificou que o custo é o principal motivo pelo qual a IA agêntica raramente chega à escala. As equipes precisam de um teto que valha independentemente de como um agente se comporta.

Disponível agora, é possível definir esses tetos diretamente no gateway do AgentCore. O rate limiting permite que equipes limitem o consumo por usuário em todas as ferramentas, modelos e agentes por trás do gateway, usando as identidades que já gerenciam via OAuth ou Gerenciamento de Identidade e Acesso (IAM). Os limites podem cobrir:

• Requisições: quantas chamadas alguém faz, por segundo ou por minuto.
• Tokens: quantos tokens um modelo processa para eles.
• Conexões: por quanto tempo mantêm conexões abertas.

Ter as três métricas importa porque agentes geram custos de formas diferentes. Um loop de retry aparece como volume de requisições; uma tarefa com raciocínio intenso aparece como tokens; uma longa sessão de pesquisa aparece como uma conexão mantida aberta enquanto muito pouco tráfego se move. Qualquer medida única deixa uma brecha para esgotar um serviço sem acionar um limite.

Os limites se aplicam em janelas de por segundo e por minuto, o que contém o modo de falha que as equipes realmente enfrentam: um agente consumindo em uma taxa que ninguém pretendia, descoberto depois do fato. Os rate limits entram em vigor assim que configurados, sem alterações no código do agente. A alocação de capacidade passa a ser algo que as equipes de plataforma configuram, não constroem. Diferentes usuários, equipes, ferramentas e modelos podem ter tetos distintos, sem nenhuma lógica de throttling escrita em nenhum deles.

Para onde isso está indo

Os modelos continuam melhorando, e esse progresso é o que torna os agentes dignos de serem implantados. Mas também eleva o que está em jogo — um agente mais capaz toma ações mais consequentes com menos supervisão. O que uma empresa ganha com modelos melhores depende de conseguir rodar esses agentes com a mesma disciplina que aplica a tudo mais em produção.

Confiar em um agente não é realmente um julgamento sobre o modelo. É um julgamento sobre o sistema dentro do qual o modelo opera — e se esse sistema aguenta quando um agente se comporta de forma inesperada. Construir esse sistema é uma disciplina jovem, e a AWS indica que as perguntas dos clientes hoje são visivelmente mais sofisticadas do que as de um ano atrás.

Cada controle que sai do código da aplicação e vai para a plataforma é uma coisa a menos que precisa ser reconstruída, revisada e aprovada separadamente para cada agente. Quanto mais confiavelmente uma plataforma consegue delimitar o que os agentes fazem e quanto consomem, mais autonomia se pode conceder sem hesitação.

Nenhuma das duas capacidades exige rearquitetar agentes já em produção, e cada uma pode ser adotada de forma independente. Para saber mais, consulte a documentação do AgentCore e as páginas de preços, e explore a implementação de referência do Dogwood.

Fonte

Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore/)