AWS Bedrock AgentCore Can Now Filter Its Own Web Search
On August 19, AWS added domain and published-date filtering to Web Search on Amazon Bedrock AgentCore, plus expanded the tool to Europe (Ireland) and Asia Pacific (Tokyo). Last week we covered AgentCore's new long-running Runtime Instances. This is a different corner of the same service, so if you're building or maintaining agents on AWS, it's worth a few minutes of your time either way.
What changed
Web Search on AgentCore launched back in June as a managed tool that lets an agent pull live, cited web results without that traffic ever leaving your AWS account. It's built on Amazon's own search infrastructure (the same stack behind Alexa+ and Kiro), and it returns snippets, source URLs, titles, and publish dates the model can reason over.
The August update adds two controls that were missing at launch. Agents can now pass include and exclude domain lists directly in each tool call, up to 100 domains per list, so a single call can restrict itself to only .gov and .edu sources, or block a specific site entirely. They can also filter by published-date range, so a research or compliance agent can enforce "results from the last 90 days only" instead of trusting the model to eyeball dates on its own. Admins get a gateway-level allowlist too, so those restrictions can be enforced centrally instead of per-request.
Introducing The First Agentic CRM
Get revenue agents, workflows, and automations across every stage of your motion. Access customer data in real time through Attio's web app, MCP, API, and SDK.
Then Ask Attio anything about your business and get instant answers.
It's the CRM that runs the work behind every win.
Why it matters
Grounding an agent in live web results only helps if you can also control what "live" means. Before this update, if you wanted your agent's outputs restricted to trusted sources or a specific time window, you had to build that filtering yourself, either in a prompt (unreliable) or by wrapping the tool call in your own logic. Now it's a native parameter.
This matters most if you're building anything regulated: a compliance agent that can only cite sources from the last quarter, a legal research tool that should never pull from forums or blogs, or a customer-facing agent whose employer wants zero risk of citing a competitor's site. Those are exactly the guardrails that get asked for the moment an agent goes from "cool demo" to "shipped feature," and until now they weren't built in.
The regional expansion matters too if you have EU or APAC data residency requirements. Web Search was US East (N. Virginia) only at launch. It now also runs in Europe (Ireland) and Asia Pacific (Tokyo), which removes one more reason an EU-based team couldn't use it.
What to do with this
If you're studying for or hold a Bedrock-adjacent cert (AWS Certified AI Practitioner, AWS Certified Machine Learning Engineer, or the newer agentic-focused material), it's worth reading through the AgentCore Gateway docs for how domain and date filters get set at the tool-call level versus the gateway level. That distinction, per-request control versus admin-enforced policy, comes up constantly in real agent architecture, not just on AWS.
If you're actually building agents right now, even a side project, try wiring a domain allowlist into one tool call this week. It's a small change, but it's the kind of thing that separates "I called an LLM API" from "I understand how to put guardrails on an agent," and that's increasingly the bar interviewers are checking for.
Keep Learning and Building.
