AWS Gives Agents Web Search Without API Keys: A Dependency Watchdog Finishes in 36 Seconds

A model doesn't know what came out this morning: no fresh vulnerabilities, no releases, no new prices. So any agent that deals with current events needs web search. In production, three requirements come up immediately: results with links, control over which sources to trust, and a guarantee that search queries don't leak. Queries often reveal what a team is working on. AWS addresses these requirements with the new Web Search API in Amazon Bedrock AgentCore, and demonstrates it with a practical example: a daily dependency "watchdog" for a security team.

What exactly was launched

The Web Search API gives an agent current results in a single call. Each result includes the page title, URL, publication date and an excerpt relevant to the query. A query can be restricted by domain (include or exclude) and by date range. It is served by a web index that Amazon itself manages, not by a third-party search engine.

Authentication uses AWS Signature Version 4 with the role the agent already runs under: on Lambda, ECS or in the AgentCore runtime. There is no separate search key, so there is nothing to store or rotate. Platform teams have a second route, AgentCore Gateway: an administrator sets a single source policy for all agents and MCP clients, and the agent cannot remove that policy.

For LangChain users, the web search tool in langchain-aws now calls this API. It works with LangChain agents, LangGraph and Deep Agents.

How the watchdog works

Every morning, a LangGraph graph checks whether anything new has appeared about the packages and images the team ships. Three branches (npm, PyPI and container base images) run in parallel. In each one, a Claude model from Bedrock decides what to search for and, at the end, returns structured findings in a Pydantic schema: package, title, CVE or advisory ID, stated severity, an exploitation flag, recommended action and source URL.

The key idea is the division of labor: the model comes up with queries and writes conclusions, while everything that must run regardless of how the model behaves lives in code. The tool is created with fixed parameters: a domain blocklist, a lower date bound, and a maximum of four searches per branch. The option model_filters=False leaves the model with a single argument, the query text. The tool returns results twice: as text for the model and as an artifact for the graph, so that code can verify them.

Before returning, each finding goes through four checks against what the same branch's searches returned:

• the URL actually appeared in the results;
• the title or source text names the package as a whole word;
• the CVE or ID from the finding is present in the source text;
• the publication date falls within the watch window (no date counts as outside the window).

Then the keep_new step compares the surviving findings against the LangGraph store so that the same item doesn't arrive twice, and report builds a table with links.

What the run showed

On a seven-day window, the three branches ran 12 searches and got 80 sources. It took 36 seconds, versus 99 if the branches had run one after another. Verification rejected two findings: for one, the source didn't name the package; for the other, the CVE number was not in the text. Four passed, but the report showed two; the other two were already in the store from earlier tests. A repeat run on the same data produced an empty report, as it should for a daily job.

Limitations and what to do in practice

Most important: the checks catch invented URLs and IDs, sources that don't mention the package, and outdated pages. But they do not confirm severity, whether exploitation occurred, affected versions or the recommendation. A page indexed this week may describe an old incident. For a real security process, cross-check findings against authoritative vulnerability databases, and have a human review them before any action.

A few more practical details:

• InMemoryStore lives only for the duration of a session. A daily run needs persistent storage, such as DynamoDBStore, and sessions in the AgentCore runtime are ephemeral.
• The default limit is 10 requests per second per region for the whole account, and parallel branches share it.
• The tool is named web_search. If an agent already has another search tool with that name, rename one of them.
• Permissions should be minimal: a single action, bedrock-agentcore:InvokeWebSearch, on a resource owned by AWS.

The choice between the two routes is simple. If the application calls search itself and sets its own rules, use the API directly. If a platform team hands out search to many agents and wants a single source policy, you need Gateway. It also fits if MCP clients such as Claude need search. For different teams, it is enough to create a separate web search target with its own blocklist.