AgentCore Web Search can enforce source and date filters per call

AWS has added runtime domain and publication-date filters to Web Search on Amazon Bedrock AgentCore. Connector version 1.2.0 lets an application narrow the eligible web sources and date window on each tools/call, while a separate admin-level domain policy remains in force.

The change matters for agents that answer time-sensitive or source-sensitive questions. A prompt that says “use official sources from this week” is guidance to the model; a server-side filter changes what the search tool can return. This article explains how the two control layers combine, where their assurance stops, and how to test the boundary before relying on it in an operational workflow.

What changed in AgentCore Web Search?

AWS’s August 19 announcement documents four optional fields inside the Web Search tool’s filters object. domainFilter.include and domainFilter.exclude accept domain lists, with as many as 100 domains in each list. publishedDateFilter.from and publishedDateFilter.to accept inclusive ISO-8601 UTC bounds.

The fields apply to one invocation. If they are omitted, AWS says all indexed content remains eligible, matching the connector’s earlier behavior. This is an important default: merely upgrading the connector does not create a source or freshness boundary.

AWS describes the filter as server-side enforcement. The request enters AgentCore Gateway, the gateway combines runtime filters with the admin policy, search runs against the resulting scope, and only compliant results return to the agent. The managed connector is MCP-compatible and is discovered and invoked through tools/list and tools/call.

The release also expands Web Search availability to eu-west-1 in Ireland and ap-northeast-1 in Tokyo, alongside us-east-1 in Northern Virginia. Region availability is a deployment fact, not by itself proof that a particular workload meets residency, privacy, or regulatory requirements.

How do admin policy and per-call filters differ?

The admin policy is the organization ceiling. It should name sources that no application or tenant is allowed to search, regardless of what a prompt or runtime request asks for. The per-call fields then narrow that ceiling for a particular job, customer, or answer window.

Consider a product-support agent. Its admin policy may permit the company documentation site, status page, and a short list of approved upstream vendors. A request about a release in the past seven days can add that date window and include only the documentation and status domains. Another request can use a different subset without creating a new gateway target.

That layered design is more precise than embedding a long source rule in every prompt. It also creates a policy-composition question that should be settled with observed results: when admin and runtime settings conflict, does the actual eligible set match the organization’s intended intersection? AWS says the gateway merges the controls, but each team should verify its own configured policy, connector version, and request payload rather than infer the effective result set from configuration screens alone.

What does filtering not prove?

A domain allowlist says where a result may come from. It does not establish that every page on that domain is authoritative, current, unmodified, or relevant to the claim being made. An approved community, partner, or documentation domain can still contain obsolete pages, user-contributed material, regional variants, or conflicting versions.

A date filter has a similar limit. AWS’s response schema requires result text but marks URL, title, and publishedDate as optional. The public documentation does not establish how every undated or incorrectly dated page will behave under every date-bounded query. Treat that as a test case, not as permission to assume that the absence of a returned date proves freshness or exclusion.

Filtering also does not measure retrieval completeness. A result set can obey every domain and date rule while missing the most important page. Reviewers still need to check whether the citations support the answer’s specific claims and whether known authoritative material was absent.

How should teams test the combined boundary?

Use one recurring task with a verifiable answer, such as summarizing software release changes from approved vendor documentation. Create controlled pages or select known pages that cover four conditions: an allowed domain inside the window, a disallowed domain inside the window, an allowed domain outside the window, and a page whose returned result does not report a publication date.

Run each case through the same gateway and connector version. Preserve the effective admin-policy version, exact runtime filter object, query, returned URLs, presence or absence of publishedDate, citations, latency, errors, and empty-result behavior. Do not put secrets or unnecessary customer context into the test query or log.

The failure behavior matters as much as the successful result. Decide what the application does when filtering returns nothing: state that no eligible evidence was found, widen scope only through an approved path, ask for a different date range, or hand the task to a person. Silently removing the filter or answering from model memory would defeat the control.

Test both date boundaries because AWS documents them as inclusive. Test subdomains and similarly named domains against the intended admin and runtime rules. If the application is multi-tenant, confirm that one tenant cannot supply a runtime list that reaches another tenant’s disallowed source class.

AWS’s Web Search documentation also requires supplied citations and links to remain visible when an end-user output uses search results. The same acceptable-use section prohibits bulk extraction or storage of results and using the service to build a competing index or database. Citation rendering and downstream storage therefore belong in the acceptance test, not only the retrieval call.

What is the business decision now?

Teams using AgentCore Web Search can move source and freshness scope out of prompt wording and into an enforced request boundary. Keep the admin policy broad enough for approved organizational use but narrow enough to remain meaningful. Add task-specific domain and date scope at runtime, then preserve the effective settings beside the evidence returned.

Adopt the new fields for a production workflow only after conflicting policy, date-edge, undated-page, empty-result, citation, and logging tests behave as intended. The useful result is not simply “the filter returned fewer pages.” It is that the application can explain which source boundary applied, what evidence survived it, and what happens when no eligible evidence exists.

BaristaLabs can review one grounded workflow and help define the policy ceiling, per-call scope, evidence checks, and failure behavior without collecting production credentials or customer records.

Sources

• AWS AI Blog: “Domain and publish date filters for Web Search on AgentCore”, published August 19, 2026.
• Amazon Bedrock AgentCore Developer Guide: “Web Search Tool”, accessed August 27, 2026.
• Amazon Bedrock pricing, accessed August 27, 2026. Pricing units were not used as claims in this article; confirm current account and Region pricing before deployment.

AWS controls connector behavior, availability, indexing, and pricing. BaristaLabs supplies the policy-composition, testing, and failure-handling recommendations.