Bedrock Web Search Adds Domain Filtering

Web Search on Amazon Bedrock can now be told where to look. As of October 23, 2026, the built-in web_search tool accepts up to 100 allowed domains or up to 100 blocked domains, plus an optional user location, all set inside the same OpenAI Responses API request you already send to Bedrock. For anyone building a docs assistant, a support agent, or a research agent on AWS, that turns open-web grounding into something you can actually scope.

The catch hasn't changed: it only works for OpenAI GPT models on Bedrock's bedrock-mantle endpoint, through the Responses API, in three US commercial Regions and GovCloud (US-West).

Image: Amazon Web Services, "Introducing Web Search on Amazon Bedrock for foundation model grounding" (AWS Machine Learning Blog), August 4, 2026. Source: https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-for-foundation-model-grounding/

What changed

AWS shipped two new controls on the web_search tool for Amazon Bedrock. Both are fields on the tool definition itself, so there's no new API, endpoint, or SDK to adopt.

Domain filtering. A new filters object takes allowed_domains (up to 100) to restrict results to sources you trust, or blocked_domains (up to 100) to keep specific sites out. You list bare domains without the http:// or https:// prefix, and each entry also matches its subdomains, so aws.amazon.com covers docs.aws.amazon.com.

User location. An optional user_location object of type approximate lets you pass a country, a region, a city, and an IANA time zone so results lean toward that geography. If you leave it out, location defaults to the United States. Country must be a real ISO 3166-1 alpha-2 code; AWS's docs say user-assigned codes such as UK and XK are rejected, so British users need GB.

Both controls are live in every Region where Web Search already runs: US East (N. Virginia), US East (Ohio), US West (Oregon), and AWS GovCloud (US-West).

Why this matters if you build agents

Until now, Bedrock's Web Search was a single switch. You could ground a model in Amazon's web index (or, since August 19, live web fetches), but you couldn't tell it which parts of the web counted as authoritative. That made it awkward for exactly the use cases where grounding pays off most.

Docs and support bots. A developer-docs assistant should answer from your docs, your changelog, and maybe your GitHub org, not from a three-year-old forum thread. An allow-list of a handful of domains does that without you building and maintaining a custom retrieval index.

Smaller attack surface. Every page an agent reads is untrusted input that can carry prompt-injection text. Restricting retrieval to known domains doesn't remove that risk, but it shrinks the set of pages that can reach your model. For agents that also call tools, that's a meaningful reduction in exposure.

Compliance and brand safety. A block-list lets you keep competitors, content farms, or sources your legal team has flagged out of grounded answers, which used to need post-filtering on the citations.

Local answers. Questions like regional availability, local pricing, or store hours were previously answered with a US default. Passing the user's approximate location fixes that for consumer-facing agents.

It also fits a broader pattern: cloud providers are folding the plumbing agents need (search, gateways, model routing) into the platform. We saw the same thing when Vercel added Mistral's new model to its AI Gateway on launch day, and when Google Cloud started letting Anthropic run Claude on its infrastructure. The more of that stack lives inside one provider, the more its fine-grained controls decide what you can ship.

How to use it

The example below is illustrative, adapted from the patterns in AWS's Bedrock User Guide; we didn't run it for this piece. It assumes the OpenAI Python SDK pointed at the bedrock-mantle endpoint with AWS credentials configured, as AWS's setup guide describes.

from openai import OpenAI

client = OpenAI() # base_url and auth configured for bedrock-mantle

response = client.responses.create(
model="openai.gpt-5.6-terra",
input="How do I enable Web Search in Bedrock?",
tools=[{
"type": "web_search",
"external_web_access": False,
"filters": {
"allowed_domains": ["aws.amazon.com", "repost.aws"]
},
"user_location": {
"type": "approximate",
"country": "GB",
"city": "London",
"timezone": "Europe/London"
}
}],
)
print(response.output_text)

