O problema central: LLMs não são atores confiáveis
Agentes de IA têm uma característica fundamental que os diferencia de sistemas tradicionais: eles se adaptam. Encontram múltiplos caminhos para resolver um problema, tomam decisões em tempo real e operam com autonomia. Essa flexibilidade é justamente o que os torna úteis — mas também é o que cria um desafio sério de segurança.
O Modelo de Linguagem Grande (LLM) no coração de um agente é não determinístico. Suas decisões não podem ser previstas ou garantidas antecipadamente. Ele pode alucinar ações prejudiciais com total confiança. É vulnerável a ataques de injeção de prompt, nos quais adversários inserem comandos maliciosos por meio de respostas de ferramentas ou entradas do usuário. Para um LLM, comandos e dados são a mesma coisa — apenas tokens.
Por isso, do ponto de vista de segurança, a abordagem correta é tratar o LLM como um ator não confiável. Isso não é pessimismo; é defesa em profundidade.
A boa notícia é que o LLM não age diretamente sobre o mundo externo. Ele precisa passar por um orquestrador que invoca ferramentas com base em sua saída. É exatamente nesse ponto de passagem que os controles precisam ser aplicados. O que se precisa nessa fronteira é de autorização: uma decisão sobre se cada invocação de ferramenta deve ser permitida e sob quais condições.
Por que as abordagens comuns não são suficientes
Dois caminhos costumam ser adotados para lidar com esse problema, mas ambos têm limitações importantes:
- Fluxos de trabalho hard-coded: eliminam a incerteza, mas também eliminam o propósito de usar um LLM como cérebro do agente. Você acaba construindo uma aplicação tradicional com uma interface de LLM. Além disso, mesmo com essa restrição, usar saídas de LLM em qualquer etapa reabre os mesmos riscos.
- Humano no loop (human-in-the-loop): oferece uma rede de segurança para operações críticas e sempre terá seu papel. Mas depender disso como mecanismo principal de controle sacrifica a autonomia e pode gerar fadiga de aprovação.
O que se precisa é de uma camada de aplicação auditável e determinística que fique fora do agente e das ferramentas. Por quê fora? Porque o plano do LLM é exatamente a coisa que não se pode confiar — ele não pode ser responsável por aplicar suas próprias restrições. Controles na camada do LLM, como prompts de sistema e alinhamento em tempo de treinamento, podem ser contornados por injeção de prompt ou alucinação. Verificações hard-coded no código do agente ou das ferramentas são mais robustas, mas tornam-se difíceis de auditar e gerenciar em escala, especialmente quando a lógica de segurança está espalhada por muitas ferramentas e serviços.
Centralizar a autorização fora de ambos fornece um único ponto de verificação que o LLM não pode contornar — auditável e verificável independentemente do código da aplicação.
Onde entram as Políticas do AgentCore
O Amazon Bedrock AgentCore Gateway fica entre o agente e as ferramentas remotas que ele acessa. Quando uma Política do AgentCore é associada a um Gateway, tudo é bloqueado por padrão. As políticas abrem seletivamente essa fronteira, especificando quais invocações de ferramentas são permitidas e sob quais condições. Essa aplicação vale para todo o tráfego de ferramentas roteado pelo Gateway.
O Amazon Bedrock AgentCore oferece a infraestrutura para implantar e gerenciar agentes em escala. Ele inclui o AgentCore Runtime para hospedar agentes, o AgentCore Gateway para gerenciar como os agentes se conectam a ferramentas usando o Protocolo de Contexto de Modelo (MCP), e a Policy no AgentCore. A Policy intercepta todo o tráfego do agente pelos gateways e avalia cada requisição contra as políticas definidas antes de permitir o acesso à ferramenta.
Para que essa abordagem escale, as políticas precisam ser mais simples de entender do que o comportamento do agente. E é aí que entra o Cedar.
O que é o Cedar e por que foi escolhido
Cedar é uma linguagem de políticas de autorização de código aberto desenvolvida pela AWS que recentemente ingressou na Cloud Native Computing Foundation (CNCF). Ele foi projetado com propriedades específicas: é construído exclusivamente para autorização, legível por humanos e analisável por máquinas usando raciocínio automatizado.
Linguagem natural é ambígua demais para infraestrutura crítica de segurança. Linguagens de programação de uso geral, como Python, são muito expressivas, mas difíceis de analisar — podem ter efeitos colaterais não intencionais, problemas de terminação e são difíceis de entender. O Cedar evita esses problemas excluindo loops e operações com estado, então a avaliação de políticas termina em tempo O(n) nos casos comuns. Esse tempo de execução limitado significa que os agentes podem tomar decisões de autorização sem prejudicar a experiência do usuário.
Como o Cedar é usado pelo AgentCore
A AgentCore Policy usa o Cedar e suas capacidades de análise matemática em vários pontos do fluxo de trabalho do AgentCore Gateway: o motor de autorização Cedar é usado na avaliação de políticas, e o Cedar Analysis é usado durante a criação de políticas e no plano de controle.
Criação de políticas com IA neuro-simbólica
Desenvolvedores podem escrever políticas Cedar diretamente ou usar linguagem natural que é traduzida para Cedar por meio de um loop de feedback de IA neuro-simbólica. Essa abordagem combina a flexibilidade do aprendizado de máquina com a exatidão provável do raciocínio automatizado: um LLM gera políticas a partir da linguagem natural, enquanto o Cedar Analysis as valida usando raciocínio simbólico e matemático.
O fluxo funciona assim: um administrador especifica — em linguagem natural — quais ferramentas MCP o agente pode chamar e sob quais condições. O loop neuro-simbólico formaliza essa descrição em políticas Cedar. Primeiro, o LLM traduz a linguagem natural em políticas Cedar. Em seguida, essas políticas passam por dois estágios de verificação.
No primeiro estágio, a AgentCore Policy usa um gerador de schema que recebe as descrições das ferramentas MCP e produz um schema Cedar. O Cedar valida as políticas contra esse schema, ajudando a garantir que elas referenciem ferramentas e parâmetros válidos e eliminando classes inteiras de erros em tempo de execução. Se a validação passar, o segundo estágio executa o Cedar Analysis, que codifica cada política como uma fórmula matemática e detecta problemas como políticas que concedem ou negam tudo, ou que contêm condições impossíveis.
Plano de controle
Ao associar políticas a um AgentCore Gateway, o Cedar Analysis realiza uma análise holística de todo o conjunto de políticas. Em vez de analisar políticas isoladamente, ele examina como elas interagem e qual é o efeito combinado. Essa análise identifica possíveis erros lógicos — como políticas conflitantes ou redundantes — e detecta se o conjunto de políticas produz resultados de autorização não intencionais.
Aplicação na invocação de ferramentas MCP
Cada requisição de ferramenta feita ao gateway do AgentCore é avaliada contra as políticas Cedar, que determinam se a invocação da ferramenta MCP com os argumentos fornecidos deve ser permitida. Isso cria o envelope de segurança enquanto permite as pontes necessárias para que o agente realize seu trabalho.
Filtragem de ferramentas MCP
O Cedar habilita uma camada adicional de proteção que opera antes de qualquer invocação de ferramenta. Quando um agente emite um comando de listagem de ferramentas, o AgentCore Gateway usa a capacidade de avaliação parcial do Cedar para determinar quais ações sempre seriam negadas sob o conjunto de políticas atual. Essas ações são omitidas da resposta de listagem de ferramentas. O agente e o LLM subjacente nunca veem essas ações de ferramentas, eliminando uma classe inteira de risco: o agente não pode tentar invocar uma ferramenta que não sabe que existe.
Legibilidade: políticas que auditores entendem
Conformidade regulatória e auditorias de segurança exigem políticas que humanos possam entender e verificar. As políticas Cedar se leem como linguagem natural estruturada, tornando-as acessíveis a equipes de segurança, responsáveis por conformidade e partes interessadas do negócio. Veja um exemplo do artigo original:
// Only allow bulk discounts for premium customers with sufficient quantity
permit (
principal is AgentCore::OAuthUser,
action == AgentCore::Action::"ApplyBulkDiscount",
resource
) when {
principal.hasTag("customer_tier") &&
principal.getTag("customer_tier") == "Platinum" &&
context.input.orderQuantity >= 50
} unless {
context.input
.productTypes
.containsAny (
["limited_edition", "seasonal_specials"]
)
};Auditores sem formação técnica conseguem entender essa política: “Permitir descontos em volume para clientes Platinum que pedem pelo menos 50 itens, exceto para produtos de edição limitada ou especiais de temporada.” A cláusula unless torna a exceção clara, que é como as regras de negócio são tipicamente expressas em linguagem natural.
Vale notar que essa única política restringe duas fontes de dados diferentes. O nível do cliente vem de uma declaração de Token Web JSON (JWT) — não pode ser alucinado ou manipulado pelo LLM. As entradas da ferramenta, como quantidade do pedido e tipos de produto, porém, originam-se da chamada de ferramenta do LLM. As políticas Cedar restringem essas entradas apenas a valores permitidos, garantindo que mesmo se o LLM produzir argumentos inesperados, a camada de aplicação de políticas os rejeite deterministicamente.
Análise formal para verificação de políticas
As políticas Cedar podem ser codificadas como fórmulas matemáticas e analisadas usando técnicas de raciocínio automatizado por meio de um codificador simbólico. A análise de políticas, incluindo comparação de políticas, está disponível como uma ferramenta CLI de código aberto.
Detectando erros lógicos
O Cedar Analysis pode detectar quando políticas contêm erros lógicos. Por exemplo, o artigo original mostra uma política com restrições contraditórias — o nível do cliente não pode ser simultaneamente “Gold” e “Platinum”. A intenção era usar || em vez de &&, um erro que tanto humanos quanto sistemas de IA podem cometer ao criar políticas. O Cedar Analysis também detecta políticas que sempre permitem uma determinada ação, geralmente uma indicação de política excessivamente permissiva.
// This policy cannot allow any requests due to logical errors
permit (
principal is AgentCore::OAuthUser,
action == AgentCore::Action::"ProcessRefund",
resource
) when {
principal.hasTag("customer_tier") &&
principal.getTag("customer_tier") == "Gold" &&
principal.getTag("customer_tier") == "Platinum"
} unless {
context.input.refundAmount > 1000
};Detectando conflitos entre políticas
O Cedar Analysis também analisa o conjunto completo de políticas para detectar inconsistências entre políticas individuais diferentes. O artigo original apresenta um exemplo onde uma política permit permite que clientes Gold processem reembolsos abaixo de $100, enquanto uma política forbid bloqueia clientes Gold (e Platinum) de processar reembolsos abaixo de $500. Como forbid tem precedência sobre permit no Cedar, a política forbid bloquearia todos os reembolsos de clientes Gold apesar da política permit.
Comparando mudanças de políticas
Ao atualizar políticas, o Cedar Analysis pode determinar o impacto exato de uma mudança. O artigo original mostra um exemplo onde uma modificação na cláusula unless — aparentemente mais restritiva à primeira vista — na verdade torna a política mais permissiva. O Cedar Analysis detecta isso automaticamente e gera uma tabela mostrando a diferença em permissividade entre o conjunto original e o atualizado:
Principal type Action Resource type Status
OAuthUser ProcessRefund Gateway Equivalent
OAuthUser ApplyBulkDiscount Gateway More permissiveEssa capacidade de verificação formal é essencial quando agentes operam autonomamente e podem afetar o mundo real. Organizações precisam de certeza matemática de que suas políticas se comportarão conforme o esperado.
Comportamento determinístico para governança confiável
Ao contrário dos modelos probabilísticos de IA, a segurança empresarial exige garantias determinísticas. As políticas Cedar sempre produzem a mesma decisão de autorização para requisições idênticas, independentemente da ordem de avaliação ou do estado do sistema. A semântica padrão do Cedar — negar por padrão, forbid vence, sem ordenação — ajuda a garantir comportamento previsível.
De políticas para produção
O Raciocínio automatizado já provou seu valor em toda a AWS, desde o AWS IAM Access Analyzer verificando políticas de acesso até segurança comprovável para configurações de rede. Aplicar essas mesmas técnicas à IA agêntica é uma extensão natural: à medida que os agentes assumem mais responsabilidades, a necessidade de garantias matematicamente fundamentadas só cresce.
A abordagem neuro-simbólica descrita — combinando a flexibilidade do LLM com o rigor do raciocínio automatizado — aponta para um futuro onde agentes podem ser ao mesmo tempo mais autônomos e mais confiáveis, porque a verificação acompanha a autonomia.
A Policy já está disponível como parte do Amazon Bedrock AgentCore Gateway. Para saber mais sobre o Cedar e suas capacidades, visite o site do Cedar, experimente o Cedar playground ou participe da comunidade Cedar no Slack da CNCF. Para mais informações sobre a Policy no Amazon Bedrock AgentCore Gateway, consulte a documentação da AWS ou explore o console do AgentCore Gateway.
Fonte
Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows (https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/)
Leave a Reply