翻訳待ち：Domain and publish date filters for Web Search on AgentCore

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

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. Figure 1: Lifecycle of a filtered Web Search request, from tools/call to verified results 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. Figure 2: How admin and runtime domain lists merge, intersecting include lists and unioning exclude lists 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 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 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. import boto3 gateway_client = boto3.client("bedrock-agentcore-control", region_name="us-east-1") # Create a Web Search target pinned to version 1.2.0 with admin-level domain filtering target = gateway_client.create_gateway_target( gatewayIdentifier="your-gateway-id", name="web-search-filtered", targetConfiguration={ "mcp": { "connector": { "source": {"connectorId": "web-search", "version": "1.2.0"}, "configurations": [ { "name": "WebSearch", "parameterValues": { "domainFilter": { "include": [ "approved-wire-1.com", "approved-wire-2.com", "sec.gov", "investor.gov", ], "exclude": ["unreliable-source.net"], } }, } ], } } }, credentialProviderConfigurations=[ {"credentialProviderType": "GATEWAY_IAM_ROLE"} ], ) print(f"Target ID: {target['targetId']}") print(f"Status: {target['status']}") 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: { "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "WebSearch", "arguments": { "query": "latest SEC enforcement actions 2026", "filters": { "domainFilter": { "include": ["sec.gov"], "exclude": [] }, "publishedDateFilter": { "from": "2026-07-01T00:00:00Z", "to": "2026-08-04T23:59:59Z" } } } } } 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 _WebSearch. For the target created earlier, that’s web-search-filtered_WebSearch. The runtime include list (sec.gov) intersects with the admin list (approved-wire-1.com, approved-wire-2.com, sec.gov, investor.gov). Because sec.gov appears in both, it is searched. If you passed some-other-site.com, it would be silently dropped because it’s not in the admin allowlist. Sample code examples Here are some examples of how you can use the MCP client created from the AgentCore Gateway with the new filters at runtime. Code sample to create MCP client for calling tools Example 1: Clinical research assistant with regulatory citation requirements You’re building a research assistant for a pharmaceutical company’s regulatory affairs team. Company policy mandates that every answer cite only FDA, NIH, or ClinicalTrials.gov. A citation from a health blog isn’t only a quality issue. It’s a compliance violation that could surface in an audit. The agent needs to enforce this on every search, regardless of what query the model constructs. import json # Pharma research assistant: only approved regulatory sources compliance_request = json.dumps({ "jsonrpc": "2.0", "id": "req-001", "method": "tools/call", "params": { "name": "WebSearch", "arguments": { "query": "FDA drug approval process 2026 guidance", "maxResults": 10, "filters": { "domainFilter": { "include": ["fda.gov", "nih.gov", "clinicaltrials.gov"] } } } } }) # Send via your MCP client (SigV4-signed or OAuth-authenticated) response = mcp_client.send(compliance_request) results = json.loads(response) # Every result is from fda.gov, nih.gov, or clinicaltrials.gov for result in results["result"]["content"]: print(result["text"]) Every result your agent cites is now verifiably from an approved regulatory source. Even if a WebMD article ranks #1 for the query, it never enters the model’s context window. Example 2: Stock-update agent, only this week’s coverage Your trading desk runs an agent that generates stock updates throughout the trading day. The problem: when a trader asks “what’s the latest on semiconductor stocks?”, the agent used to surface a highly-ranked analysis from last quarter, and a trader who acts on stale coverage loses money. [truncated for AI cost control]