AWS Daily Intelligence #61 - A domain allow-list is not an egress control

Web Search on Bedrock can now be pointed at a list of domains you trust, or away from a list you do not. It is a useful grounding control and it is worth being precise about what it controls, because a different pair of settings decides whether the external web is reached at all.

“Using the filters parameter, you specify up to 100 allowed_domains to limit results to trusted sources, or up to 100 blocked_domains to exclude sources you don't want.”

Executive summary

Two controls, both on the tool rather than on the model: “Web Search on Amazon Bedrock now supports two new controls that give you more precision over the results that ground a model's response: domain filtering and user location. Both are configured directly on the web_search tool in your existing OpenAI Responses API request.”

Read that scoping carefully. The new controls shape which results come back. Whether a request can leave AWS at all is governed by two older settings that have to agree with each other, and an allow-list is not one of them.

What changed

Domain filtering gives you a two-sided list, capped at 100 entries on each side, and AWS describes the two use cases plainly: “This is useful when you want responses grounded only in specific sites, or when you need to keep certain domains out of results.”

User location is the softer of the two: “With user location, you can optionally specify location parameters so that Web Search can return results relevant to that geography. This helps with location-dependent questions, such as regional availability or local services.”

Availability is the existing Web Search footprint: “US East (N. Virginia), US East (Ohio), US West (Oregon), and AWS GovCloud (US-West)”.

Architecture

Web Search is two operations, and only one of them can ever reach the public internet.

“Search — Returns titles, URLs, and snippets from the Amazon Bedrock web index and knowledge graph for high-confidence facts.” And, unambiguously: “Search is always served from the Amazon Bedrock web index.”

“Fetch — Retrieves page content for a specific URL. With external_web_access set to false, Fetch uses the Amazon Bedrock cache only. With the parameter set to true and the required IAM permission granted, Fetch checks the cache first and accesses the external web only on a cache miss.”

The new controls shape which results ground the answer. A different pair decides whether anything leaves AWS.

The external-web gate has two conditions, and both must hold

AWS states this three separate times on the same page, which is usually a sign it gets misread.

Where	What it says
Overview	“Retrieval from the external web occurs only when both* your request and your IAM permissions allow it.”*
How it works	“The `external_web_access` parameter in the Responses API and* the `bedrock-websearch:ExternalWebAccess` IAM permission govern whether Fetch can use the external web after a cache miss.”*
Enable external web access	“External retrieval takes effect only when you both* grant the permission and leave the parameter enabled.”*

The parameter alone does nothing. The permission alone does nothing. Which makes this a genuine two-party control: a platform team can hold the IAM half and an application team the request half, and neither can turn on external retrieval by itself.

Why the allow-list is not the egress control

AWS is direct about the risk, and about the remedy:

“Note that setting external_web_access to true introduces data exfiltration risk. An agent could encode query data into a URL and then attempt to fetch that URL from the external internet. When you work with sensitive data, set external_web_access to false to prevent data reaching the external internet.”

The remedy AWS names is the parameter. Not a domain list. That distinction is the reason to be careful about how domain filtering gets described internally: it constrains which sources are allowed to ground an answer, which is a quality and trust control. The question of whether request data can reach the internet is settled before the filter is relevant.

Also worth reading plainly: “When Fetch reaches the external web, your request data may leave the AWS boundary.”

Business value

Grounding quality is the real win. A model answering from a hundred domains you chose is a different product from one answering from the open web, particularly for regulated or house-style content where the acceptable sources are a known list. The 100-entry cap on each side is generous for a curated list and tight for anything resembling a category.

User location addresses a specific failure: an answer that is correct somewhere else. For “regional availability or local services” questions that is often the whole bug.

Security considerations

The posture AWS recommends for sensitive data is explicit and it is not a filter: external_web_access set to false. In that configuration Search still works from the Bedrock index and Fetch still works from the cache, so you keep most of the capability without the boundary crossing.

