# AWS WAF no AgentCore Gateway: Segurança de Produção para IA Agêntica A disponibilidade geral do AWS WAF para o Amazon Bedrock AgentCore Gateway marca uma inflexão importante: workloads de IA agêntica agora podem receber proteções de borda consistentes sem instrumentação por agente. Analiso o que essa integração realmente entrega, onde ela ainda deixa lacunas e como estruturar uma postura de segurança madura para sistemas agênticos em produção. - URL: https://fernando.moretes.com/blog/aws-waf-no-agentcore-gateway-seguranca-de-producao-para-ia-agentica-aws-waf-adds - Markdown: https://fernando.moretes.com/blog/aws-waf-no-agentcore-gateway-seguranca-de-producao-para-ia-agentica-aws-waf-adds/article.md?lang=pt - Published: 2026-06-30T09:03:52.409Z - Category: IA & Agentes - Tags: aws-waf, bedrock-agentcore, agentic-ai, zero-trust, api-security, financial-grade, security, llm-ops - Reading time: 12 min - Source: [AWS WAF adds support for Amazon Bedrock AgentCore Gateway](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-amazon-bedrock-agentcore/) --- Workloads de IA agêntica têm um problema de segurança estrutural que nenhuma engenharia de prompt resolve: eles expõem superfícies de ataque HTTP reais — endpoints de ferramentas, callbacks de integração, rotas de orquestração — que precisam das mesmas proteções que qualquer API de produção financeira exige. Com a disponibilidade geral do AWS WAF para o Amazon Bedrock AgentCore Gateway, anunciada em 29 de junho de 2026, a AWS finalmente fecha esse gap na camada de borda. Esta análise vai além do anúncio: examino o modelo de proteção, os limites reais, os padrões de configuração para ambientes de alta exigência e o que ainda falta para uma postura Zero Trust completa em sistemas agênticos. ## O Contexto em Números - **1** — Configuração de protection pack por Gateway. Aplicada consistentemente a todos os agentes, ferramentas e integrações downstream sem reconfiguração por recurso - **5+** — Categorias de Managed Rule Groups disponíveis. Common Rule Set, Known Bad Inputs, Bot Control, IP Reputation e SQL/XSS rules aplicáveis ao Gateway - **~$5/mo** — Custo base de WAF WebACL. Mais $1/milhão de requisições inspecionadas; Bot Control adiciona ~$10/mo + $1/milhão — planejar para volumes de agentes que podem ser ordens de magnitude - **GA** — Disponibilidade em todas as regiões onde WAF e AgentCore Gateway coexistem. Sem preview regional — disponível imediatamente onde ambos os serviços estão presentes ## O Que É o AgentCore Gateway e Por Que a Superfície de Ataque É Diferente O Amazon Bedrock AgentCore Gateway é o plano de controle de conectividade para workloads agênticos: ele expõe endpoints HTTP/MCP (Model Context Protocol) que permitem que modelos de linguagem invoquem ferramentas externas, executem código server-side e integrem com sistemas downstream de forma orquestrada. Desde fevereiro de 2026, o Gateway suporta execução de ferramentas server-side via integração com a Responses API, e em março de 2026 o AWS Step Functions adicionou integração nativa com AgentCore, tornando o Gateway um componente de orquestração de primeira classe em pipelines de produção. A superfície de ataque de um Gateway agêntico é qualitativamente diferente de uma API REST convencional. Primeiro, o volume de requisições pode ser não-humano por design: um único agente LLM pode gerar dezenas de chamadas de ferramentas por turno de conversação, e sistemas multi-agente amplificam isso exponencialmente. Segundo, os payloads carregam semântica de linguagem natural que pode ser manipulada para injeção de prompt indireta — um vetor que regras WAF tradicionais não foram projetadas para detectar, mas que regras de Known Bad Inputs e Body Size podem mitigar parcialmente. Terceiro, integrações com sistemas financeiros downstream — APIs de core banking, sistemas de pagamento, datastores de clientes — tornam cada chamada de ferramenta um vetor potencial de exfiltração de dados ou escalada de privilégio. A ausência de proteção WAF nativa até este anúncio significava que equipes de segurança precisavam interpor API Gateway ou Application Load Balancer como proxies apenas para obter cobertura WAF — adicionando latência, custo e complexidade operacional desnecessários. A integração direta elimina essa gambiarra arquitetural. ## Modelo de Proteção: AWS WAF no AgentCore Gateway Fluxo de tráfego de um cliente externo até ferramentas e agentes downstream, mostrando onde o WAF intercepta e as camadas de regras aplicadas. O protection pack é configurado uma vez no Gateway e protege todos os recursos downstream. ### 🛡️ WAF Protection Pack - AWS WAF WebACL (security) - IP-Based Access Controls (security) - Rate-Based Rules (security) - Managed Rule Groups (CRS, KBI, Bot Control) (security) ### 🚪 AgentCore Gateway - AgentCore Gateway MCP/HTTP Endpoint (edge) ### 🤖 Agentic Workloads - Agent A (Bedrock) (ai) - Agent B (Bedrock) (ai) - Server-Side Tool Execution (compute) ### 🏦 Downstream Systems - Financial API (Core Banking) (external) - Customer Data (DynamoDB/RDS) (storage) ### 📊 Observability - CloudWatch Logs WAF Full Logs (data) - Security Hub Findings (security) ### Fluxos - client -> waf: Requisição HTTP/MCP - waf -> ip_rules: Avalia regras IP - waf -> rate_rules: Avalia rate limits - waf -> managed_rules: Avalia regras gerenciadas - waf -> gateway: Allow (passa inspeção) - waf -> client: Block 403 - gateway -> agent_a: Roteia para agente - gateway -> agent_b: Roteia para agente - gateway -> tool_exec: Execução server-side - agent_a -> api_backend: Chamada de ferramenta - tool_exec -> datastore: Leitura/escrita - waf -> cw_logs: Full logs (sampled/all) - cw_logs -> security_hub: Findings via EventBridge ## O Modelo de Protection Pack: Cobertura Centralizada com Trade-offs Reais O mecanismo central desta integração é o **protection pack**: uma WebACL do AWS WAF associada ao nível do Gateway, não a recursos individuais. Isso tem implicações arquiteturais profundas que vão além da conveniência operacional. Do lado positivo, a cobertura centralizada resolve o problema de drift de configuração que afeta equipes que gerenciam múltiplos agentes e ferramentas independentemente. Em ambientes financeiros onde auditores exigem evidência de controles uniformes, um único ponto de aplicação de política simplifica drasticamente a demonstração de conformidade. A regra de Bot Control, em particular, é valiosa em contextos onde você precisa distinguir entre chamadas legítimas de agentes internos e tráfego automatizado externo abusivo — embora a calibração seja não-trivial quando o seu próprio sistema é, por definição, automatizado. Do lado negativo, a granularidade de regra por recurso não existe neste modelo. Se o Agente A precisa aceitar tráfego de um conjunto de IPs que o Agente B não deve aceitar, você não pode expressar isso dentro de um único protection pack de Gateway — precisaria de múltiplos Gateways ou lógica de roteamento adicional downstream. Para organizações com requisitos de isolamento de tenant em nível de agente, isso é uma limitação real. A configuração de rate-based rules merece atenção especial. O limite padrão de avaliação de rate no WAF é por IP de origem em uma janela de 5 minutos, com um mínimo de 100 requisições. Em sistemas multi-agente onde múltiplos agentes podem compartilhar um NAT Gateway ou VPC endpoint — e portanto o mesmo IP de saída — rate limiting baseado em IP pode inadvertidamente throttle tráfego legítimo de alta frequência. A solução correta é usar rate limiting baseado em header customizado (como um `X-Agent-ID` propagado pelo orquestrador) combinado com IP, o que requer uma regra customizada com `RateBasedStatement` e `CustomKeys`. ## Onde Esta Integração Brilha - **Cobertura uniforme sem instrumentação por agente**: Um único protection pack protege todos os agentes, ferramentas e integrações downstream — elimina o risco de um agente novo ser implantado sem proteção WAF por omissão operacional. - **Known Bad Inputs Managed Rule Group**: Particularmente relevante para endpoints que recebem payloads de linguagem natural — a regra bloqueia padrões de Log4JRCE, SSRF e path traversal que podem ser injetados indiretamente via conteúdo de usuário processado pelo LLM. - **IP Reputation Lists**: Integração com feeds de inteligência de ameaças gerenciados pela AWS — bloqueia automaticamente IPs associados a botnets e infraestrutura de C2 sem manutenção de lista manual. - **Logs completos para auditoria**: WAF full logging para CloudWatch Logs entrega registros de cada requisição avaliada com o resultado da regra, IP de origem, URI e headers selecionados — essencial para trilhas de auditoria em ambientes regulados. - **Integração com AWS Firewall Manager**: Para organizações com múltiplas contas AWS, o Firewall Manager pode impor políticas WAF centralizadas em todos os AgentCore Gateways via AWS Organizations — governança de segurança em escala. - **Step Functions + AgentCore + WAF como stack completa**: Com a integração Step Functions-AgentCore de março de 2026, é possível construir workflows agênticos com orquestração durável, proteção de borda e execução de ferramentas server-side em uma stack coesa e auditável. > **Limites Reais que Você Precisa Conhecer Antes de Ir para Produção:** **1. WAF não detecta prompt injection semântica.** As regras gerenciadas inspecionam padrões sintáticos conhecidos — elas não entendem semântica de linguagem natural. Um ataque de indirect prompt injection que instrui o LLM a exfiltrar dados via chamada de ferramenta legítima passa pelo WAF sem alarme. WAF é necessário mas não suficiente; você precisa de guardrails de Bedrock e validação de output no nível da aplicação. **2. Body size limits podem truncar payloads de agentes.** O WAF inspeciona os primeiros 8 KB do body por padrão (configurável até 64 KB com inspeção de body aumentada). Payloads de ferramentas com contexto de conversação longo podem exceder esse limite — o WAF avalia apenas a porção inspecionada, e o restante passa sem inspeção de regras de body. Monitore `aws_waf_oversized_body` nas métricas do WAF. **3. Granularidade por agente não existe.** Um único protection pack se aplica a todo o Gateway. Requisitos de isolamento de tenant ou políticas diferenciadas por agente exigem múltiplos Gateways — com o custo e a complexidade operacional correspondentes. **4. Bot Control pode ser caro em escala agêntica.** A $10/mês base mais $1/milhão de requisições parece razoável, mas um sistema multi-agente em produção pode gerar facilmente 50-100 milhões de requisições/mês — resultando em $60-110/mês apenas para Bot Control, por Gateway. Avalie se Bot Control é necessário ou se rate-based rules customizadas são suficientes para o seu threat model. **5. Latência de inspeção WAF.** Cada requisição adiciona latência de inspeção WAF — tipicamente 1-3ms para regras simples, podendo chegar a 10-15ms com Bot Control habilitado. Em workflows agênticos com dezenas de chamadas de ferramentas encadeadas, essa latência acumula. ## Modelagem de Ameaças Específica para Sistemas Agênticos em Ambientes Financeiros Antes de configurar qualquer regra WAF, o exercício mais valioso é construir um modelo de ameaças específico para o seu sistema agêntico — não reutilizar o modelo de ameaças da sua API REST. Os vetores são diferentes. **Abuso de volume não-humano** é o vetor mais imediato. Diferente de APIs humanas onde rate limiting por IP é uma heurística razoável, sistemas agênticos podem ter clientes legítimos que são eles mesmos sistemas automatizados. Um orquestrador de agentes externo legítimo pode gerar 10.000 requisições em 5 minutos — exatamente o padrão que uma regra de rate limiting genérica bloquearia. A solução é estratificar: rate limiting por IP para proteção contra abuso externo, combinado com rate limiting por header de identidade de agente para controle de quota por cliente. **Injeção indireta via conteúdo de usuário** é o vetor mais sofisticado e o menos coberto pelo WAF. Um usuário malicioso pode inserir instruções em linguagem natural em um campo de texto que o LLM processa e que resultam em chamadas de ferramentas não-intencionadas. O WAF pode bloquear tentativas grosseiras (payloads com `