How is restricting sources different from training the assistant on my own data?

Connecting an assistant to your own documents makes it answer from your knowledge, which is the first and most accurate option. Source restriction covers the other case: when you have no internal answer and the assistant must look outside, you decide where it looks instead of leaving it the whole internet. The two are used together, not as alternatives.

Do I need Amazon's platform specifically to do this?

No. The idea is broader than the platform. Any assistant you build can be given an allowed source list and a recency requirement, either through a built-in platform feature or a layer you write in the application itself. What matters is that the decision is written down and reviewable rather than left to the model.

How many official sources should be on the list?

There is no correct number, but a short reviewed list beats a long neglected one. Start with the authorities that genuinely relate to your activity and to your customers' recurring questions, then add as needed. A list nobody revisits every few months eventually becomes a source of errors rather than a safeguard.

How do I know my assistant is answering from outdated sources?

By keeping a log that stores, for each answer, the link it was built on and the page date, then reviewing a sample periodically. If you have no such log, you do not know, and you will discover the problem through a customer complaint. Showing the link and date to the user inside the answer adds a second layer of protection, because it makes the user check alongside you.

Where Does Your AI Assistant Get Its Answers? Controlling Sources and Recency

On 19 August 2026 AWS announced an update to the Web Search tool in Amazon Bedrock AgentCore: an agent can now narrow results to trusted domains or block unwanted ones on a per-call basis, and constrain results to a specific time window with inclusive from and to bounds. Administrators also gained gateway-level allowlist support with a cap of up to 100 domains per list, and the tool expanded to Ireland and Tokyo after launching in North Virginia only.

It reads as a platform footnote. It is actually a large provider conceding that the important question about an AI assistant is not whether it answers, but where the answer came from and when it was written. That question belongs to every company running an assistant in front of customers or staff, on any platform.

The two flaws that ruin any assistant answering from the web

Connecting an assistant to open web search opens two doors that do not close on their own:

A source you do not trust: the model does not distinguish between an official regulatory page, a forum thread, a marketing blog and a competitor page. All of it is text. The result is your customer being told something about your own business, sourced from somewhere you neither own nor endorse.
Information that is correct but expired: this is the more dangerous one, because it does not look like an error. A page written three years ago about a requirement, a fee or a deadline, after the requirement changed. The answer is precise and confidently phrased, and correct for its year rather than yours.

The second flaw is why a date filter is not a nicety. In a market where regulations shift annually, is this from this year matters more than is this from a good site.

What this means in practice in Saudi Arabia

Take a business running an assistant that answers customer or employee questions. The queries that reach it will inevitably include regulatory matters: e-invoicing requirements, licence or contract conditions, a step inside a government platform, a clause in the labour law. Each of those has exactly one authoritative source: ZATCA, the Ministry of Human Resources and Social Development, CST, SDAIA.

An assistant that answers a tax or labour question from a general blog when it could answer from the authority's own site does not have an intelligence problem. It has a configuration problem. Defining an allowed list of sources per question type is an administrative decision you make once, not a capability you wait for a vendor to ship.

There is a second dimension that matters just as much: the data path. Whether the text of your staff and customer queries stays inside your own cloud environment or travels out to a third-party search engine is a material difference when those queries carry customer names, order numbers or contract details. Anyone building an assistant that touches personal data should know exactly where every word a user types ends up, because the Personal Data Protection Law judges you on the path, not the intent.

Three layers you actually control

Whether you are on Amazon or elsewhere, control over answer quality sits in three layers, strongest first:

Your own material first: product guides, pricing, policies, approved answers. Any question you already have an answer to should never send the assistant searching the web at all. This layer resolves the majority of real questions.
A defined list of trusted domains: for regulatory and market questions you have no internal answer to, a short written list of official sites, reviewed quarterly.
Open search bounded by date: the last resort, for general questions, with a recency constraint and the link and date always shown to the user.

The working rule: the further down you go, the higher the error probability and the more essential it is to show the source. An assistant that surfaces the authority's link and the page date turns the user into a checker. An assistant that returns a confident sentence with no source is asking for trust it has not earned.

What these controls do not fix

Domain and date filters govern where information comes from. They do not guarantee the assistant understood it or relayed it correctly. It can still read a current official page and summarise it misleadingly, or apply a general rule to a case it does not cover. Filtering shrinks the error surface; it does not remove it.

So two things remain non-negotiable: a clear handoff to a human on sensitive questions, and a log you can go back to and read what was asked, what was answered, and from which source. Without that log, you will not learn your assistant is wrong until a customer complains.

The Origami view

We read this update as a sign of maturity in the assistant market. The first phase was a race over who answers fastest and most fluently. The phase we are entering is a race over who answers from a source that can be shown and defended. That difference is precisely the difference between an impressive demo and a system you put in front of customers.

Our advice to anyone building an assistant today is to start from the bottom, not the top: collect your approved answers in one place first, then write the list of permitted official sources, then open general search last and with a date bound. Reverse that order and you get an assistant that talks a lot and cites little — worse than having no assistant, because it is wrong in your name.

Conclusion

Domain and date filtering looks like a detail inside one platform, but it points at a question that belongs to anyone running an assistant: do you know where yours answers from, and when the information behind that answer was written? If the answer is no, the problem is not the model but the setup — and the fix is an administrative decision before it is an engineering one: your material first, then a short official list, then time-bounded search with the link always attached.

Where Does Your AI Assistant Get Its Answers? Controlling Sources and Recency