Restrict agents to approved sources with AgentCore Gateway per-request domain and date filters

Tell your agent to only read sec.gov, and it will

Regulated teams often need a simple, provable answer to one question: can my model be restricted to an approved set of sources and a defined freshness window? domain allowlists/denylists and ISO‑8601 UTC publish‑date ranges are enforced server-side by the AgentCore Gateway. That combination gives operators per-call control over which sources an agent may consult and when those sources were published.

Quick summary for leaders

What changed: Per-request filters for domains (filters.domainFilter.include and filters.domainFilter.exclude) and publication dates (filters.publishedDateFilter.from, filters.publishedDateFilter.to), using inclusive ISO‑8601 UTC timestamps.
Where they run: Enforcement happens server-side in the AgentCore Gateway and merges with admin-level connector policies so runtime filters can only narrow, never expand, administrator-defined scope.
Limits & compatibility: Each include or exclude list supports up to 100 domain entries (lists counted independently); the feature is delivered through the AgentCore Gateway and is backward compatible (filters are optional).
Regions (as shipped with this release): us-east-1, eu-west-1, ap-northeast-1. Confirm exact availability and dates in the Bedrock AgentCore Web Search v1.2.0 release notes.

How the policy layering actually works

There are two policy layers: admin-level lists you set when creating the Web Search target, and runtime lists passed per tools/call. The AgentCore Gateway enforces both. Merge logic is simple and deterministic:

Include (allowlist) lists merge by intersection, the effective allowlist is the overlap between admin and runtime includes.
Exclude (denylist) lists merge by union, anything denied by either admin or runtime lists is denied overall.

Concrete examples:

Admin include = {sec.gov, fda.gov}; Runtime include = {sec.gov, example.com} → Effective include = {sec.gov}.
Admin exclude = {malicious.example}; Runtime exclude = {tracking.example} → Effective exclude = {malicious.example, tracking.example}.

“runtime filters can narrow but never expand the scope set by an administrator.”

Teams will rely on that guarantee for compliance. Administrators set the superset of permitted sources, and runtime controls only tighten that set. For strict enforcement, configure allowed domains at the target level. Runtime filters provide API-level tightening that cannot be bypassed by the model.

Practical enforcement behavior and gotchas

If a domain filter is active, results without a recognizable domain are excluded.
If a date filter is active, results without a recognized publication date are excluded.
There are four conceptual lists in play: admin include, admin exclude, runtime include, runtime exclude, each can contain up to 100 domains.

These rules intentionally favor accuracy of source provenance over raw recall. Tighter filters will return fewer candidate documents and, when filters are strict, may return no results. That is acceptable for workflows that must certify sources (clinical, legal, financial), but it changes the user experience and error-handling needs.

Where to verify behavior and what remains ambiguous

The connector exposes clear fields and merge behavior, but several operational details are intentionally implementation-level. Before you rely on this for compliance, confirm or test these items in your environment (either via the Bedrock AgentCore Web Search v1.2.0 docs or a short proof‑of‑concept):

How the service determines a “recognizable domain” (hostname parsing, public suffix logic, canonicalization of subdomains, handling of shortened URLs and embedded content such as PDFs).
How the service recognizes a publication date (meta tags, HTTP headers, extracted text, or sitemap data) and which date formats are accepted.
Whether wildcard or pattern matching (for example, *.gov) is supported in domain lists or whether entries must be exact hostnames.
What exact logs are emitted: does the Gateway record the effective merged allow/deny lists per request in CloudTrail or Gateway logs so you can audit which sources were eligible?
Index provenance and refresh cadence: how fresh the underlying search index is and what sources are included in it.

These are operational questions you should resolve in a PoC. Where the connector promises “zero data egress, ” validate the data flow diagram and AWS documentation to confirm queries and retrievals stay within your cloud tenancy or within AWS infrastructure as required by your compliance posture.

Permissions, tooling and compatibility

Caller permission: bedrock-agentcore:InvokeGateway on the gateway ARN is required to invoke the Gateway.
Gateway service role: the Gateway’s role must have bedrock-agentcore:InvokeWebSearch so it can call the Web Search connector.
Tool naming convention: tools are named using the pattern <target-name>___WebSearch (for example, web-search-filtered___WebSearch).
SDK/CLI/Console: the filters are surfaced across AWS SDKs, the AWS CLI, the AgentCore CLI, and the Console; the filters object is optional and additive (no breaking changes).

A minimal runtime filters example (fields to pass)

When you call tools/call, include a filters object (optional). Example fields you will pass include:

filters.domainFilter.include, array of allowed domains for this call (e.g., [“sec.gov”]).
filters.domainFilter.exclude, array of domains to deny for this call.
filters.publishedDateFilter.from and filters.publishedDateFilter.to, inclusive ISO‑8601 UTC bounds (e.g., “2026-07-01T00:00:00Z” to “2026-08-04T23:59:59Z”).
maxResults, control how many search results the connector returns to the Gateway (examples showed values like 10 or 15).

