要点
- On 10 November 2026, Amazon published an AWS Machine Learning blog, "Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search," by Sundar Raghavan and Omar Abdelwahab. It announces that the Web Search API in Amazon Bedrock AgentCore is now available.
- AWS says every query is served from a web index that Amazon operates and is not sent to a third-party search engine. Calls are signed with the application's existing AWS credentials. There is no search API key to store. The required permission is bedrock-agentcore:InvokeWebSearch on a resource AWS owns.
- Each result includes the page title, URL, publication date, and an extract. Requests can include or exclude domains and limit results to a date range. The langchain-aws toolkit can attach a date floor, a blocklist, a search budget, and returned sources as data, and can hide those filters from the model.
- In the authors' test, three research branches ran in parallel, made 12 searches, received 80 sources, and finished in 36 seconds of wall time, against 99 seconds added together. An evidence check dropped two findings. Four findings passed, and a store held back two already reported items, leaving two new ones.
- The four checks confirm that a cited URL came back from that branch's own searches, that the source names the package, that any CVE or advisory ID appears in the text, and that the dated page falls inside the window. They do not confirm severity, exploitation, affected versions, or the recommended action, and a page dated this week can describe an older incident.
On 10 November 2026, Amazon published an AWS Machine Learning blog introducing a daily dependency watch built with LangGraph and the Web Search API in Amazon Bedrock AgentCore. The post, signed by Sundar Raghavan and Omar Abdelwahab, also says that API is now available. The checkable claim is not that agents can finally search the live web. It is that AgentCore keeps the search query and the source policy inside the AWS boundary, and in code the model cannot loosen, so the product being sold is governance of search, not freshness alone.
[1]What AgentCore actually shipped
The post describes a first-party search API for agents and applications. A caller signs the request with the AWS credentials it already uses, including an execution role on AWS Lambda, Amazon Elastic Container Service, or Amazon Bedrock AgentCore runtime. AWS says it serves every query from a web index that Amazon operates, and does not send the query to a third-party search engine. That is a product claim about where the query text goes, and it matters because those queries often reveal internal work.
Each result includes the page's title, URL, publication date, and an extract relevant to the query. Requests can include or exclude domains, and can limit results to a publication date range. The same search is also offered through AgentCore Gateway, where an administrator source policy can be applied to every agent and Model Context Protocol client. The notebook in the post uses the US East, N. Virginia, Region, written as us-east-1, and the authors point readers to a list of supported Regions rather than claiming global coverage in the text we read.
For LangChain developers, the AgentCore web search tool in LangChain's AWS integration now calls this API. The post gives minimum versions for the walkthrough: boto3 1.43.127 or later, the AgentCore Python SDK 1.26.0 or later, and langchain-aws 1.9.3 or later. By default, the post says, an account can send 10 requests per second in each Region, and all agents in an account share that quota.
[1]The dependency watch and the authors' own test
The worked example is a morning watch for a security team. It starts with a watchlist and a time window, then fans out one research branch each for npm, PyPI, and container base images. LangGraph runs the three branches in parallel. Inside each branch, an Anthropic Claude model on Amazon Bedrock decides what to search for and, at the end, returns structured findings. The branch's search tool adds the date window and the blocklist to every query, signs the request, and stops after four searches. When the branches finish, the graph keeps only findings that pass an evidence check, drops items already reported, and builds a cited table.
In the authors' run, the three branches made 12 searches and got 80 sources back. They finished in 36 seconds of wall time, against 99 seconds for the branches added together. The evidence check dropped two findings: one whose source did not name the package, and one whose CVE identifier did not appear in its source. None of the sources came from the blocked domain. Four findings passed the checks. A store had already recorded two of them from earlier test runs, so the report listed two new findings. A second run with the same input searched again, kept two findings, and reported nothing new, because both were already in the store.
Those timings and counts are a single vendor demonstration, not a third-party benchmark. They show that the graph can run, filter, and remember, on the authors' own notebook. They do not show how the API behaves under another team's sources, or at the shared 10-requests-per-second cap.
[1]What stays in code, outside the model
The design thesis sits in one sentence from the post. The model decides what to search for and writes the findings. Every rule that must hold, whatever the model does, stays in code: the date window, the blocklist, the search budget, and the checks on each finding. In the toolkit setup the authors show, the date floor and the excluded domains are attached by the tool. With model_filters set to false, the model sees only a query argument. It can narrow those constraints, the post says, but it cannot lift them. Each branch gets its own toolkit, so the search budgets do not collapse into one shared counter the model can spend down.
The evidence check is also code. Before a branch returns, four tests run against that branch's own search results. The cited URL must have come back from one of those searches. The source's title or text must name the package as a whole word. Any CVE or advisory identifier in the finding must appear in that text. The source's publication date must fall inside the watch window, and a missing date counts as outside. After the branches merge, a store records what has already been reported, so a daily job should not surface the same advisory twice.
On AgentCore Gateway, the same idea is moved one layer further out. The blocklist can sit on the gateway target as an administrator policy, hidden from the agent, which cannot lift it. The post says this route needs two permissions on two principals: the gateway's service role needs permission to call web search, and the agent needs permission to call the gateway.
[1]What the checks cannot confirm
The authors are explicit about the gap. The four checks catch an unsupported URL, a source that does not name the package, an invented identifier, and an out-of-window or undated source. They do not confirm severity, exploitation status, affected versions, or the recommended action. They also do not prove when an issue was first disclosed. A page that the index dates this week can describe an older incident. For a production security workflow, the post says, findings should still be verified against authoritative vulnerability feeds, and someone should review a finding before anyone acts on it.
That limitation is the point at which "cited web search" stops being a substitute for a vulnerability program. The API can keep queries in-boundary and keep policy out of the model's hands. It cannot, on this evidence, tell a team whether a finding is new, exploitable, or correctly graded.
The post is an AWS product blog. The 36-second and 99-second figures, the 12 searches, and the 80 sources are the authors' test. Pricing is mentioned only by reference to Amazon Bedrock AgentCore pricing, with a cap of 12 searches per watch run in the example. We did not independently call the API or rerun the notebook.
[1]The fair case
The fair reading is that teams already building agents on AWS have a reason to want search that does not leave their cloud account, and that does not depend on a rotatable third-party key. Putting the date window, the blocklist, and the budget in code is the correct place for those rules, because a model that can rewrite its own source policy is not a policy. The evidence checks, modest as they are, are a concrete way to keep citations attached to what the search actually returned.
It is also fair to say that this is still a how-to around a new AWS API. The freshness of results, the coverage of the Amazon-operated index, and the quality of the extracts are not independently measured in the post. A team that already trusts another search provider may see less new information here than a team that has been blocked by key management, data-residency rules, or a model that keeps ignoring a blocklist.
[1]Who should care, and what to watch
Security and platform teams that already run agents on AWS, and that today send search queries to an outside engine, should care. So should LangChain and LangGraph developers who want filters the model cannot turn off, and administrators who want one source policy to cover many agents through a gateway.
In the next six months, the tests are whether teams adopt the API as their default search path, whether the shared Regional quota becomes a practical limit when many agents search at once, and whether production watches still need a human review step after the evidence checks, as the authors already recommend. A second test is whether AWS publishes anything checkable about index coverage and extract quality, which this post does not.
[1]Close
On the evidence in this post, AgentCore web search is a way to keep query text and source policy inside AWS and in code, then to check citations against what that search returned. It is not a complete vulnerability workflow, and the 36-second demonstration does not stand in for that. The claim to watch is whether those in-code rules, and the in-boundary query path, become the default for AWS-hosted agents over the next six months, while human review of severity and novelty stays in the loop.
[1]