An agent can narrow its own web search, but never widen it
Narrow only, never wider
Your agent can search the web. You write in the prompt: only use sec.gov and the big financial wires. It usually listens. The times it does not are the times you learn that a line in a prompt is a request, not a rule.
On 19 August AWS added site filters to the web search tool in Bedrock AgentCore. Small feature. But the way it handles a disagreement is worth knowing, because that is what makes it a guardrail instead of a note.
This is AWS's own documentation of an AWS service, quoted here. It does not run on our infrastructure and we have not tested it. The design is what interests us.
What you get
Two filters. A list of sites to allow and a list to block, plus a date range for when a page was published.
The agent can pass them in the search call itself:
{
"method": "tools/call",
"params": {
"name": "WebSearch",
"arguments": {
"query": "latest SEC enforcement actions 2026",
"filters": {
"domainFilter": { "include": ["sec.gov"], "exclude": [] },
"publishedDateFilter": {
"from": "2026-07-01T00:00:00Z",
"to": "2026-08-04T23:59:59Z"
}
}
}
}
}
An admin sets the same kind of list on the gateway instead, where the agent cannot see or change it. Each list holds up to 100 sites.
The rule
So the admin has a list and the agent has a list. What happens when they disagree?
Allow lists are intersected. Block lists are combined. "Runtime filters can narrow but never expand the scope set by an administrator."
The admin's list is the ceiling. The agent can ask for less, never more. And anything either one blocks stays blocked.
Turn it around and you see why it matters. If the two allow lists were simply added together, the admin's list would be a starting suggestion. An agent that wanted some other site could just name it in its own call and get it. The filter would be paperwork.
That is the difference between the two places you can put a rule. Asking a model to stay inside a boundary means asking it to remember, halfway through a job, after reading who knows what. A gateway comparing two lists is not remembering anything.
The date filter is the sneaky one
The site list gets the attention. The date range may matter more.
An old page does not look old. A four-year-old page about a tax rule or a dead API reads exactly like a current one — same confident tone, and now with a citation stapled to it, which makes a wrong answer more convincing rather than less. The model cannot judge how fresh a page is when nothing tells it. Setting a window gives it a fact it otherwise never had.
The catch
Search costs $7 per 1,000 queries and runs in three regions. AWS's selling point is that the queries stay inside their network — "without sending user prompts and retrieval queries to external search API providers outside of AWS." Good if you already live in AWS. Mostly irrelevant if you do not.
The idea travels, though, because the tool is reached over MCP: "Web Search uses a built-in connector target on Bedrock AgentCore Gateway using the Model Context Protocol (MCP)." Nothing about allow lists intersect, block lists combine, the agent can only narrow needs Amazon. Any gateway can do it, for any tool — which files something may read, which hosts it may reach, which tables it may query.
So the question to ask about a tool is not whether you can restrict it. It is where the restriction lives, and whether the agent can move it.
We went through the protocol under all this in MCP's biggest update, and gave a model live search without a managed service in web search on WEC Inference. The next tutorial in the agent series puts an agent's tools behind a gateway that decides what it may call.