What changed on August 19
AWS announced two simultaneous updates to Bedrock AgentCore Web Search on August 19, 2026: regional expansion to Europe Ireland (eu-west-1) and Asia Pacific Tokyo (ap-northeast-1), and the addition of per-call domain and publication-date filtering. The service, which launched at AWS Summit New York in June, was previously limited to US East North Virginia. The combined update directly addresses the two most common objections raised by enterprise teams evaluating the tool: that it was not available where their workloads run, and that it lacked the source-control granularity their compliance and security teams require.
For teams already building AI agent systems on AWS, this update changes the calculus on several use cases that were previously impractical — particularly in regulated European industries where data residency requirements ruled out the US East endpoint.
New regions and why EU matters
When Bedrock AgentCore Web Search launched in June it was US East only. That meant a European team running agents in eu-west-1 had to route web-search queries to a different region, which created a cross-region data transfer and a potential GDPR Article 46 compliance gap for any personal data that might be included in the query context. The eu-west-1 launch closes that gap: the entire agent execution chain — model inference, tool calls and web-search retrieval — can now stay inside a single AWS region in the EU.
This matters most for three groups: financial services firms under EBA guidelines that restrict cross-border data movement; healthcare platforms subject to GDPR special-category data rules; and multi-tenant SaaS companies that have contractually committed to EU data residency for specific customers. In all three cases, “the web-search tool only works in the US” was a hard blocker that has now been removed.
The Asia Pacific Tokyo (ap-northeast-1) launch extends the same capability to teams serving Japanese enterprise customers, where sector-specific regulations impose similar residency expectations, particularly in financial services under FISC standards.
Domain and date filters explained
The second part of the update — filtering controls — addresses a structural problem with web-grounded agents: the web is large, unreliable and stale in places. Two new filter types are now available on every Web Search call:
Domain filtering lets developers pass an include list (allowlist) and an exclude list (denylist) directly in the API call. Each list supports up to 100 domains. An include list restricts the search to the specified domains only; an exclude list blocks those domains from appearing in results. This operates at the API level, server-side, with no post-processing or external orchestration required. The practical effect is that a financial services agent can be configured to only cite sources from a list of approved regulators and data providers, rather than the open web.
Date filtering lets developers set a publication-date window using ISO-8601 UTC bounds — a “from” date, a “to” date, or both. An agent that needs to summarise this week’s earnings calls can be constrained to the last seven days at the API call level, eliminating the risk of surfacing three-year-old results that happen to be highly ranked. For use cases where information freshness is a correctness requirement rather than a preference, this removes a layer of post-processing that teams were previously implementing themselves.
The layered filtering model
The filtering system uses a layered architecture that separates administrator controls from runtime controls:
- Gateway-level allowlist: Administrators can set an allowlist at the gateway level that applies to all calls passing through that gateway. This is the compliance control surface — it ensures that no runtime caller can expand the permitted source set beyond what the administrator has approved.
- Runtime filters: Individual API calls can narrow the scope set by the gateway (adding more specific include rules or additional excludes), but they cannot expand it. The rule is: runtime filters can narrow but never expand the administrator’s scope.
- Include lists merge by intersection: If the gateway allows domains A, B and C, and a runtime call specifies include [B, C, D], the effective include is [B, C] — D is not in the gateway-level allowlist, so it is dropped.
- Exclude lists merge by union: If the gateway blocks domain X, and a runtime call also blocks domain Y, both X and Y are blocked for that call.
This model means that compliance requirements can be enforced centrally at the gateway, while individual agent workflows retain the flexibility to narrow scope further for their specific task. A multi-tenant SaaS platform can assign different domain policies to different customer tiers without giving any customer the ability to exceed the platform-level policy.
The entire filtering pipeline runs server-side within the customer’s AWS environment, so the constraint is not just a guideline — it is enforced at the infrastructure level before results are returned to the model.
What it means for US & EU software teams
Three practical implications for teams building or evaluating agentic systems on AWS:
EU-only agent workflows are now viable on Bedrock. Before this update, teams committed to EU data residency had a binary choice: skip web grounding, or introduce a cross-region hop. The eu-west-1 launch removes that trade-off. Teams can build agents that retrieve live web context without data leaving the EU, which is the baseline many enterprise procurement teams require before approving a tool for production use.
Domain filtering changes the RAG-vs-web-search calculus. One reason teams build custom RAG pipelines over curated document stores rather than using web search is source control: with an open web search, you cannot guarantee that the agent will not cite a competitor, an outdated article or an unapproved source. Per-call domain allowlists bring that level of control to web search at the API level, without the ongoing cost of maintaining a curated document store. For use cases where the source universe is bounded — regulatory filings, approved vendor documentation, internal wikis with public mirrors — this makes managed web search a more practical alternative to RAG for freshness-sensitive queries.
Date filtering is a correctness tool, not just a UX feature. The most common failure mode in web-grounded agents is not hallucination — it is accurate-but-stale information presented without a timestamp. An agent citing a 2023 pricing guide as if it were current is producing a factual error that neither the model nor the user may catch. Date filtering enforced at the API level converts a best-practice recommendation (“please search recent sources”) into a hard constraint that the infrastructure enforces, not the prompt.
Frequently asked questions
What is Amazon Bedrock AgentCore Web Search?
Bedrock AgentCore Web Search is a fully managed tool that lets AI agents retrieve live, cited information from the public web at query time, without any data leaving the customer’s AWS environment. Agents send a natural-language query; the service returns relevant snippets, source URLs and publication dates that the model can reason over. It is priced at $7 per 1,000 queries and does not require managing a search-engine API key or third-party service.
Which regions does Bedrock AgentCore Web Search support after August 19?
After the August 19, 2026 expansion the service is available in US East N. Virginia (us-east-1), Europe Ireland (eu-west-1) and Asia Pacific Tokyo (ap-northeast-1). The Ireland region means EU-based teams can run web-grounded agents entirely within AWS infrastructure inside the EU, satisfying most data residency requirements without cross-region data transfer.
What are domain and date filters in AgentCore Web Search?
Domain filters are per-call include and exclude lists of up to 100 domains each that restrict or block web sources at the API level, with no external orchestration required. Gateway-level allowlists set the maximum permitted scope; runtime calls can narrow it further but never expand it. Date filters constrain results to a publication-date window using ISO-8601 UTC bounds. Both filter types are enforced server-side within the customer’s AWS environment.
How does this affect teams building GDPR-compliant AI agents in Europe?
The EU Ireland region launch means web-grounded agent workflows no longer require a cross-region data transfer, which is relevant for GDPR Article 46 transfer requirements and sector-specific mandates in finance and healthcare. The domain-filtering capability also provides a compliance-auditable control surface: teams can restrict agents to a declared list of approved sources, which is easier to document in a data protection impact assessment than an unrestricted web crawl.
Sources
AWS What’s New — Web Search in Amazon Bedrock AgentCore adds domain and date filtering, expands to Europe and Asia Pacific (August 19, 2026)
AWS Machine Learning Blog — Domain and publish date filters for Web Search on AgentCore (August 2026)