A few practical notes. Treat the allow-list as configuration, not code: keep it in a parameter store so product or support teams can change it without a deploy. If your agent serves several tenants, build the list per tenant (each customer's docs plus your own). And keep reading the url_citation annotations in the response; the filter narrows retrieval, but the citations are still your audit trail for what the model actually used.

If you want retrieval to stay inside AWS, keep external_web_access set to false, as above. That serves results from Amazon's own web index and knowledge graph with no request data leaving the AWS boundary. The parameter defaults to true, which requires the bedrock-websearch:ExternalWebAccess IAM permission and fetches live pages.

The fine print

OpenAI models only. Web Search on Bedrock supports OpenAI GPT-5.4 and later in the commercial US Regions. In GovCloud the docs list gpt-5.6-terra, gpt-5.6-luna, and gpt-5.4. Claude, Llama, Mistral, and Amazon's own Nova models on Bedrock can't use this tool, so a Bedrock agent built on Claude still needs its own search integration.

One endpoint, one API. It's a server-side tool on the Responses API at bedrock-mantle. It isn't available through bedrock-runtime, the Converse API, or InvokeModel. If your code standardized on Converse for model portability, adopting Web Search means a second code path.

US only. Web Search is strictly regional and processes queries in-Region, and that's currently us-east-1, us-east-2, us-west-2, and us-gov-west-1. Teams with EU or Middle East data-residency requirements are still waiting.

Filters aren't a security boundary on their own. An allowed domain can still host user-generated content (think GitHub issues or community forums). Scope the list to the specific subdomains you actually trust, and keep your usual output validation on anything the agent does with retrieved text.

Display obligations. Per reporting on AWS's service terms, customers have to keep and display source citations and links in anything shown to end users. Plan your UI for citations before you plan your prompt.

How it compares with OpenAI's own web search

The new parameters follow the shape of the web_search tool in OpenAI's own Responses API, which also documents a filters object with up to 100 allowed or blocked domains and an approximate user_location. For builders, that's the most useful detail in this launch: a tool definition written against OpenAI's API should need little or no change to run against Bedrock, and vice versa. That's real portability between first-party OpenAI and Amazon Web Services, at least for GPT models.

What you get from the Bedrock side is the AWS wrapper: IAM permissions on the bedrock-websearch prefix, CloudTrail data events for every search and fetch, an option to keep retrieval inside the AWS boundary, and billing on your existing AWS account. What you give up is model choice. If you route between providers through a gateway such as Vercel AI Gateway, Bedrock's Web Search only applies to the OpenAI slice of that traffic.

What it costs

AWS bills Web Search per query, where a query is a single web search request, on top of model inference. The live figure sits on the Amazon Bedrock pricing page under Web Search; that page renders the price dynamically, so check it in your own Region. Third-party writeups from Unite.AI and Bits Lovers, both citing that pricing page, report $12.00 per 1,000 queries in the three US commercial Regions. AWS's announcement doesn't say the new controls change that rate. Prices as of October 24, 2026.

At that rate, search can cost more than the tokens it grounds on the cheaper GPT-5.6 tiers, which is the Bits Lovers writeup's main point. A tight allow-list won't change the per-query fee, but it can make each query more likely to return something usable, which matters when an agent loops and searches several times per task.

Pros and cons

Pros: no new API to learn, the same parameter shape as OpenAI's tool, up to 100 domains per list, subdomain matching, location-aware answers, and IAM plus CloudTrail controls around every search.

Cons: OpenAI GPT models only, Responses API on bedrock-mantle only, US Regions only, a per-query fee on top of tokens, and filters that narrow retrieval without making retrieved content trustworthy.

FAQ

Can I use Bedrock Web Search domain filtering with Claude?

No. Web Search on Bedrock currently supports OpenAI GPT-5.4 and later models through the Responses API on bedrock-mantle. Claude and other Bedrock models aren't on the supported list.

Can I set allowed and blocked domains at the same time?

AWS's announcement describes allowed_domains as a way to limit results and blocked_domains as a way to exclude sources, each up to 100 entries. OpenAI's equivalent documentation frames them as either-or. The safe pattern is to pick one list per request and check the Bedrock User Guide before combining them.

Do I need to include subdomains separately?

No. Each domain entry also matches its subdomains, so listing aws.amazon.com covers docs.aws.amazon.com. Leave off the http:// or https:// prefix.

Which country code should I use for the UK?

Use GB. Bedrock validates country against assigned ISO 3166-1 alpha-2 codes and rejects user-assigned codes such as UK.

Is Web Search on Bedrock available outside the US?

Not yet. It runs in US East (N. Virginia), US East (Ohio), US West (Oregon), and AWS GovCloud (US-West), and queries stay in the Region where they're issued.

Verdict

If you already run GPT models on Bedrock and use Web Search, turn on an allow-list this week for any agent with a defined knowledge domain: docs bots, internal support, and vendor-research agents. It costs nothing extra to configure, cuts the number of pages that can reach your model, and makes answers easier to defend. If you're choosing a stack from scratch, the bigger question is whether you're comfortable being tied to OpenAI models on one AWS endpoint for search. For multi-model agents, a provider-neutral search layer is still the more flexible choice, and the deployment patterns we've covered on AWS apply either way.

Sources

https://aws.amazon.com/about-aws/whats-new/2026/10/bedrock-web-search-domain-user-location/

https://docs.aws.amazon.com/bedrock/latest/userguide/web-search.html

https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-for-foundation-model-grounding/

https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-web-access-web-search/

https://aws.amazon.com/bedrock/pricing/

https://platform.openai.com/docs/guides/tools-web-search

https://www.unite.ai/amazon-bedrock-gets-built-in-web-search-for-grounded-model-responses/

https://www.bitslovers.com/amazon-bedrock-web-search-openai-gpt/