AWS opens the public web to Bedrock agents behind a single IAM parameter
On August 19, 2026, AWS added an external_web_access parameter to Web Search on Amazon Bedrock, letting agents pull content live from the public web. The lock is an IAM permission, and the default is open.
August 19, 2026. external_web_access. IAM. On August 19, 2026, AWS extended Web Search on Amazon Bedrock with a parameter named external_web_access. It lets agents pull content live from the public web — sports scores, real-time prices, freshly published documentation — instead of being limited to Amazon’s in-house web index. The lock controlling that switch is a single IAM permission, and the default setting is open.
It is a governance decision disguised as a feature. For teams deploying agents in regulated environments, everything hinges on understanding this parameter and its default.
One grounding tool, two modes
Web Search on Amazon Bedrock is the managed server-side tool that “grounds” a model’s responses in current web knowledge with zero data egress from the customer’s AWS environment. It runs on Amazon’s search infrastructure — the same that powers Alexa+, Amazon Quick, and Kiro — and combines a proprietary web index with an Amazon knowledge graph.
Until now, everything stayed inside the AWS boundary: queries and results flowed without leaving the customer’s perimeter. That is precisely what reassured regulated industries, which refuse to send their prompts to third-party search APIs.
On August 19, 2026, AWS added the external_web_access parameter. Set to true (the default), Web Search fetches content live from the public web, for cases where freshness wins. Set to false, it serves only the in-AWS web index and knowledge graph — no request data leaves the boundary.
The choice is explicit, but inertia works against caution: whoever does not set false stays in open mode.
The lock is an IAM permission
The control architecture is simple and elegant. For external web access to work, you must grant the bedrock-websearch:ExternalWebAccess permission to the requesting identity and leave external_web_access at its default (true). Two conditions, one effect: the agent can leave the perimeter.
This is access control in the classic sense, applied to a brand-new capability. The IAM permission becomes the single decision point — which is good news for audit, since everything is traceable in CloudTrail and governable through existing IAM policies.
But the trap is familiar to cloud security teams: an overly broad IAM permission spreads fast. A service role that receives bedrock-websearch:* for convenience opens external web access without anyone deciding it explicitly. Policy review becomes the mandatory counterpart to the feature.
The proof is in the customers, and the right IAM reflex
Deployment is already underway at reference customers. Benchling uses the tool to ground its scientific agents’ answers in published literature, on top of users’ institutional data. Gen Digital — the maker of Norton — uses it to generate content ideas grounded in current events. In both cases, the decisive argument cited is the same: the query stays within the customer’s AWS environment.
The right IAM reflex is to condition the permission on explicit tagging rather than grant it wholesale:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock-websearch:ExternalWebAccess",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:PrincipalTag:data-boundary": "public-web-allowed" }
}
}
]
}A principal-tag condition turns a binary permission into a governed decision: only identities explicitly tagged as allowed to leave the perimeter can call external web access. And because the permission is distinct from the search action itself, an IAM policy review is enough to map who can reach the public web today.
The trade-off between the two modes is rarely symmetric. An agent grounded only on Amazon’s in-AWS index and knowledge graph returns results that are current but curated; an agent with external access returns the freshest page the public web offers, including whatever a search engine happens to rank. For a regulated team, the first is almost always sufficient and strictly safer; for a trading or newsroom use case, the second is the whole point. The parameter exists precisely so one platform can serve both audiences without forcing either to compromise — and the IAM permission is what keeps that choice auditable.
Availability and pricing
External Web Access is available in three regions: US East (N. Virginia), US East (Ohio), and US West (Oregon). A global deployment will have to live with this limited geography for now.
On cost, Web Search is billed on usage, by the number of search queries agents submit — $7 per 1,000 queries, with up to $200 in free credits for new customers. It is a marginal cost that can be planned, but it can surprise on chatty agents: an agent that makes multiple search calls within a reasoning chain consumes several queries per interaction.
This launch is part of a broader sequence. On August 17, 2026, AWS opened the OpenAI GPT-5.6 models (Sol, Terra, Luna) on the bedrock-runtime endpoint with cross-region inference. On August 21, 2026, GPT-5.6 Sol pricing dropped to $4 per million input tokens and $20 for output. AWS is turning Bedrock into an open agent platform, with web grounding as one more building block.
What changes for governance
The external_web_access parameter crystallizes a tension that agent teams will have to resolve explicitly: freshness versus watertightness.
- Regulated cases (health, finance, defense). The right setting is
external_web_access: false. The agent stays within the internal AWS index, responses are grounded without ever exposing the query to the public web, and compliance is straightforward to demonstrate. - Freshness cases (pricing, news, documentation). The right setting is
true, but owned: accept that the query and its context travel to the public web, and treat that as a data flow to monitor. - The default. Configuring nothing means inheriting the
truedefault — the most exposed mode. For a CISO, the minimal action is not to read the documentation: it is to check what value is actually in force on your deployments.
# Check that no identity holds the external web access permission without an explicit decision
aws iam get-account-authorization-details \
--filter User Role \
--query 'UserDetailList[].AttachedPolicies[]' 2>/dev/null
# then grep for "bedrock-websearch:ExternalWebAccess" in the applicable policiesThe recommendation fits in one sentence: treat external_web_access as a data boundary, not a convenience setting.
On the monitoring side, search-query volume flows through CloudWatch like any other Bedrock usage: an unexplained spike in external web access is a signal of ungoverned usage worth investigating before the audit. CloudTrail records the ExternalWebAccess permission checks, so the data-boundary decision leaves a trail a compliance reviewer can actually read.
Verdict
If you deploy Bedrock agents in regulated environments, set external_web_access: false everywhere and grant the bedrock-websearch:ExternalWebAccess permission only to explicitly authorized identities. Audit existing service roles: that is where broad permissions accumulate.
If freshness is your priority, enable external access deliberately, document it, and watch query volume — at $7 per 1,000 queries, a chatty agent quickly becomes a cost line.
The story runs deeper than AWS. By shipping public-web access behind a parameter that is open by default and an IAM permission, AWS shifts responsibility for the data boundary onto the customer. That is consistent with the shared responsibility model — but it means agent security is not configured: it is decided, case by case, in IAM. The direction of travel is unmistakable: agents are now reaching past the firewall to the open web, and the cloud vendors are handing customers the switch without making the choice for them.