One detail to check rather than assume, because the names suggest otherwise: “The simplest managed-policy path is to attach either AmazonBedrockExternalWebSearchReadOnly or AmazonBedrockExternalWebSearchFullAccess. The current versions of these policies grant the same three Web Search actions on the same resources, so either policy enables external retrieval.”

So picking the read-only policy is not a weaker grant for this purpose. AWS says so itself, and the hedge “current versions” is doing work — it is true today and is the kind of thing that changes.

Codex is the worked example of the safe posture: “Codex sets external_web_access to false on each request, so your request data stays within the AWS boundary.”

Cost considerations

The announcement points at the Bedrock pricing page rather than naming a charge for the new controls, and there is nothing on the documentation page that prices filtering separately. So neither source says whether filtering changes what a request costs. Price it from the pricing page against your own measured call volume rather than from either page’s silence.

Operational considerations

Two things that will cost someone an afternoon.

First, the endpoint: “Web Search is a server-side tool, so it isn't available when you call the Responses API on the bedrock-runtime endpoint. To use it, call the Responses API on bedrock-mantle.”

Second, invocation is the model's choice: “The model uses the tool only when it determines the request needs current information.” You add the tool to the tools array; the model decides whether to call it. So your filters apply to the searches the model chose to run. An allow-list is not a guarantee that a search happened, only a constraint on one that did.

And the baseline permissions are separate from the external-access one: “The IAM identity behind your API key must be allowed to call the Web Search actions bedrock-websearch:InvokeSearch and bedrock-websearch:InvokeFetch.”

Tradeoffs

Choice	What you gain	What it costs
`allowed_domains`	Answers grounded only in sources you vetted	Capped at 100; a question outside the list grounds poorly or not at all
`blocked_domains`	Keeps known-bad sources out without enumerating the good ones	Also capped at 100, and it is a denylist — it cannot anticipate
`external_web_access: false`	AWS's own recommendation for sensitive data; request data stays in the boundary	Fetch is limited to the Bedrock cache, so a cache miss returns nothing fresh
`external_web_access: true`	Fetch can reach pages the cache does not hold	“introduces data exfiltration risk”, in AWS's own words

Implementation guidance

Decide external_web_access first, before thinking about filters. It is the setting that determines whether request data can leave AWS, and AWS's advice for sensitive data is false.
Treat the parameter and the IAM permission as a two-party control. Record which team owns each half, because external retrieval needs both and either side can withdraw it alone.
Use domain filtering for grounding quality, and do not describe it in a design document as a data boundary.
Check which managed policy you attached. The read-only and full-access policies currently grant the same three actions on the same resources.
Confirm you are on bedrock-mantle. On bedrock-runtime the tool is simply unavailable.

Best practices

Keep the allow-list well under 100 so it can grow without a rewrite.
Prefer an allow-list to a denylist where the acceptable sources are knowable; a denylist cannot anticipate a new domain.
Set user location explicitly for anything regional rather than relying on a default.
Use the citations in the response to audit what actually grounded an answer — they are the evidence that the filter did what you intended.

Who should adopt this and when

Now, if you already run Web Search and have an opinion about which sources should ground an answer. Both controls sit on a request you are already making.

Now, if a review blocked Web Search on source quality. An allow-list is a concrete answer to the question of which sites the model may read, in a way that was not previously available.

Not as an answer to a data-egress review. That review is about external_web_access and the IAM permission, and AWS's documentation says so directly.

Key takeaways

Domain filtering takes up to 100 allowed_domains or up to 100 blocked_domains on the filters parameter, with user location alongside it.
Search is always served from the Bedrock web index. Only Fetch can reach the external web, and only on a cache miss.
External retrieval requires the external_web_access parameter and the bedrock-websearch:ExternalWebAccess permission. Either alone does nothing.
AWS names the exfiltration risk and names the parameter as the remedy — not a domain list.
The read-only and full-access external-search managed policies currently grant the same three actions.
Web Search is server-side, so it requires the bedrock-mantle endpoint.