AWS recently added an external_web_access parameter to Web Search on Amazon Bedrock. It looks almost trivial: a boolean, defaulting to true.
But the interesting part isn't the default by itself.
AWS has paired that parameter with a separate IAM permission, bedrock-websearch:ExternalWebAccess, so external web access only becomes possible when both controls allow it.
That makes this less a story about an unsafe default and more an interesting example of where application configuration and cloud permissions meet. One flag says what the application is asking for. IAM decides whether the infrastructure is allowed to do it.
For systems handling sensitive data, that's a design decision worth making deliberately before you ship, not discovering during a post-incident retrospective.
This piece is about that small flag, the permission sitting behind it, what they actually do, and why the choice deserves a conversation before production.
When you use Web Search on Amazon Bedrock, external_web_access controls whether Bedrock is permitted to go beyond its own web index and cache to access the live external web.
Set external_web_access to false, and Web Search is served entirely from the Amazon Bedrock web index and cache. AWS states that request data does not leave the AWS boundary for retrieval.
Leave it at true, which is the API default, and Bedrock is permitted to use external web access only if the identity making the request also has the bedrock-websearch:ExternalWebAccess IAM permission.
With both controls enabled, Bedrock may access the live public web when necessary. In that configuration, AWS explicitly warns that request data may leave the AWS boundary.
Those two controls work together.
The parameter expresses intent. IAM controls whether external access is actually authorised.
That's the mechanical difference. The implications, though, are not small.
There is another residency boundary worth knowing about. At the time of writing, Bedrock Web Search is available in the US East (N. Virginia), US East (Ohio), and US West (Oregon) Regions. AWS states that each Region operates its own search and fetch tier and that queries and results are not routed between those Regions.
Source: Amazon Bedrock Web Search documentation
Defaults are trust.
When a developer integrates a new API, they trust that the default configuration is a reasonable starting point for most workloads. AWS has generally earned that trust, but "reasonable for most workloads" and "appropriate for your specific security and compliance context" are not the same thing.
There is an important safeguard here: external_web_access: true does not override IAM.
AWS requires the separate bedrock-websearch:ExternalWebAccess permission before external access can occur, and general Bedrock permissions such as AmazonBedrockFullAccess do not automatically include it.
That's good security design.
But it doesn't remove the application's responsibility to make an explicit decision.
If you're building a customer-facing AI feature and your users may ask questions containing personal data, confidential business information, health information, internal identifiers, or anything else you would rather not expose beyond your intended AWS boundary, then whether external web access is permitted is not a neutral implementation detail.
It's part of your data architecture.
And because external_web_access is supplied with the request, the decision ultimately lives in your application logic as well as your IAM configuration.
Don't use an IAM denial as your application configuration.
If the application is supposed to remain inside AWS, say so explicitly in both places: set external_web_access to false, and don't grant bedrock-websearch:ExternalWebAccess.
That is considerably easier to reason about six months later than an application continually requesting external access and relying on IAM to stop it.
AWS requires an explicit IAM permission to allow external web access:
bedrock-websearch:ExternalWebAccess
This is the right design.
General access to Bedrock isn't enough. The identity has to be granted the ability to cross this particular boundary separately.
That gives security teams an infrastructure-level control even if an application developer leaves external_web_access at its default value.
AWS also provides separate managed-policy options around Web Search with and without external access, reinforcing the distinction between access to the search capability itself and permission to reach beyond the AWS boundary.
In practice, though, permissions have a habit of expanding during development.
Teams moving quickly may grant a broader policy to get something working, intending to revisit the scope later. Granting the permission isn't the problem. Granting it without understanding what it enables, without a documented reason, and without the corresponding application configuration being reviewed is where the exposure begins.
In my experience, some of the most consequential security gaps in production systems are not the obvious ones.
They're the permissions that got granted during a sprint, with the intention of revisiting the scope later, and never got revisited.
There is an important warning in AWS's own documentation that deserves more attention than the boolean itself.
When external web access is enabled, AWS warns about the potential for data exfiltration.
The problem is not merely that a legitimate search query might contain sensitive information. An agent or model with access to external retrieval could potentially construct a URL or external request containing information from its context and attempt to send that information outside the AWS boundary.
AWS therefore recommends disabling external web access when working with sensitive data.
That changes the way I think this feature should be discussed.
The important security point isn't that external web access is inherently bad. It's that AWS itself treats it as a potential data-exfiltration boundary.
Live web access can be enormously useful. In some applications it is the entire reason Web Search exists.
But once a system is allowed to communicate with the public internet, that capability becomes part of your threat model.
That's true whether the system happens to contain an LLM or not.
I'm a developer, not a lawyer, and nothing here is legal advice. Treat what follows as professional interpretation. If you operate in a regulated sector, your legal and compliance teams need to be part of this conversation.
That said, here's how I read the flag's implications across some of the regulatory frameworks most likely to affect teams building these systems.
If personal data can appear in prompts or in web requests derived from those prompts, permitting external access adds another potential data-flow boundary that should be assessed under your GDPR obligations.
Depending on how the service is used, that can affect your records of processing, processor arrangements, international-transfer analysis, security controls, and privacy notices.
Article 32 of the GDPR requires appropriate technical and organisational measures proportionate to the risks involved in processing personal data. Other GDPR principles, including data minimisation and data protection by design and by default, can also become relevant to the architectural decision.
external_web_access: true is not remotely a GDPR violation by itself.
The relevant question is whether you understand where personal data can go, have an appropriate basis for the processing, and have designed controls proportionate to the risk.
If your application doesn't need external access to fulfil its purpose, deliberately keeping that path closed is considerably easier to explain than discovering later that it was available simply because nobody considered the configuration.
See: GDPR Article 32
For applications subject to HIPAA, the concern is not that any external transmission automatically constitutes a breach.
Covered entities and business associates routinely use cloud services lawfully when appropriate Business Associate Agreements and safeguards are in place.
The architectural question is whether permitting live external web access could cause electronic protected health information to be disclosed to a destination that is not part of the approved HIPAA data flow.
If that can happen, the issue becomes considerably more serious.
A patient or clinician can put sensitive information into a conversational interface whether or not your product specification tells them to. Symptoms, medications, names, appointment information, or copied clinical notes can all appear in prompts.
For healthcare workloads, that makes AWS's own warning about potential data exfiltration particularly relevant.
The correct question isn't simply:
"Does this application use HIPAA-compliant AWS infrastructure?"
It is:
"Where can PHI actually travel once it enters this application?"
Those are not necessarily the same question.
See: HHS guidance on HIPAA and cloud computing
India is now well beyond the draft-rules stage.
The Digital Personal Data Protection Rules, 2025 were notified in November 2025, with different provisions of the Act and Rules coming into force on a phased timetable.
For product teams, that makes architecture decisions around unnecessary data movement worth documenting now rather than treating them as something to revisit when the remaining obligations commence.
The exact compliance implications depend on the product, the data involved, the parties processing it, and which provisions are in force and applicable at the relevant time.
But the architectural principle is much simpler.
If external web access isn't required for the product to work, keeping that retrieval path inside AWS is a much easier design choice to explain than discovering later that sensitive prompts were permitted to reach the public internet simply because nobody considered the configuration explicitly.
See: MeitY — Digital Personal Data Protection Rules, 2025
true is genuinely the right answerNone of this is an argument for always setting external_web_access to false.
There are real applications where live web retrieval is the entire point, and where the additional capability justifies opening that boundary.
AWS's own examples are illustrative: sports scores, live pricing, and newly published documentation.
I'd add to that list:
For these applications, disabling external access simply to say everything stayed inside AWS may make the product materially worse.
That isn't good security architecture either.
Security is not the art of disabling everything that could theoretically introduce risk. It is deciding which capabilities the product actually needs, understanding the risks they introduce, and controlling them appropriately.
In my view, the right question isn't:
"Should this ever be true?"
It's:
"Have we made an active decision about it, and can we defend that decision?"
A true value that someone thought about, reviewed, and documented is categorically different from a true value that's simply the default nobody noticed.
When Ascentspark builds on Bedrock, external_web_access is the kind of parameter we flag for an explicit decision before the first staging deployment.
Not because it's always a problem.
Because it's the kind of decision that should be made with the product owner and the client's security and compliance context in mind, rather than defaulted into by whoever was fastest to copy the API example.
Our working framework is simple enough to apply quickly:
What data can realistically appear in user queries for this product?
Think about the worst-case query, not only the intended one. Users will ask off-topic questions. They'll paste documents into chat windows. They'll include names, account details, patient information, internal project names, and things the requirements document never predicted.
The query surface is wider than the product spec.
Does the product actually need live external web access?
If the Amazon Bedrock web index and cache serve the use case, there may be no reason to permit another egress path.
If false works, use false.
If true is the right answer, why?
Document it.
Add the bedrock-websearch:ExternalWebAccess permission grant to the architecture decision record and note why the capability is required.
Don't merely record that the permission exists. Record the reason it exists.
Do the application and IAM configuration agree?
If external access isn't intended, explicitly set external_web_access: false and withhold the IAM permission.
If external access is intended, make sure the application enables it only in the paths that genuinely require it.
Defence in depth works better when both layers express the same intent.
Is the resulting data flow visible to the right stakeholders?
If the design permits user-derived data to reach the external web, make sure that behaviour is reflected wherever your privacy, security, compliance, and contractual documentation requires it.
The implementation flag itself doesn't need to become legal copy.
The data flow it enables may need to.
This isn't a heavyweight process.
It takes minutes in a design review.
The alternative — explaining to a client six months after launch why their application was capable of sending query-derived data outside the AWS boundary when they assumed it wasn't — takes considerably longer.
There's a category of technical decision that causes disproportionate downstream problems, not because it's complex, but because it's invisible.
external_web_access is a good example.
One boolean. One IAM permission. A surprisingly meaningful architectural boundary.
And, to AWS's credit, the controls are there.
AWS gives you an in-boundary retrieval path. It separates external web access into its own IAM permission. General Bedrock access doesn't automatically grant that permission. The documentation explicitly warns about the possibility of data exfiltration and recommends disabling external access for sensitive workloads.
AWS has done much of the infrastructure work correctly.
The remaining question belongs to us as architects and developers:
What should our application actually be allowed to do?
That decision shouldn't live accidentally in an API default, and it shouldn't live accidentally in an IAM policy copied from a development environment.
It should be explicit in both.
Because application configuration expresses what the software intends to do, while IAM expresses what the infrastructure will permit it to do.
When those two agree, you have something considerably more useful than a boolean.
You have a boundary.
And boundaries are worth deciding before you ship.
The regulatory references in this article describe general frameworks and are not legal advice. Privacy, security, data-protection, and healthcare compliance obligations depend on the product, jurisdiction, architecture, contracts, and data involved. Take qualified legal advice for systems handling regulated or sensitive information.
Amazon Bedrock's Web Search external_web_access parameter defaults to true, but that alone does not enable access to the live external web. The caller must also have the separate bedrock-websearch:ExternalWebAccess IAM permission. With external access disabled, retrieval stays within the Amazon Bedrock web index and cache; when external access is authorised, AWS warns that request data may leave the AWS boundary and identifies a potential data-exfiltration risk. For sensitive workloads, the safest architecture is to make the decision explicit in both application configuration and IAM rather than relying on either layer alone.
external_web_access: true actually mean for my users' data?Setting external_web_access to true permits external web access only when the identity making the request also has the bedrock-websearch:ExternalWebAccess IAM permission. With both controls enabled, Bedrock may access the live public web, and AWS warns that request data may leave the AWS boundary. Setting the parameter to false keeps Web Search retrieval within the Amazon Bedrock web index and cache.
external_web_access: true automatically give Bedrock access to the external web?No. The parameter and IAM permission work together. The request must permit external access and the caller must have bedrock-websearch:ExternalWebAccess. General Bedrock access does not automatically grant this permission.
Use defence in depth. Explicitly set external_web_access: false in the application and do not grant the bedrock-websearch:ExternalWebAccess IAM permission to the application's identity. This makes the intended behaviour clear at both the application and infrastructure layers.
IAM provides an important security boundary, but it shouldn't substitute for correct application configuration. If the application doesn't intend to use external access, explicitly setting the parameter to false makes that intent clear and avoids having the application continually request a capability that infrastructure is expected to deny.
Yes, although the consequences may be different. Confidential business information, customer data, internal identifiers, source material, and other information can appear in prompts even outside regulated sectors. Understanding whether query-derived information can leave your cloud boundary is a basic security and privacy architecture question.
false and not enabling Web Search at all?With Web Search enabled and external_web_access: false, Bedrock can still use the Amazon Bedrock web index and cache for retrieval while keeping the request inside the AWS boundary. If Web Search isn't enabled at all, that retrieval capability isn't available to the model.
external_web_access: true a GDPR or HIPAA violation?No. External web access is not inherently a violation of either framework. The compliance implications depend on what data is processed, where it can go, the roles and agreements between the parties, the safeguards in place, and the applicable legal requirements. The architectural concern is that enabling external access creates another potential data-flow boundary that needs to be understood and governed.
A system permitted to access the external web may potentially construct requests containing information from its context and send that information outside the AWS boundary. AWS therefore identifies external web access as a potential data-exfiltration risk and recommends disabling it when working with sensitive data.
The current behaviour, IAM requirements, security considerations, and regional availability are documented in the Amazon Bedrock Web Search documentation. Because cloud services evolve, check the current AWS documentation rather than relying solely on the behaviour described in this article.
