AgentCore Web Search: Build a Bounded Dependency Watcher

Amazon Bedrock AgentCore Web Search can supply current sources to a daily dependency watcher. The practical design is a scheduled research workflow with fixed boundaries: choose the packages, restrict the search window, retain evidence and review findings before recommending changes. It should supplement your vulnerability tooling, not declare a dependency safe.

AWS’s November 10 LangGraph walkthrough demonstrates parallel research across npm, PyPI and container dependencies. Its most useful idea is separating discovery from validation. A model finding a relevant-looking page is only the beginning of an alert.

Choose the search interface deliberately

AgentCore offers a direct InvokeWebSearch API and a managed Gateway connector. The service documentation distinguishes their input fields: the direct API uses searchQuery, while the MCP connector uses query. Copying a request between them without adapting it will not work.

Choose the direct API when your scheduled application owns the search calls. Choose Gateway when you need an MCP tool exposed to agents with centrally configured source restrictions. For Gateway, request filters can narrow an administrator’s include list but cannot expand it. Conflicting include lists can legitimately produce no results.

Do not interpret an empty response as a clean security report. Record whether the search completed, how many sources it returned and whether filters excluded the intended advisory domains. “No matching evidence found” and “search failed” need different statuses in the digest.

Keep the research budget outside the prompt

Define the package inventory, time window and maximum calls in application configuration. A prompt asking an agent to search only four times is weaker than code enforcing the limit. Also decide whether retries consume the budget and what happens when one ecosystem fails while the others succeed.

An illustrative daily run could allow four searches each for npm, PyPI and containers, giving a maximum of 12 search attempts. Run independent branches concurrently if useful, but retain separate failure states. A container-search timeout should not erase a verified PyPI finding or turn the overall run into a false all-clear.

The AWS example uses a bounded toolkit configuration. Check the package version and corresponding interface before copying it: the LangChain integration guide also documents a Gateway-based setup. Pin the implementation you review rather than mixing direct-API and Gateway snippets.

Separate evidence checks from security judgments

For each candidate, preserve the source URL, title, observed publication date, package identifier, advisory identifier and the excerpt supporting it. Require the URL to appear in the actual search results rather than accepting a model-generated citation.

AWS’s sample checks source provenance, package and identifier mentions, and publication-window membership. Those checks reduce obvious fabrication, but they do not establish affected versions, exploitation status, severity or the correctness of a remediation recommendation.

Consider a hypothetical alert for a library called example-parser. A page can mention that library and a valid advisory while discussing a different affected version from the one your application installs. Before assigning urgency, compare the primary advisory’s affected range with your resolved dependency version. Keep “potentially relevant” distinct from “confirmed affected.”

A page published today may also describe an old incident. Store the disclosure date separately from the page date when the source provides both. Otherwise, the watcher can repeatedly present retrospective reporting as a newly discovered vulnerability.

Deduplicate findings without hiding meaningful updates

A scheduled process needs durable state. An in-memory set disappears when the job exits, so it cannot prevent yesterday’s finding from becoming today’s new alert. Persist the package, advisory identifier, canonical source and last-seen evidence in a store appropriate to your application.

Use a stable finding key, then track material changes separately. An advisory receiving a fixed version is worth another notification; a different publication repeating the same facts usually is not. Keep a content or evidence revision alongside the key so deduplication does not suppress useful changes.

For each run, retain a small audit record containing the window, packages searched, attempted calls, failures and accepted findings. This lets an engineer distinguish “nothing changed” from “the watcher never completed,” without reading every model transcript.

Troubleshoot permissions before changing the agent

For the Gateway route, LangChain documents two permission boundaries: the caller needs InvokeGateway on the gateway, and the gateway execution role needs InvokeWebSearch on the service tool resource. A trust-policy Region mismatch can surface as a failure to obtain execution-role credentials.

Check those identities and the configured Region before modifying the model prompt. Authentication failures are infrastructure failures. They should stop the affected branch and produce a clear operational status rather than be summarized as missing search results.

Keep source links in the delivered digest. Besides allowing reviewers to inspect the evidence, citations are a condition of use for the connector. The digest should make the next step obvious: verify the installed version, inspect the upstream advisory or review the proposed upgrade.

Discovery should not automatically become remediation. Let the watcher bring evidence to the team, while version checks, tests and your change process decide what gets deployed. That boundary makes a small research agent useful without giving a plausible summary more authority than it deserves.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help teams turn agent workflows and complex engineering decisions into clear technical content that developers can apply.

Book a 30-minute call.