Domain and publish date filters for Web Search on AgentCore Amazon Web Services (AWS) announced runtime domain and published-date filtering for Web Search on Amazon Bedrock AgentCore, shipping in web-search connector version 1.2.0, enabling per-call control over which domains agents search and the publication-date window of results. The release also expands Web Search availability to eu-west-1 (Dublin) and ap-northeast-1 (Tokyo) regions, with a zero-egress architecture that keeps search queries within AWS. Artificial Intelligence /blogs/machine-learning/ Domain and publish date filters for Web Search on AgentCore When an AI agent uses Web Search to ground its answers on behalf of a customer, the organization behind that agent needs domain and date filters to control which sources the agent consults and how fresh those sources must be. A financial-services agent shouldn’t ground its answers in an unvetted blog. A product-information agent shouldn’t cite pricing or inventory data from three years ago when the user asked about current availability, as stock levels and pricing change rapidly. Today, we’re announcing runtime domain and published-date filtering for Web Search on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model. This capability ships as part of the web-search connector version 1.2.0. These capabilities give developers per-call control over which web domains their agents can search and what publication-date window results must fall within, all enforced server-side. No external orchestration is required. When combined with existing admin-level domain policies, organizations have a layered filtering model that enforces enterprise governance while giving individual API calls the flexibility to narrow scope dynamically, per request. Alongside runtime filtering, this release also expands Web Search availability to two new AWS Regions: eu-west-1 Dublin and ap-northeast-1 Tokyo . Customers in Europe and Asia Pacific can now invoke Web Search from a regional endpoint closer to their workloads, reducing latency and providing an EU-based entry point for organizations with data proximity requirements. AgentCore uses a zero-egress architecture where search queries remain within AWS. This regional expansion gives regulated customers in these regions a path to grounded agents without routing traffic across the Atlantic. In this post, we walk through what runtime filtering is, why it matters, how the layered admin-plus-runtime model works, how to get started with the new API parameters, and what regional availability means for your workloads. What’s new in connector version 1.2.0 This launch introduces two new capabilities within the filters object of the Web Search tool input schema: 1. Runtime domain filtering Pass an include allowlist or exclude denylist list of domains on every tools/call invocation. This gives per-request control over which sources the agent may consult. Field | Description | | filters.domainFilter.include | Results from these domains are returned | | filters.domainFilter.exclude | Results from these domains are suppressed | Each list supports up to 100 domains , counted independently. 2. Published-date filtering Restrict results to content published within a specific date range using ISO-8601 UTC bounds: Field | Description | | filters.publishedDateFilter.from | Earliest publication date inclusive | | filters.publishedDateFilter.to | Latest publication date inclusive | Both filters are optional and applied per request. Omitting them preserves the existing behavior where all indexed content is eligible. Why runtime filtering matters Real-world agent workloads demand more granular control than organization-wide policies alone can provide: Per-task source restriction : A compliance agent analyzing regulatory updates should only search .gov domains and approved publishers, not the open web. Temporal scoping : A market-intelligence agent summarizing “this week’s earnings calls” should never surface results from prior quarters, even if they rank highly for the query. Dynamic allow/deny at call time : A multi-tenant platform serving different customers may need different domain policies per request, without creating separate targets for each tenant. Content freshness guarantees : A customer support agent answering “what changed in the latest release” should only return documentation published in the past 7 days. Runtime filtering addresses these needs by moving control into the API call itself. How it works: The request flow The following diagram shows the lifecycle of a filtered search request: your agent sends a tools/call with query and filters, the Gateway merges your runtime filters with the admin-level policy, executes the filtered query against the web index, enforces compliance on the raw results, and returns only verified results for your agent to ground its response on. The entire lifecycle is server-side. There’s no client-side filtering loop, no post-processing, and no additional roundtrips. The layered filtering model: Admin + runtime A key design principle of this launch is that runtime filters can narrow but never expand the scope set by an administrator . This ensures enterprise policy is always enforced, regardless of what a runtime caller requests. The admin-level domain lists are set up during creation of the connector resource. Merge logic The following diagram illustrates how admin-level and runtime filter lists combine: include lists merge by intersection only domains present in both lists survive while exclude lists merge by union a domain blocked at either level stays blocked . Notice how d.com is dropped from the effective allowlist because it appears only in the runtime list, not the admin policy. Domain include allowlist : The effective allowlist is the intersection of admin and runtime lists. If the admin allows a.com, b.com, c.com and the runtime call includes b.com, c.com, d.com , only b.com and c.com are searched. The domain d.com is outside the admin domain list and is silently dropped. Domain exclude denylist : The effective denylist is the union of admin and runtime lists. If the admin blocks x.com and the runtime call excludes y.com , both are blocked. Note: A runtime caller can’t search a domain the admin hasn’t allowed and can’t unblock a domain the admin has denied. Runtime filters can only further restrict the search space. Filter compliance behavior When filters are active, Web Search prioritizes precision over recall. Results that can’t be verified against your filter criteria are excluded rather than returned unfiltered: Domain filter active: Results without a recognizable domain are excluded from consideration. Date filter active: Results without a recognized publication date are excluded. You might receive fewer results when filters are active, but every result you do receive satisfies your specified filter criteria. Cap enforcement There are four lists: admin include, admin exclude, runtime include, and runtime exclude. Each supports up to 100 entries independently. For full configuration details and composition rules, see Configure domain filtering https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html gateway-target-connector-web-search-tool-domain-filtering in the Developer Guide. Getting started Web Search is delivered through AgentCore Gateway, a capability of Amazon Bedrock AgentCore that provides a managed endpoint, compatible with the Model Context Protocol MCP , for connecting agents to tools. Follow these steps to enable runtime domain and date filtering for your Web Search target. Prerequisites - An Amazon Bedrock AgentCore Gateway with a Web Search target pinned to connector version 1.2.0 or later. - AWS Identity and Access Management IAM permissions: your calling agent or application needs bedrock-agentcore:InvokeGateway on the gateway Amazon Resource Name ARN , and the Gateway’s service role needs bedrock-agentcore:InvokeWebSearch . See Configure the Gateway Service Role https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-api-target-config.html gateway-add-target-api-connector-web-search-service-role for the complete policy. - The latest AWS SDK Python, JavaScript, Java, .NET, Go, Ruby, or PHP . Step 1: Create a Web Search target with version 1.2.0 Use AWS SDK for Python Boto3 to create or update a target pinned to version 1.2.0, with admin-level domain policies. If you already have a Web Search target on version 1.1.0, you can use UpdateGatewayTarget to pin it to version 1.2.0 instead of creating a new target. For additional setup options, including the AgentCore CLI and console, see Set up Web Search Tool https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-api-target-config.html gateway-add-target-api-connector-web-search-setup . Step 2: Invoke with runtime filters Imagine your agent monitors SEC enforcement actions for a legal team. The team only trusts sec.gov as a primary source, and they need actions from the current month, not historical filings. Here’s the tools/call payload your agent sends: The agent receives only results from sec.gov published in the last five weeks. There’s no third-party legal commentary or outdated filings in the results. Note: The tool name in your tools/call request is the name discovered through tools/list , which follows the pattern