O problema de controlar agentes de IA em produção
Agentes de IA são capazes de automatizar fluxos de trabalho complexos, mas sem os controles certos, eles podem tomar ações que conflitam com as políticas internas da organização ou com obrigações regulatórias. Para endereçar esse desafio, a AWS desenvolveu o recurso de Política no Amazon Bedrock AgentCore, que permite às equipes aplicar controles de forma centralizada sobre os agentes que rodam no Amazon Bedrock AgentCore.
Recentemente, a AWS expandiu esse recurso com novas capacidades que permitem impor restrições ao longo do tempo — como limites de taxa, pré-requisitos de chamadas, ordenação sequencial de ferramentas e controle de efeitos cumulativos. Essas políticas são expressas em Dogwood, uma linguagem de governança de código aberto, e aplicadas em tempo real pelo monitor Dogwood embutido no AgentCore Gateway.
O que é o Policy Authoring
Como parte desse lançamento, a AWS também expandiu as capacidades do Policy Authoring, uma ferramenta baseada em IA que converte documentos de especificação de políticas escritos em linguagem natural em especificações formais Dogwood — sintaticamente e semanticamente corretas.
Com essa funcionalidade, é possível gerar políticas que:
- Impõem restrições temporais e de trajetória de ações;
- Invocam o Amazon Bedrock Guardrails para detectar conteúdo inadequado em campos de texto livre;
- Restringem os parâmetros de entrada das ferramentas disponíveis para o agente.
O ponto central é que qualquer pessoa, independentemente do nível técnico, pode importar um documento de políticas escrito em prosa diretamente no Amazon Bedrock AgentCore para proteger os sistemas agênticos em produção.
Como o Policy Authoring funciona na prática
O Policy Authoring funciona melhor quando as regras já existem em prosa — quando o trabalho é de transcrição, não de design. Você pode fornecer um documento com um conjunto de regras: uma lista de políticas, a seção de regras de um procedimento operacional ou um parágrafo descrevendo ações permitidas ou restritas.
A ferramenta atua como um tradutor, não como um resumidor. Documentos que misturam regras com justificativas e comentários funcionam melhor quando pré-processados para isolar apenas as regras em si.
O cenário de exemplo: banco de varejo
Para ilustrar as traduções, o artigo da AWS usa o exemplo de um agente de atendimento ao cliente em um banco de varejo. Esse agente verifica identidades, abre disputas, emite reembolsos, move fundos entre contas e solicita aprovação de supervisores. Suas ferramentas são acessadas via AgentCore Gateway e incluem:
verify_identity— verificação de identidade do chamador;initiate_transfer— transferência de fundos entre contas do cliente;issue_refund— reversão de uma cobrança disputada;file_dispute— abertura de caso de disputa;request_approval— solicitação de aprovação de um supervisor.
O Policy Authoring recebe junto ao documento um esquema com os nomes das ferramentas, seus argumentos e retornos — gerado a partir do manifesto de ferramentas MCP (Model Context Protocol) do agente. Isso garante que as políticas geradas referenciem exatamente os mesmos nomes que o agente usa.
Exemplos de tradução de políticas
Restrição em argumentos de uma ferramenta
Regra em linguagem natural: Reembolsos só podem ser emitidos durante o horário comercial (9h–17h UTC) e apenas para valores de até US$ 2.500.
permit (
principal,
action == AgentCore::Action::"issue_refund",
resource
)
when {
context.system.now.toTime() >= duration("9h") &&
context.system.now.toTime() <= duration("17h")
}
when {
context.input.amount <= 2500
};Uma única frase com dois requisitos independentes se torna uma política com duas condições. Para mais detalhes sobre funções baseadas em tempo como duration, consulte o suporte a políticas baseadas em tempo.
Pré-requisito obrigatório
Regra: Não inicie uma transferência a menos que a identidade do chamador tenha sido verificada para a mesma conta nos últimos 15 minutos.
permit (
principal,
action == AgentCore::Action::"initiate_transfer",
resource
)
when temporal {
formerly within 15m
AgentCore::Action::"verify_identity"::response{
input.account: context.input.account,
output.verified: true
}
};Aqui a condição não pode ser resolvida apenas com a requisição de transferência — ela consulta o histórico da sessão. O operador formerly within 15m verifica se o evento descrito ocorreu nos últimos 15 minutos. A correlação por account garante que uma verificação de outra conta não satisfaça a regra.
Limite cumulativo
Regra: Bloqueie uma transferência se o total transferido nas últimas 12 horas ultrapassar US$ 50.000.
forbid (
principal,
action == AgentCore::Action::"initiate_transfer",
resource
)
when temporal {
exists (total: Long). (
(sum a for (a: Long), (t: Timepoint).
where (
formerly within 12h (
AgentCore::Action::"initiate_transfer"::request{
input.amount: a
} && tp(t)
)
)
) == total &&
total > 50000
)
};Aqui o histórico não é apenas consultado — ele é somado. A política soma o argumento amount de todas as transferências nas últimas 12 horas e bloqueia a chamada atual se o total ultrapassar US$ 50.000. Cada transferência individual pode ser pequena, mas a condição restringe o agregado.
Limite de taxa
Regra: O agente não pode tentar mais de três reembolsos para a mesma conta em uma hora.
forbid (
principal,
action == AgentCore::Action::"issue_refund",
resource
)
when temporal {
exists (n: Long). (
(count for (t: Timepoint).
where (
formerly within 1h (
AgentCore::Action::"issue_refund"::request{
input.account: context.input.account
} && tp(t)
)
)
) == n &&
n > 3
)
};Estrutura semelhante ao exemplo anterior, mas contando eventos em vez de somar valores. A contagem inclui a tentativa atual, portanto a quarta tentativa na mesma hora é bloqueada. Como a regra diz "tentativa", reembolsos negados ou com falha também contam.
Verificação de texto livre
Regra: Rejeite qualquer abertura de disputa cuja descrição contenha um número de Seguro Social americano.
forbid (
principal,
action == AgentCore::Action::"file_dispute",
resource
)
when {
BedrockGuardrails::SensitiveInformation(
["US_SOCIAL_SECURITY_NUMBER"],
[context.input.description]
).maxConfidenceScore().greaterThanOrEqual(decimal("0.2"))
};Algumas regras dizem respeito ao significado de texto livre, não a valores estruturados. Para esses casos, a política gerada invoca uma verificação do Amazon Bedrock Guardrails diretamente no campo indicado. Como a regra original não especifica um limiar de confiança, a tradução usa o valor padrão para essa verificação.
Regra que combina múltiplos tipos de condição
Regra: Um reembolso acima de US$ 500 exige aprovação de supervisor para aquela cobrança, registrada nos últimos 30 minutos.
forbid (
principal,
action == AgentCore::Action::"issue_refund",
resource
)
when {
context.input.amount > 500
}
unless temporal {
formerly within 30m
AgentCore::Action::"request_approval"::response{
input.charge_id: context.input.charge_id,
output.approved: true
}
};A sentença tem duas partes verificadas de formas distintas: um limite no argumento da chamada atual e uma condição sobre o histórico da sessão. A cláusula unless levanta a negação quando uma aprovação correspondente está registrada. A correlação por charge_id impede que uma aprovação para uma cobrança autorize o reembolso de outra.
Boas práticas para escrever políticas em linguagem natural
Políticas claras e sem ambiguidade geram comportamentos mais previsíveis — tanto para humanos quanto para o autoformalizador. A AWS destaca as seguintes orientações:
- Diga se você quer a tentativa ou o resultado. "Após uma transferência" é ambíguo. "Após uma transferência ser concluída com sucesso" não é. Limites de taxa e caps cumulativos geralmente se aplicam a tentativas; pré-requisitos e regras de ordenação, a resultados.
- Declare a janela de tempo. "Recentemente" não tem tradução. "Nos últimos 30 minutos" sim. Se a regra deve resetar em um limite de calendário (e não deslizar com o relógio), declare isso explicitamente.
- Nomeie o sujeito da regra. "Não mais que três transferências por hora" não diz de quem: três pelo mesmo chamador ou três contra a mesma conta? Ambas são expressáveis, mas são políticas diferentes.
- Forneça o limiar e seu limite. "Mais de três" e "pelo menos três" diferem por uma ação — geralmente a que a regra existe para impedir. O mesmo vale para níveis de confiança em verificações de conteúdo.
- Revise as políticas Dogwood geradas. Cada política é retornada junto com a frase que a originou para leitura lado a lado. A validação verifica se a política é bem formada, mas não confirma se ela expressa exatamente o que o autor pretendia. Esse julgamento fica com quem é dono do documento.
O que não pode ser aplicado por políticas
O serviço de authoring consegue identificar e sinalizar políticas incompatíveis com o mecanismo de execução. Há quatro categorias comuns de regras que não podem ser traduzidas para Dogwood:
- Não é uma regra sobre uma ação. Exemplo: "Agentes devem sempre agir no melhor interesse financeiro do cliente." Não há condição sobre nenhuma ação, campo ou principal. Essa é uma exigência legítima, mas pertence às instruções do agente, às avaliações e ao treinamento — não a um mecanismo de autorização.
- Pede uma ação, não um veredicto. Exemplo: "Quando uma descrição de disputa contiver um número de Seguro Social, remova-o antes de salvar." Um mecanismo de políticas permite ou nega uma chamada — ele não a modifica. Redação é um controle diferente, aplicado em outro ponto do pipeline.
- Usa construtos não suportados pela linguagem. Exemplo: "Negue transferências em fins de semana e feriados federais americanos." O suporte a data e hora no Dogwood cobre pontos no tempo, offsets e diferenças, mas não há acesso ao dia da semana nem a calendários de feriados. O guia da linguagem Dogwood detalha quais construtos estão disponíveis.
- Está fora do escopo de execução. Exemplo: "Um cliente pode iniciar no máximo dez transferências por dia, contadas em todas as sessões simultâneas." A execução avalia trajetórias dentro de uma sessão; um cap que agrega entre sessões não pode ser recuperado com uma formulação diferente.
Em cada um desses casos, o resultado útil não é uma política, mas um rótulo indicando que a regra não pode ser traduzida para Dogwood — o que sinaliza a necessidade de considerar alternativas: reescrever, mover para outro controle ou aceitar que permanece como processo humano.
Como funciona o pipeline de autoformação
O processo de autoformação roda em quatro etapas:
- Decomposição: O documento é quebrado em regras atômicas. Uma cláusula numerada frequentemente carrega várias obrigações independentes, e cada uma se torna uma instrução sobre uma ferramenta específica que pode ser aplicada de forma isolada.
- Roteamento: Cada regra é classificada como expressável ou não em Dogwood. As inexpressáveis são separadas antes da tradução, evitando que se tornem políticas que validam corretamente mas aplicam a coisa errada.
- Autoformação: As regras restantes são convertidas em Dogwood, ancoradas no esquema de ferramentas fornecido junto ao documento.
- Validação: Cada política candidata é validada usando as mesmas ferramentas de linha de comando Dogwood que acompanham a linguagem open source. O compilador é uma autoridade precisa e determinística sobre se uma política pode ser analisada e se todos os nomes existem no esquema. Quando uma candidata é rejeitada, seus diagnósticos são retornados e a regra é traduzida novamente com esses erros em vista, por um número limitado de rodadas.
O resultado final são duas coleções: as políticas que validaram para sintaxe e compatibilidade com o esquema do ambiente (junto com as regras atômicas que as geraram) e as regras atômicas que foram separadas por não serem expressáveis.
Conclusão
O Policy Authoring no Amazon Bedrock AgentCore representa um avanço importante para equipes que precisam aplicar governança sobre agentes de IA sem precisar dominar uma linguagem formal de especificação. A abordagem reconhece que as regras geralmente já existem em prosa — em procedimentos operacionais, documentos de conformidade ou políticas internas — e encurta o caminho entre esse documento e um conjunto de políticas revisável e implantável.
O Dogwood pode ser escrito diretamente por quem preferir trabalhar na linguagem. O Policy Authoring existe para o caso mais comum: quando as regras já estão em prosa e o trabalho é de transcrição.
Para começar, consulte a documentação de Política no AgentCore para criar um motor de políticas e gerar políticas a partir de um documento, e o guia da linguagem Dogwood para quem quiser ler ou estender as políticas geradas. Para entender como essas políticas são interpretadas e aplicadas em tempo de execução, veja também Securing AI agents with temporal policies in Amazon Bedrock AgentCore e Introducing Dogwood: runtime verification for AI agents.
Fonte
Authoring Dogwood policies from natural language in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/authoring-dogwood-policies-from-natural-language-in-amazon-bedrock-agentcore/)