Omit filters to preserve prior behavior (all indexed content eligible). If you pass runtime includes that aren’t in the admin include, they won’t expand the permitted scope; the admin include defines the superset.

Operational checklist and PoC tests

Before rolling out to regulated users, run a short proof-of-concept with the following test cases and telemetry checks:

Merge rules test: create an admin include set {sec.gov, fda.gov}. Run a call with runtime include {sec.gov, example.com} and confirm only sec.gov is eligible.
Missing metadata test: search queries that surface PDFs or syndicated content without explicit publish dates and confirm those results are excluded when date filters are active.
Top-ranked disallowed domain test: run a query that normally surfaces a high-rank WebMD or similar page; ensure it’s excluded when not in admin/runtime allowlists.
Empty-results handling: provoke a request where filters exclude all candidates and confirm service behavior, does it return an empty result set, an explicit error, or a special status? Build graceful fallbacks (human review, cached vetted artifacts) accordingly.
Audit trail test: verify which events are emitted to CloudTrail and Gateway logs, confirm that you can reconstruct the effective allow/deny lists and the returned results for each call.
Latency & regional test: call Gateway endpoints from your workload in the three supported regions (us-east-1, eu-west-1, ap-northeast-1) and compare latency and throughput for typical queries.

Design recommendations for SaaS operators

Define admin-level allowlists for legally required sources (regulatory domains, approved journals). Treat that as policy set by compliance and legal teams.
Use runtime include lists to narrow results per tenant or per session without changing the admin policy.
Record both the runtime filters you pass and the Gateway endpoint in your application logs so you can reconstruct what an agent was allowed to see.
Provide graceful fallbacks for empty-results scenarios: surface a controlled message to users, route to human review, or fall back to a locally cached, approved dataset.
Validate IAM least privilege for callers and for the Gateway service role before production rollout.

Tests and telemetry you should add immediately

Log the raw runtime filters payload with request identifiers and user/tenant context (obfuscate sensitive values if required by policy).
Log the Gateway’s returned results and any filter-exclusion reason metadata; if the service doesn’t provide fine-grained exclusion reasons, build an internal flag that notes when returned results count is zero under an active filter.
Implement automated integration tests that assert the effective allowlist/denylist behavior for representative tenant policies.

Key takeaways, questions you’d ask (and short answers)

Can runtime filters expand the admin-level allowed domains?

No. Runtime filters can only narrow the administrator-defined scope; they cannot expand it. The effective include is the intersection of admin and runtime includes; excludes are the union of admin and runtime excludes.
Where are these filters enforced?

Server-side by the AgentCore Gateway. The Gateway merges admin and runtime rules and applies them before results enter the model context window.
What happens to results without a domain or publication date?

If a domain filter is active, results without a recognizable domain are excluded. If a date filter is active, results without a recognized publication date are excluded. Confirm exact parsing behavior in a PoC because heuristics (PDFs, syndicated pages) vary.
How big can my domain lists be?

Each include or exclude list supports up to 100 domains, counted independently. Confirm whether wildcards or pattern matches are supported and whether that 100‑entry limit applies per list in the official connector docs.
Which regions support Web Search runtime filtering today?

As shipped with this release: us-east-1 (N. Virginia), eu-west-1 (Ireland/Dublin), and ap-northeast-1 (Tokyo). Verify current availability and dates in the Bedrock AgentCore Web Search v1.2.0 release notes.
What IAM permissions are needed?

The caller needs bedrock-agentcore:InvokeGateway on the Gateway ARN. The Gateway’s service role needs bedrock-agentcore:InvokeWebSearch to call the Web Search connector.
Are these changes backwards compatible?

Yes, the filters object is optional and this release is additive; existing code that omits filters continues to see the previous behavior.

Next steps, a 30/60/90 day playbook

30 days: Run a focused PoC: exercise merge rules, missing-metadata behavior, and empty-results handling. Confirm CloudTrail and Gateway logs capture enough context for audits.
60 days: Integrate runtime filter passing into your agent code, add telemetry, and set up automated tests that assert compliance for representative tenant policies.
90 days: Roll out to a limited set of regulated tenants with human-in-the-loop fallbacks, document operational runbooks, and validate with legal and compliance teams that your evidence and logs meet contractual requirements.

A practical governance note

Server-side enforcement via the Gateway is much stronger than prompt-level controls because it cannot be bypassed by a model that ignores instructions. That makes this feature useful for teams that must prove where a model drew its evidence. Still, policy and enforcement are only the start. Logging, monitoring, and fallback UX determine whether the control actually limits legal exposure. As one release example puts it, when configured for strict sources, “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.” Validate that claim end-to-end in your environment before relying on it for compliance.

Authors credited on the release include Gaurav Deshmukh, Mike Erickson, Kalyan Garimella, and Omar Abdelwahab; the feature ships as Web Search connector v1.2.0 and is delivered through the AgentCore Gateway and MCP-compatible tooling. For connector-level schema, limits, and the definitive statement on zero‑egress and regional availability, consult the Bedrock AgentCore Web Search v1.2.0 release notes and API reference in AWS documentation.