AWS ajoute une API de recherche Web directe pour les agents personnalisés et les pipelines de données

Amazon Web Services a annoncé une API autonome de recherche Web pour Amazon Bedrock AgentCore le 11 novembre 2026. Celle-ci permet aux applications de récupérer des résultats Web classés au moyen d’un seul appel signé, sans avoir à créer de passerelle. AWS facture les recherches 7 $ pour 1 000 requêtes. L’API est conçue pour les agents personnalisés, les pipelines de données et les applications existantes.

Avant ce lancement, la recherche Web sur AgentCore était proposée par l’intermédiaire d’AgentCore Gateway, ce qui nécessitait une passerelle, une cible de recherche Web et un client Model Context Protocol (MCP). La nouvelle InvokeWebSearch opération s’effectue plutôt à l’aide des SDK AWS ou de l’AWS CLI, avec des identifiants standard AWS Identity and Access Management (IAM) et une authentification Signature Version 4, sans clé API ni secret distinct. Les résultats contiennent des extraits de texte et, lorsqu’ils sont disponibles, les titres des pages, leurs URL et leurs dates de publication.

La recherche directe pour une orchestration personnalisée

L’API est destinée aux boucles d’agents personnalisées et aux infrastructures telles que LangChain ou LlamaIndex, ainsi qu’aux charges de travail sans agents, notamment les tableaux de bord, les pipelines de vérification des faits, l’enrichissement de contenu et les systèmes de surveillance. Elle permet également aux développeurs de gérer eux-mêmes les nouvelles tentatives, la mise en cache et la gestion des erreurs, plutôt que de confier ces fonctions à une passerelle.

Le service effectue ses recherches dans un index Web exploité par Amazon. AWS indique que les requêtes sont traitées au sein d’AWS plutôt que transmises à un moteur de recherche tiers, et que l’opération utilise la même infrastructure de recherche qu’Alexa+, Kiro, Quick et d’autres produits Amazon.

Les requêtes peuvent contenir jusqu’à 200 caractères. Les appelants peuvent demander de 1 à 25 résultats et en recevoir jusqu’à 25 lorsque maxResults est omis. Les listes de domaines à inclure et à exclure peuvent chacune contenir jusqu’à 100 entrées, et un domaine racine correspond également à ses sous-domaines. Les filtres de date de publication acceptent des horodatages UTC au format RFC 3339, et les deux publishedAfter et publishedBefore bornes sont inclusives.

Les utilisateurs de Python ont besoin de Boto3 1.43.127 ou d’une version ultérieure. La prise en charge est également incluse dans langchain-aws 1.9.3 et AgentCore Python SDK 1.26.0. Dans la console AgentCore, les utilisateurs peuvent tester des requêtes avec des paramètres de nombre de résultats, de date et de domaine, examiner les métadonnées des résultats et la latence des appels, puis générer un extrait de code d’intégration ou créer une cible de passerelle.

Contrôle des identités et des réseaux privés

Les appelants doivent disposer de bedrock-agentcore:InvokeWebSearch l’autorisation sur l’outil de recherche Web géré par AWS, soit la même action et la même ressource que celles utilisées par le rôle de service d’une passerelle. Les politiques de contrôle des services peuvent appliquer des garde-fous à l’échelle de plusieurs comptes, ce qui permet aux organisations de gouverner la recherche directe en parallèle des autres autorisations AWS.

Pour les charges de travail exécutées dans des sous-réseaux privés, AWS PrivateLink peut acheminer les appels par l’intermédiaire d’un point de terminaison d’interface dans un cloud privé virtuel (VPC). Le trafic reste ainsi sur le réseau AWS, sans passerelle Internet, passerelle NAT ni serveur mandataire. Les politiques de point de terminaison, les groupes de sécurité, l’emplacement des sous-réseaux et une condition aws:SourceVpce IAM peuvent limiter les principaux et les chemins réseau autorisés à lancer des recherches.

CloudTrail consigne les InvokeWebSearch requêtes comme événements de données, mais ceux-ci ne sont pas consignés par défaut. Un journal de suivi ou une banque de données d’événements doit comporter un sélecteur d’événements pour le type de ressource AWS::BedrockAgentCore::WebSearch correspondant. Les événements ainsi générés identifient l’outil de recherche Web et maxResults, et non le texte de recherche ni les filtres. Les conditions d’utilisation acceptables applicables exigent également que les clients conservent et affichent les citations de sources et les liens fournis avec les résultats.

Disponibilité et limites de la passerelle

L’API est facturée selon le même type d’utilisation que le connecteur de passerelle, mais son utilisation directe n’entraîne aucuns frais de passerelle. Son quota par défaut est de 10 requêtes par seconde et par compte dans chaque région, et les clients peuvent demander une augmentation. Au lancement, l’API est disponible dans les régions US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo) et Asia Pacific (Sydney).

AWS recommande toujours AgentCore Gateway pour la plupart des charges de travail fondées sur des agents, en particulier les déploiements qui regroupent des outils compatibles avec MCP derrière un seul point de terminaison, utilisent des sessions MCP facultatives ou appliquent une politique de sources contrôlée par un administrateur à plusieurs équipes. Les deux solutions effectuent leurs recherches dans le même index, mais la passerelle peut également authentifier les appelants au moyen de jetons Web JSON, tandis que l’API autonome utilise uniquement IAM. Les administrateurs de passerelle peuvent imposer des listes de domaines au niveau des cibles, invisibles pour les agents qui les appellent ; les requêtes adressées directement à l’API comportent leurs propres filtres.

Ce lancement rend l’index Web d’Amazon accessible sans obliger les applications à adopter MCP ou l’architecture de passerelle. La distinction porte sur le contrôle opérationnel : les appelants directs prennent en charge la gestion des requêtes et le filtrage, tandis que les environnements partagés d’agents conservent les contrôles centralisés de la passerelle sur les outils, l’authentification et les politiques de sources.