# Web Search no Bedrock AgentCore: Revisão Técnica Aprofundada

O Web Search no Amazon Bedrock AgentCore entrega busca web gerenciada para agentes de IA, com zero egresso de dados fora do ambiente AWS e grounding via MCP. Avalio a capacidade com olhar crítico de arquiteto sênior: trade-offs reais, limites operacionais e quando faz sentido adotar.

- URL: https://fernando.moretes.com/blog/web-search-no-bedrock-agentcore-revisao-tecnica-aprofundada-announcing-w

- Markdown: https://fernando.moretes.com/blog/web-search-no-bedrock-agentcore-revisao-tecnica-aprofundada-announcing-w/article.md?lang=pt

- Published: 2026-06-17T15:00:11.000Z

- Category: IA & Agentes

- Tags: bedrock, agentcore, agentic-ai, mcp, web-search, grounding, financial-grade, rag

- Reading time: 10 min

- Source: [Announcing Web Search on Amazon Bedrock AgentCore: Ground your AI agents in current, accurate web knowledge](https://aws.amazon.com/blogs/aws/announcing-web-search-on-amazon-bedrock-agentcore-ground-your-ai-agents-in-current-accurate-web-knowledge/)

---

Quando um agente de IA precisa raciocinar sobre eventos que ocorreram depois do seu corte de treinamento — uma mudança regulatória, uma falha de mercado, um CVE publicado ontem — a resposta convencional era integrar manualmente uma API de busca externa, gerenciar credenciais, lidar com egresso de dados e torcer para que o provedor de busca não armazenasse seus prompts. O Web Search no Amazon Bedrock AgentCore, disponível em GA desde 17 de junho de 2026, ataca exatamente esse problema: entrega busca web gerenciada, com grounding citado, construída sobre o índice próprio da Amazon e conectada ao agente via Model Context Protocol (MCP) — tudo dentro do perímetro AWS. Minha análise não é um tutorial; é uma revisão técnica honesta de onde essa capacidade muda o jogo, onde ela ainda tem arestas e qual o veredicto para quem projeta sistemas financeiros e enterprise de alta criticidade.

## Números que importam na avaliação

- **$7** — por 1.000 queries de busca. Preço de GA; sem compromisso upfront. Comparável a Bing Search API (~$3–$15/1k) mas sem egresso de dados fora da AWS.
- **1** — região disponível no lançamento (us-east-1). Disponibilidade regional única é o principal limitador operacional para workloads multi-region e de DR ativo-ativo.
- **0** — bytes de egresso de prompts para provedores externos. Queries e snippets permanecem no ambiente AWS do cliente — diferencial crítico para compliance financeiro e LGPD/GDPR.

## O que é, de verdade: MCP como camada de integração de ferramentas

O Web Search não é um endpoint REST avulso colado ao Bedrock. Ele é um **connector target** dentro do **Bedrock AgentCore Gateway**, exposto via **Model Context Protocol (MCP)**. Isso importa arquiteturalmente: o MCP define um contrato padronizado de tool-calling entre o modelo e ferramentas externas, permitindo que o agente descubra, invoque e interprete resultados de busca como parte do seu ciclo de raciocínio — sem que o desenvolvedor precise escrever parsers ou gerenciar o schema de resposta manualmente.

Na prática, o fluxo é: o agente envia uma query em linguagem natural → o Gateway roteia para o connector de Web Search → o serviço consulta o índice web da Amazon combinado com o **Amazon Knowledge Graph** (dados estruturados verificados) → retorna snippets, URLs, títulos e datas de publicação → o modelo raciocina sobre esses fragmentos para produzir uma resposta grounded com citações.

A escolha do MCP como protocolo de integração é uma aposta clara da AWS na padronização do ecossistema agentic. Isso significa que o mesmo Gateway pode agregar múltiplos targets MCP — busca web, bases de conhecimento internas, APIs corporativas — e o agente os trata de forma uniforme. Para arquitetos que já trabalham com Strands Agents ou frameworks compatíveis com MCP, a adoção é praticamente zero-friction no lado do código. O ponto de atenção é que o Gateway em si introduz um hop adicional de latência e um ponto de controle centralizado que precisa ser dimensionado e monitorado.

## Onde brilha: o caso financeiro e de compliance

Em ambientes financeiros regulados — bancos, corretoras, fintechs sob BACEN, CVM, SEC ou FCA — o maior bloqueador para adoção de busca web em agentes não era tecnológico: era de governança. Enviar prompts contendo dados de clientes ou estratégias proprietárias para APIs de busca de terceiros (Google, Bing, Brave) cria um vetor de vazamento de dados que a maioria dos times de segurança simplesmente não aceita. O Web Search no AgentCore elimina esse vetor ao manter tudo dentro do perímetro AWS do cliente.

Isso tem implicações concretas: **não há necessidade de Data Processing Agreements (DPAs) adicionais** com provedores de busca externos; o tráfego pode ser mantido dentro de uma **VPC via PrivateLink** (verificar disponibilidade por região); os logs de queries ficam no CloudWatch Logs do próprio cliente, auditáveis via CloudTrail; e as políticas IAM do AgentCore Gateway podem ser escopadas por role, permitindo que apenas agentes autorizados invoquem a ferramenta de busca.

O caso de uso que mais me convence é o de **agentes de compliance e monitoramento regulatório**: um agente que precisa verificar se uma nova circular do BACEN ou uma atualização da SEC afeta uma posição ou produto específico, consultando fontes públicas em tempo real, sem que a query revele a posição do cliente para nenhum terceiro. Combinado com o Amazon Knowledge Graph — que traz dados estruturados verificados sobre entidades, fatos e relações — o grounding vai além de snippets de texto puro, o que reduz alucinações em domínios com ontologias bem definidas como regulação financeira e taxonomias de produtos.

## Pontos fortes que diferenciam a capacidade

- **Zero egresso de dados**: queries e respostas nunca saem do ambiente AWS do cliente — diferencial de compliance inegociável para setores regulados.
- **Multi-source grounding**: combinação de índice web com Amazon Knowledge Graph entrega snippets + fatos estruturados verificados, reduzindo alucinações em domínios ontológicos.
- **MCP nativo**: integração via protocolo padronizado permite composição com outros targets (Knowledge Bases, APIs internas) no mesmo Gateway sem código adicional.
- **Citações estruturadas**: o retorno inclui URL, título e data de publicação — fundamentais para rastreabilidade e auditoria em workflows agentic de alta criticidade.
- **Herança de infraestrutura Alexa+/Amazon Quick**: o índice subjacente tem histórico de escala e qualidade em buscas agentic, não é um crawler genérico de terceiro.
- **Modelo de preço simples**: $7/1k queries, usage-based, sem tier de comprometimento — adequado para workloads com volume imprevisível em fase de experimentação.

## Fluxo de grounding: Web Search no AgentCore em ambiente financeiro

Mostra como um agente financeiro consulta o Web Search via AgentCore Gateway (MCP), combina com Knowledge Base interna e retorna resposta grounded com citações, tudo dentro do perímetro AWS do cliente.

### 🏦 Aplicação — Camada do Agente

- Bedrock Agent (Strands / custom) (ai)
- Foundation Model (Claude / Nova) (ai)

### 🟧 AWS — AgentCore Gateway (MCP)

- AgentCore Gateway MCP endpoint (network)
- Web Search Connector Target (external)
- Knowledge Base Target (interno) (data)

### 🔍 Amazon — Índice & Conhecimento

- Amazon Web Index (crawl próprio) (external)
- Amazon Knowledge Graph (fatos verificados) (data)

### 🔒 AWS — Segurança & Observabilidade

- IAM Role (escopo por agente) (security)
- CloudWatch Logs + CloudTrail (data)

### Fluxos

- user -> agent: pergunta em linguagem natural
- agent -> llm: raciocínio + seleção de tool
- llm -> gateway: tool call MCP
- gateway -> iam: authz por role
- gateway -> websearch: query de busca
- gateway -> kb: busca interna (paralela)
- websearch -> webindex: consulta índice web
- websearch -> kg: enriquece com fatos
- websearch -> gateway: snippets + URLs + datas
- gateway -> llm: contexto grounded
- llm -> user: resposta com citações
- gateway -> cwlogs: audit log de queries

## Onde dói: limites reais que o entusiasmo de lançamento esconde

Nenhuma capacidade de GA chega perfeita, e o Web Search no AgentCore não é exceção. O primeiro limite que impacta projetos enterprise imediatamente é a **disponibilidade em uma única região (us-east-1)**. Para workloads financeiros com requisitos de DR multi-region ou com restrições de residência de dados fora dos EUA (LGPD, GDPR, regulação europeia), isso não é um detalhe — é um bloqueador de adoção até que regiões adicionais sejam habilitadas. A AWS promete expansão no roadmap, mas sem SLA de data.

O segundo ponto crítico é a **ausência de controle sobre o índice consultado**. Diferente de uma Knowledge Base gerenciada onde você define o corpus, o Web Search consulta o índice público da Amazon. Isso significa que não há como excluir domínios específicos, priorizar fontes confiáveis (ex: apenas reguladores, bancos centrais, publicações peer-reviewed) ou filtrar por jurisdição geográfica do conteúdo. Para agentes que precisam de grounding em fontes curadas — um requisito comum em compliance financeiro — isso é uma limitação funcional relevante.

O terceiro ponto é **observabilidade e custo previsível**. A $7/1k queries, um agente conversacional com 10k usuários ativos fazendo 5 buscas por sessão gera $350/dia — $10.500/mês — apenas em Web Search, antes de computar o custo do modelo. Sem mecanismos nativos de **rate limiting por agente ou por usuário** no Gateway, um loop de raciocínio mal configurado pode gerar centenas de queries em segundos. É imprescindível implementar quotas via API Gateway ou lógica de retry com backoff exponencial e limite de iterações no próprio agente. CloudWatch Metrics para `WebSearchQueryCount` deve ter alarme configurado desde o dia zero.

> **Riscos operacionais que precisam de mitigação ativa:** **Disponibilidade regional única**: não use Web Search como componente crítico em arquiteturas que exigem failover multi-region até que us-east-1 não seja a única opção. Projete o agente para degradar graciosamente — responder com base apenas no Knowledge Base interno — quando o Web Search estiver indisponível ou fora da região.

**Runaway query cost**: implemente um `max_search_iterations` no loop do agente (recomendo ≤5 por turno de conversa) e configure um budget alert no AWS Cost Explorer com threshold diário. Um agente mal configurado em produção pode consumir o budget mensal em horas.

**Qualidade de grounding não garantida**: o índice web da Amazon é amplo, mas não é curado por domínio. Valide a qualidade dos snippets retornados com um conjunto de queries de referência antes de ir para produção em casos de uso de alta criticidade.

## Arquitetura de referência: composição com Knowledge Base e guardrails

O padrão arquitetural que recomendo para ambientes financeiros não usa o Web Search de forma isolada. A composição correta é: **Knowledge Base interna (documentos regulatórios, políticas, dados proprietários) + Web Search (eventos recentes, publicações públicas) + Guardrails do Bedrock (filtragem de conteúdo e PII)**, todos expostos como targets MCP no mesmo AgentCore Gateway.

O agente decide qual ferramenta invocar com base no tipo de query: para fatos históricos e políticas internas, usa a Knowledge Base; para eventos recentes ou validação de informações públicas, usa o Web Search. Essa decisão pode ser guiada por um **router de intenção** implementado como uma chain de prompt antes da chamada de tool, reduzindo queries desnecessárias ao Web Search e, consequentemente, o custo.

No plano de observabilidade, instrumentalize o Gateway com **OpenTelemetry**: trace cada invocação de tool com `agent.tool.name`, `agent.tool.latency_ms`, `agent.search.query_hash` (nunca o texto raw por PII) e `agent.search.result_count`. Correlacione com os traces do modelo via `trace_id` para ter visibilidade end-to-end do ciclo de raciocínio. No Datadog ou CloudWatch, crie um SLO de latência P95 para o ciclo completo de grounding (target: <3s para queries síncronas em interfaces conversacionais).

Para IAM, o princípio de menor privilégio se aplica com granularidade: a role do agente deve ter `bedrock:InvokeAgent` e a permissão específica para invocar o Gateway, mas **não** deve ter acesso direto às credenciais do índice ou a outros targets não autorizados. Use **resource-based policies no Gateway** para restringir quais roles podem invocar quais targets MCP.

## Posicionamento estratégico: o que a AWS está realmente construindo

O Web Search no AgentCore não é um produto isolado — é uma peça de um movimento estratégico maior. Olhando o conjunto de anúncios do AWS Summit New York 2026: Managed Knowledge Base, AgentCore Gateway, Web Search, AWS DevOps Agent, AWS Transform — a AWS está construindo uma **plataforma de orquestração agentic enterprise**, onde o MCP é o barramento de integração e o AgentCore é o plano de controle.

Isso tem implicações para decisões de build vs. buy. Hoje, muitas equipes constroem sua própria camada de tool-calling com LangChain, LlamaIndex ou frameworks proprietários, integrando manualmente APIs de busca, bases vetoriais e ferramentas de ação. O AgentCore + Web Search representa a proposta da AWS de que essa camada deve ser gerenciada, assim como a AWS gerencia filas (SQS), streams (Kinesis/MSK) e orquestração (Step Functions). A aposta é que o custo de operação e governança de ferramentas agentic customizadas supera o custo de adoção da plataforma gerenciada.

Para arquitetos de sistemas financeiros, a questão não é se o Web Search é tecnicamente superior a uma integração Bing/Google customizada — em muitos aspectos, ainda não é, especialmente em controle de corpus e cobertura regional. A questão é se a **redução de risco de compliance + redução de overhead operacional** justifica o preço e as limitações atuais. Para a maioria dos casos de uso que avaliei — monitoramento regulatório, enriquecimento de relatórios, assistentes de research — a resposta é sim, com as mitigações adequadas.

## Como adotar com responsabilidade em ambiente financeiro

1. **1. Validar residência de dados e disponibilidade regional** — Confirme com o time jurídico e de compliance se us-east-1 atende aos requisitos de residência de dados. Se não, implemente o agente com fallback para Knowledge Base interna até que regiões adicionais estejam disponíveis. Documente essa decisão como um ADR com data de revisão.

2. **2. Configurar IAM com escopo mínimo** — Crie uma IAM Role dedicada por agente com `bedrock:InvokeAgent` e a permissão de Gateway escopada pelo ARN específico. Use `aws:ResourceTag` conditions para restringir acesso por ambiente (dev/staging/prod). Nunca use roles com `*` em recursos para agentes em produção.

3. **3. Implementar guardrails de custo desde o início** — Configure um AWS Budget com alerta em 80% do threshold diário para queries de Web Search. No código do agente, implemente `max_search_calls_per_turn ≤ 5` e circuit breaker com backoff exponencial. Monitore `WebSearchQueryCount` no CloudWatch com alarme de anomalia.

4. **4. Instrumentalizar com OpenTelemetry antes de ir para produção** — Adicione spans OTel para cada invocação de tool: `agent.tool.name`, `agent.tool.latency_ms`, `agent.search.result_count`. Nunca logue o texto raw da query (PII risk) — use hash ou categorias. Correlacione com o trace do modelo para visibilidade end-to-end. Defina SLO de P95 < 3s para o ciclo completo.

5. **5. Validar qualidade de grounding com query set de referência** — Antes de produção, construa um conjunto de 50-100 queries representativas do domínio (ex: circulares regulatórias, notícias de mercado) e avalie manualmente a relevância e precisão dos snippets retornados. Defina um threshold mínimo de relevância e automatize essa validação no pipeline de CI/CD do agente.

6. **6. Compor com Knowledge Base interna para reduzir custo e melhorar precisão** — Implemente um router de intenção que direciona queries sobre dados internos e históricos para a Knowledge Base (custo menor, corpus controlado) e queries sobre eventos recentes para o Web Search. Isso reduz o volume de queries pagas e melhora a precisão em domínios proprietários.

## Web Search AgentCore vs. alternativas de grounding web
| Critério | Critério | Web Search AgentCore | Bing Search API (Azure) | Brave Search API | Self-hosted (SerpAPI + Lambda) |
| --- | --- | --- | --- | --- | --- |
| Egresso de dados | Zero (dentro da AWS) | Dados saem para Azure | Dados saem para Brave | Dados saem para SerpAPI | — |
| Controle de corpus | Nenhum (índice Amazon) | Filtros básicos de domínio | Filtros básicos | Alto (configurável) | — |
| Integração MCP nativa | Sim (nativa) | Não (custom wrapper) | Não (custom wrapper) | Não (custom wrapper) | — |
| Preço por 1k queries | $7 | $3–$15 (por tier) | $3–$9 (por tier) | $5–$50 + infra Lambda | — |
| Disponibilidade regional | us-east-1 apenas (GA) | Global (Azure regions) | Global (API pública) | Depende do provedor | — |
| Knowledge Graph estruturado | Sim (Amazon KG) | Sim (Microsoft Entity) | Não | Não | — |

## Lente do AWS Well-Architected

- **security**: Zero egresso de dados é o ponto mais forte. Complemente com Bedrock Guardrails para filtragem de PII nos snippets retornados, resource-based policies no Gateway por role de agente, e KMS CMK para criptografia de logs de query no CloudWatch. Nunca logue o texto raw de queries que possam conter dados de clientes.
- **reliability**: Disponibilidade em us-east-1 única é o principal risco de confiabilidade. Implemente fallback para Knowledge Base interna com circuit breaker. Defina SLO de disponibilidade separado para o componente de Web Search e exclua-o do SLO geral do agente quando em modo degradado.

## Anti-padrões que já vi acontecer (ou que vão acontecer)

- **Usar Web Search para todo tipo de query**: invocar busca web para perguntas sobre dados internos ou históricos que a Knowledge Base responderia melhor e mais barato. Resultado: custo desnecessário e latência maior.
- **Sem limite de iterações no loop do agente**: agentes ReAct sem `max_iterations` podem entrar em loops de busca, gerando dezenas de queries por turno. Já vi isso consumir $500 em um único teste de carga.
- **Logar o texto raw das queries**: queries de agentes financeiros podem conter ticker symbols, nomes de clientes ou estratégias proprietárias. Logar o texto raw viola políticas de PII e cria risco regulatório.
- **Confiar cegamente nos snippets retornados**: o índice web é amplo mas não curado. Sem validação de qualidade, o agente pode raciocinar sobre snippets desatualizados, de fontes não confiáveis ou fora de contexto.
- **Arquitetura sem fallback regional**: usar Web Search como componente crítico sem fallback para Knowledge Base interna em caso de indisponibilidade regional — especialmente crítico com disponibilidade em us-east-1 apenas.

> **Minha nota de curadoria:** Adotaria o Web Search no AgentCore imediatamente para casos de uso de monitoramento regulatório e enriquecimento de relatórios em ambientes financeiros — mas não como componente crítico de caminho principal até que a disponibilidade multi-region seja realidade. A lição mais dura que aprendi em sistemas agentic financeiros é que **o risco de compliance de enviar prompts para terceiros é frequentemente subestimado até que o time jurídico revise o contrato** — e aí o projeto para. O Web Search resolve esse problema de forma elegante e gerenciada. O que eu faria diferente do tutorial padrão: implementar o intent router antes de qualquer coisa, configurar o budget alert no dia zero e construir o fallback para Knowledge Base interna como requisito não-negociável de arquitetura, não como melhoria futura.

## Veredicto: adotar com critério, não com entusiasmo

O Web Search no Amazon Bedrock AgentCore é uma capacidade genuinamente útil que resolve um problema real de governança em ambientes enterprise e financeiros: como dar aos agentes acesso a conhecimento web atual sem criar vetores de vazamento de dados para provedores externos. A execução técnica — MCP nativo, Knowledge Graph estruturado, citações com metadados, preço usage-based — é sólida para um lançamento de GA.

Os limitadores são igualmente reais: disponibilidade em us-east-1 apenas, ausência de controle sobre o corpus consultado, sem rate limiting nativo por agente, e preço que pode escalar rapidamente sem guardrails de custo adequados. Para sistemas financeiros multi-region ou com requisitos de corpus curado, esses não são detalhes — são bloqueadores que precisam de mitigação ativa ou de aguardar o roadmap da AWS.

Meu veredicto: **adote para casos de uso de monitoramento, enriquecimento e research em ambientes onde us-east-1 é aceitável; implemente com intent routing, circuit breaker, budget alerts e fallback para Knowledge Base interna; documente as limitações atuais como ADR com critérios de revisão**. Não adote como componente crítico de caminho principal em arquiteturas que exigem DR multi-region ou controle estrito de corpus. A direção estratégica da AWS com o AgentCore é convincente — esta é uma peça de uma plataforma agentic enterprise que vai amadurecer rapidamente.

## Referências

- [Announcing Web Search on Amazon Bedrock AgentCore (AWS News Blog)](https://aws.amazon.com/blogs/aws/announcing-web-search-on-amazon-bedrock-agentcore-ground-your-ai-agents-in-current-accurate-web-knowledge/)
- [Amazon Bedrock AgentCore Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html)
- [Amazon Bedrock AgentCore Pricing](https://aws.amazon.com/bedrock/agentcore/pricing/)
- [Model Context Protocol (MCP) Specification](https://modelcontextprotocol.io/specification)
- [Introducing Amazon Bedrock Managed Knowledge Base (AWS News Blog)](https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-managed-knowledge-base-for-faster-more-accurate-enterprise-ai-applications/)
- [Top Announcements AWS Summit New York 2026](https://aws.amazon.com/blogs/aws/top-announcements-of-the-aws-summit-in-new-york-2026/)
- [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)
- [Building Effective Agents — Anthropic Research](https://www.anthropic.com/research/building-effective-agents)