AWS ouvre le web public à ses agents Bedrock via un simple paramètre IAM
Le 19 août 2026, AWS a ajouté un paramètre external_web_access à Web Search sur Amazon Bedrock, qui laisse les agents récupérer du contenu en direct sur le web public. Le verrou est une permission IAM, et le réglage par défaut est « ouvert ».
19 août 2026. external_web_access. IAM. Le 19 août 2026, AWS a étendu Web Search sur Amazon Bedrock avec un paramètre nommé external_web_access. Il permet aux agents de récupérer du contenu en direct sur le web public — scores sportifs, prix en temps réel, documentation fraîchement publiée — au lieu de se limiter à l’index web interne d’Amazon. Le verrou qui contrôle ce basculement est une simple permission IAM, et le réglage par défaut est ouvert.
C’est une décision de gouvernance déguisée en fonctionnalité. Pour les équipes qui déploient des agents en environnement régulé, tout se joue dans la compréhension de ce paramètre et de sa valeur par défaut.
Un outil de grounding, deux modes
Web Search sur Amazon Bedrock est l’outil serveur géré qui « ancre » les réponses d’un modèle dans des connaissances web à jour, avec zéro sortie de données hors de l’environnement AWS du client. Il repose sur l’infrastructure de recherche d’Amazon — celle qui alimente Alexa+, Amazon Quick et Kiro — et combine un index web propriétaire avec un graphe de connaissances Amazon.
Jusqu’ici, tout restait dans la frontière AWS : les requêtes et les résultats circulaient sans quitter le périmètre du client. C’est précisément ce qui rassurait les secteurs régulés, qui refusent d’envoyer leurs prompts à des API de recherche tierces.
Le 19 août 2026, AWS a ajouté le paramètre external_web_access. À true (la valeur par défaut), Web Search va chercher le contenu en direct sur le web public, pour les cas où la fraîcheur prime. À false, il ne sert que l’index web et le graphe de connaissances internes à AWS — aucune donnée de requête ne quitte la frontière.
Le choix est donc explicite, mais l’inertie joue contre la prudence : qui n’active pas false reste en mode ouvert.
Le verrou est une permission IAM
L’architecture du contrôle est simple et élégante. Pour que l’accès au web externe fonctionne, il faut accorder la permission bedrock-websearch:ExternalWebAccess à l’identité qui fait la requête, et laisser external_web_access à sa valeur par défaut (true). Deux conditions, un seul effet : l’agent peut sortir du périmètre.
C’est du contrôle d’accès au sens classique du terme, appliqué à une capacité nouvelle. La permission IAM devient le point de décision unique — ce qui est une bonne nouvelle pour l’audit, puisque tout est traçable dans CloudTrail et gouvernable via les politiques IAM existantes.
Mais le piège est connu des équipes de sécurité cloud : une permission IAM trop large se distribue vite. Un rôle de service qui reçoit bedrock-websearch:* par commodité ouvre l’accès web externe sans qu’on l’ait décidé explicitement. La revue des politiques devient la contrepartie obligatoire de la fonctionnalité.
La preuve par les clients, et le bon réflexe IAM
Le déploiement est déjà en cours chez des clients de référence. Benchling utilise l’outil pour ancrer les réponses de ses agents scientifiques dans la littérature publiée, en plus des données institutionnelles de ses utilisateurs. Gen Digital — l’éditeur de Norton — s’en sert pour générer des idées de contenu fondées sur l’actualité. Dans les deux cas, l’argument décisif cité est le même : la requête reste dans l’environnement AWS du client.
Le bon réflexe IAM consiste à conditionner la permission à un marquage explicite, plutôt que de l’accorder en bloc :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock-websearch:ExternalWebAccess",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:PrincipalTag:data-boundary": "public-web-allowed" }
}
}
]
}Une condition par tag de principal transforme une permission binaire en décision gouvernée : seules les identités explicitement taguées comme autorisées à sortir du périmètre peuvent appeler l’accès web externe. Et comme la permission est distincte de l’action de recherche elle-même, une revue des politiques IAM suffit à cartographier qui peut, aujourd’hui, atteindre le web public.
Disponibilité et tarification
La fonctionnalité External Web Access est disponible dans trois régions : US East (N. Virginia), US East (Ohio) et US West (Oregon). Un déploiement global devra composer avec cette géographie limitée pour l’instant.
Côté coût, Web Search est facturé à l’usage, au nombre de requêtes de recherche soumises par les agents — 7 $ pour 1 000 requêtes, avec jusqu’à 200 $ de crédits pour les nouveaux clients. C’est un coût marginal qui se planifie, mais qui peut surprendre sur des agents très bavards : un agent qui multiplie les appels de recherche dans une chaîne de raisonnement consomme plusieurs requêtes par interaction.
Ce lancement s’inscrit dans une séquence plus large. Le 17 août 2026, AWS a ouvert les modèles OpenAI GPT-5.6 (Sol, Terra, Luna) sur l’endpoint bedrock-runtime avec inférence inter-régions. Le 21 août 2026, le prix de GPT-5.6 Sol baissait à 4 $ par million de tokens en entrée et 20 $ en sortie. AWS transforme Bedrock en plateforme d’agents ouverte, où le grounding web est une brique de plus.
Ce que ça change pour la gouvernance
Le paramètre external_web_access matérialise une tension que les équipes d’agents vont devoir trancher explicitement : fraîcheur contre étanchéité.
- Cas régulé (santé, finance, défense). Le bon réglage est
external_web_access: false. L’agent reste cantonné à l’index interne AWS, la réponse est ancrée sans jamais exposer la requête au web public, et la conformité se démontre simplement. - Cas de fraîcheur (prix, actualité, documentation). Le bon réglage est
true, mais assumé : il faut accepter que la requête et son contexte partent vers le web public, et traiter cela comme un flux de données à surveiller. - Le défaut. Ne rien configurer, c’est hériter du défaut
true— le mode le plus exposé. Pour un RSSI, l’action minimale n’est pas de lire la documentation : c’est de vérifier quelle valeur est réellement en vigueur sur vos déploiements.
# Vérifier qu'aucune identité ne détient la permission d'accès web externe sans décision explicite
aws iam get-account-authorization-details \
--filter User Role \
--query 'UserDetailList[].AttachedPolicies[]' 2>/dev/null
# puis grep sur "bedrock-websearch:ExternalWebAccess" dans les politiques applicablesLa recommandation tient en une phrase : traitez external_web_access comme une frontière de données, pas comme un réglage de confort.
Côté supervision, le volume de requêtes de recherche se suit dans CloudWatch comme n’importe quel usage Bedrock : un pic inexpliqué d’accès web externe est le signal d’un usage non gouverné à investiguer sans attendre l’audit.
Verdict
Si vous déployez des agents Bedrock en environnement régulé, fixez external_web_access: false partout et n’accordez la permission bedrock-websearch:ExternalWebAccess qu’aux identités explicitement autorisées. Auditez les rôles de service existants : c’est là que les permissions larges s’accumulent.
Si la fraîcheur est votre priorité, activez l’accès externe consciemment, documentez-le, et surveillez le volume de requêtes — à 7 $ les 1 000 requêtes, un agent bavard devient vite un poste de coût.
Le fond du sujet dépasse AWS. En livrant l’accès au web public derrière un paramètre ouvert par défaut et une permission IAM, AWS déplace la responsabilité de la frontière de données vers le client. C’est cohérent avec le modèle de responsabilité partagée — mais cela signifie que la sécurité des agents ne se configure pas : elle se décide, au cas par cas, dans IAM.