AWS dá a agentes busca na web sem chaves de API: o vigia de dependências terminou em 36 segundos

O modelo não sabe o que foi lançado hoje de manhã: nem vulnerabilidades recentes, nem releases, nem novos preços. Por isso, qualquer agente que trabalhe com eventos atuais precisa de busca na web. Em produção, três exigências aparecem de imediato: resultados com links, controle sobre quais fontes merecem confiança e a garantia de que as consultas de busca não vazem. Muitas vezes, as consultas revelam no que a equipe está trabalhando. A AWS atende a esses requisitos com a nova Web Search API no Amazon Bedrock AgentCore e a demonstra num exemplo prático: um «vigia» diário de dependências para equipes de segurança.

O que exatamente foi lançado

A Web Search API entrega ao agente resultados atuais com uma única chamada. Cada resultado traz o título da página, a URL, a data de publicação e um trecho relevante para a consulta. É possível restringir a consulta por domínios (incluir ou excluir) e por intervalo de datas. Quem atende a consulta é um índice da web gerenciado pela própria Amazon, e não um buscador de terceiros.

A autenticação usa o AWS Signature Version 4, com o papel (role) sob o qual o agente já roda: no Lambda, no ECS ou no AgentCore runtime. Não existe uma chave de busca separada, então não há nada para armazenar nem rotacionar. Para equipes de plataforma, há um segundo caminho, o AgentCore Gateway: o administrador define uma única política de fontes para todos os agentes e clientes MCP, e o agente não pode removê-la.

Para quem usa LangChain, a ferramenta de busca na web do langchain-aws agora chama essa API. Ela funciona com agentes LangChain, LangGraph e Deep Agents.

Como o vigia funciona

Um grafo LangGraph verifica toda manhã se surgiu algo novo sobre os pacotes e imagens que a equipe publica. Três ramos (npm, PyPI e imagens-base de contêineres) rodam em paralelo. Em cada um, um modelo Claude do Bedrock decide o que buscar e, no final, devolve achados estruturados conforme um esquema Pydantic: pacote, título, CVE ou ID do boletim, severidade declarada, indicação de exploração, ação recomendada e URL da fonte.

A ideia central é a divisão de trabalho: o modelo elabora as consultas e redige as conclusões, enquanto tudo o que precisa ser executado, independentemente do comportamento do modelo, fica no código. A ferramenta é criada com parâmetros fixos: lista de bloqueio de domínios, limite inferior de data e no máximo quatro buscas por ramo. A opção model_filters=False deixa ao modelo um único argumento: o texto da consulta. A ferramenta devolve os resultados duas vezes: como texto para o modelo e como artefato para o grafo, para que o código possa verificá-los.

Antes de devolver, cada achado passa por quatro verificações contra o que as buscas do mesmo ramo retornaram:

• a URL realmente apareceu nos resultados;
• o título ou o texto da fonte cita o pacote como palavra inteira;
• o CVE ou ID do achado consta no texto da fonte;
• a data de publicação está dentro da janela de observação (sem data, o achado é considerado fora da janela).

Em seguida, a etapa keep_new compara os achados aprovados com o armazenamento do LangGraph, para que o mesmo item não chegue duas vezes, e a etapa report monta uma tabela com links.

O que a execução mostrou

Em uma janela de sete dias, os três ramos fizeram 12 buscas e obtiveram 80 fontes. O processo levou 36 segundos, contra 99 se os ramos rodassem um após o outro. A verificação descartou dois achados: em um, a fonte não citava o pacote; no outro, o número do CVE não estava no texto. Quatro passaram, mas o relatório exibiu dois, porque os outros dois já estavam no armazenamento por causa de testes anteriores. Uma nova execução com os mesmos dados gerou um relatório vazio, como deve acontecer numa tarefa diária.

Limitações e o que fazer na prática

O ponto mais importante: as verificações pegam URLs e IDs inventados, fontes sem menção ao pacote e páginas desatualizadas. Mas elas não confirmam a severidade, o fato de exploração, as versões afetadas nem a recomendação. Uma página indexada nesta semana pode descrever um incidente antigo. Em um processo real de segurança, confronte os achados com bases de vulnerabilidades de referência e peça a uma pessoa que os revise antes de qualquer ação.

Alguns detalhes práticos:

• O InMemoryStore vive apenas durante a sessão. Para uma execução diária, é preciso um armazenamento persistente, como o DynamoDBStore, já que as sessões no AgentCore runtime são efêmeras.
• O limite padrão é de 10 requisições por segundo por região para toda a conta, e os ramos paralelos o dividem entre si.
• A ferramenta se chama web_search. Se o agente já tiver outra busca com esse nome, renomeie uma delas.
• As permissões necessárias são mínimas: uma única ação, bedrock-agentcore:InvokeWebSearch, sobre um recurso pertencente à AWS.

A escolha entre os caminhos é simples. Se o aplicativo chama a busca por conta própria e define as próprias regras, use a API diretamente. Se uma equipe de plataforma distribui a busca para vários agentes e quer uma política de fontes unificada, o caminho é o Gateway. Ele também serve quando a busca é necessária para clientes MCP como o Claude. Para equipes diferentes, basta criar um web search target separado, com sua própria lista de bloqueio.