Before touching any technical detail, understand why this feature exists.
AI agents search the web to ground their answers in real information. But without controls, an agent might:
| Problem | Real Consequence |
|---|---|
| Cite an unvetted blog for financial advice | Compliance violation |
| Use 3-year-old pricing data | Customer gets wrong information |
| Pull from crowdsourced commentary | Material error in earnings report |
| Mix sources across tenants | BAA or contract violation |
The agent cannot be trusted to self-filter. System prompts can instruct a model to avoid certain sources, but the model can still ignore those instructions. Hard enforcement must happen at the API/server level.
There are exactly two filter categories introduced in connector version 1.2.0.
Controls which websites results can come from.
filters.domainFilter
| Field | What It Does |
|---|---|
filters.domainFilter.include | Allowlist — only return results FROM these domains |
filters.domainFilter.exclude | Denylist — suppress results FROM these domains |
Key Limits:
Controls how recent results must be.
filters.publishedDateFilter
| Field | What It Does |
|---|---|
filters.publishedDateFilter.from | Earliest allowed publication date (inclusive) |
filters.publishedDateFilter.to | Latest allowed publication date (inclusive) |
Key Rules:
2026-04-01T00:00:00Z)from, just to, or bothOmitting either filter preserves existing behavior — all indexed content remains eligible.
This is the most conceptually important part. There are two levels of filtering:
Level 1: Admin-level policy (set when creating/configuring the connector)
Level 2: Runtime filters (set per API call, per request)
Runtime filters can NARROW but NEVER EXPAND the admin policy.
An API caller cannot search a domain the admin hasn't approved. An API caller cannot unblock a domain the admin has blocked.
Only domains present in both the admin list and the runtime list are searched.
Admin allows: [a.com, b.com, c.com]
Runtime includes: [b.com, c.com, d.com]
Effective allowlist = INTERSECTION = [b.com, c.com]
d.com is silently dropped — not in admin list
A domain blocked at either level stays blocked.
Admin blocks: [x.com]
Runtime excludes: [y.com]
Effective denylist = UNION = [x.com, y.com]
INCLUDE (allowlist):
Admin ∩ Runtime = Effective
[a,b,c] ∩ [b,c,d] = [b,c] ← d is dropped
EXCLUDE (denylist):
Admin ∪ Runtime = Effective
[x] ∪ [y] = [x,y] ← both are blocked
When your agent sends a filtered search request, here is exactly what happens server-side:
Step 1: Agent sends tools/call with query + filters
↓
Step 2: Gateway merges runtime filters with admin policy
(intersection for include, union for exclude)
↓
Step 3: Filtered query executes against web index
↓
Step 4: Raw results are checked for compliance
↓
Step 5: Only verified results return to agent
Everything is server-side. There is:
When filters are active, the system prioritizes precision:
You may receive fewer results, but every result you receive satisfies your filter criteria.
Here is the structure of a tools/call payload with filters applied:
{
"query": "your search query here",
"maxResults": 10,
"filters": {
"domainFilter": {
"include": ["sec.gov", "investor.gov"],
"exclude": ["reddit.com"]
},
"publishedDateFilter": {
"from": "2026-04-01T00:00:00Z",
"to": "2026-06-30T23:59:59Z"
}
}
}
| List | Set By | Max Entries |
|---|---|---|
| Admin include | Admin at connector creation | 100 |
| Admin exclude | Admin at connector creation | 100 |
| Runtime include | Developer per API call | 100 |
| Runtime exclude | Developer per API call | 100 |
Now test your understanding against real use cases.
Requirements:
sec.govSolution:
"filters": {
"domainFilter": {
"include": ["sec.gov"]
},
"publishedDateFilter": {
"from": "2026-06-01T00:00:00Z",
"to": "2026-06-30T23:59:59Z"
}
}
What happens: Runtime sec.gov intersects with admin allowlist. If sec.gov is in the admin list, it is searched. If not, it is silently dropped.
Requirements:
Solution:
"filters": {
"domainFilter": {
"include": ["fda.gov", "nih.gov", "clinicaltrials.gov"]
}
}
Key insight: Even if WebMD ranks #1 for the query, it never enters the model's context window.
Requirements:
Solution:
"filters": {
"publishedDateFilter": {
"from": "2026-06-17T00:00:00Z"
}
}
Key insight: That highly-ranked analysis from last quarter never reaches the model.
Requirements:
Solution: One shared gateway target. Apply tenant-specific filters dynamically at runtime per API call.
Healthcare tenant call → include: [pubmed.ncbi.nlm.nih.gov, cdc.gov]
Legal tenant call → include: [law.cornell.edu]
Finance tenant call → include: [sec.gov, federalreserve.gov]
Key insight: One infrastructure, 200 different enforced policies.
| Region | Code |
|---|---|
| US East (N. Virginia) | us-east-1 |
| Europe (Ireland) | eu-west-1 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
Search queries stay within AWS infrastructure. They are not sent to a third-party search engine or routed outside AWS.
This matters for regulated industries (healthcare, finance, government) because it removes an entire category of compliance review.
To use runtime filtering:
UpdateGatewayTarget)bedrock-agentcore:InvokeGateway on the gateway ARNbedrock-agentcore:InvokeWebSearch<target-name>___WebSearch┌─────────────────────────────────────────────────────────┐
│ DOMAIN & DATE FILTERS — SUMMARY │
├─────────────────────────────────────────────────────────┤
│ TWO FILTER TYPES │
│ • domainFilter (include/exclude, up to 100 each) │
│ • publishedDateFilter (from/to, ISO-8601 UTC) │
├─────────────────────────────────────────────────────────┤
│ TWO POLICY LEVELS │
│ • Admin level (set at connector creation) │
│ • Runtime level (set per API call) │
├─────────────────────────────────────────────────────────┤
│ COMBINATION RULES │
│ • Include lists → INTERSECTION (narrower wins) │
│ • Exclude lists → UNION (more blocked wins) │
│ • Runtime can NEVER expand admin scope │
├─────────────────────────────────────────────────────────┤
│ ENFORCEMENT │
│ • 100% server-side │
│ • No client-side loops or post-processing │
│ • Precision over recall when filters active │
├─────────────────────────────────────────────────────────┤
│ ARCHITECTURE │
│ • Zero data egress — stays within AWS │
│ • Available: us-east-1, eu-west-1, ap-northeast-1 │
│ • Requires connector version 1.2.0 │
└─────────────────────────────────────────────────────────┘
Test yourself before moving on:
x.com and runtime tries to remove it from the exclude list, what happens?publishedDateFilter?Answers: (1) Silently dropped. (2) It stays blocked — runtime cannot unblock admin denials. (3) ISO-8601 UTC. (4) They are excluded. (5) Yes to both — all filters are optional and independent. (6) 400 (4 lists × 100 each). (7) The model can ignore prompt instructions; API-level enforcement cannot be bypassed by the model.