AWS moves agent source-vetting into the API call with per-request web search filters

AWS has added runtime domain and published-date filtering to Web Search on Amazon Bedrock AgentCore, shipping as part of web-search connector version 1.2.0 ^[1][2]. The filters are applied per call and enforced server-side with no external orchestration required ^[3], which moves the question of which sources an agent may read out of your application code and into the request itself.

The mechanics are narrow and legible. Two capabilities appear inside the `filters` object of the Web Search tool input schema ^[4]: an include (allowlist) or exclude (denylist) domain list passed on every `tools/call` invocation, each list supporting up to 100 domains counted independently ^[5]; and a published-date restriction expressed as ISO-8601 UTC bounds ^[6]. Both are optional, and omitting them preserves the existing behaviour where all indexed content is eligible ^[7]. If both lists are populated, that is a ceiling of 200 domain entries referenced in a single call ^[8].

The governance design matters more than the parameters. AWS says runtime filters can narrow but never expand the scope an administrator has set, with admin-level domain lists established at creation ^[9][10]. That is the right ordering, and it is what makes the feature usable in a multi-tenant setting: per the announcement, a platform serving different customers can apply different domain policies per request without standing up a separate target for each tenant ^[11]. The cited enterprise cases follow the same shape, such as a compliance agent restricted to .gov domains and approved publishers rather than the open web, and a support agent limited to documentation published in the past seven days ^[12].

The request lifecycle is entirely server-side ^[13]. AWS describes the agent sending a `tools/call` with query and filters, the Gateway merging runtime filters with the admin-level policy, executing the filtered query against the web index, enforcing compliance on the raw results, and returning only verified results for grounding ^[14]. There is no client-side filtering loop, no post-processing, and no additional roundtrips ^[13]. For teams that built their own vetting layer, this is the practical consequence: the code that fetched, then discarded, then re-queried can go, and the audit question becomes what filters were on the call.

The same release expands Web Search to eu-west-1 (Dublin) and ap-northeast-1 (Tokyo) ^[15]. AWS says regional endpoints cut latency for local workloads and give an EU-based entry point for organisations with data proximity requirements, without routing traffic across the Atlantic, and that AgentCore uses a zero-egress architecture in which search queries remain within AWS ^[16][17].

What to watch. The announcement material does not describe domain matching semantics, so whether an entry covers subdomains, or how conflicting admin and runtime lists resolve beyond the narrowing rule, is not something to assume; nor does it state pricing or latency figures. Also unspecified is the empty-result path, which is the failure mode that matters most: an agent handed a tight allowlist plus a seven-day window will sometimes get nothing back, and what it does next is your problem, not the connector's. And a `.gov` allowlist is a provenance control, not a truth control. It bounds where an answer came from, which is what a regulator asks about, and says nothing about whether the retrieved page was right.