AWS offre la recherche web aux agents sans clé d'API : le gardien des dépendances a terminé en 36 secondes

Le modèle ignore ce qui est sorti ce matin : ni les vulnérabilités récentes, ni les versions, ni les nouveaux tarifs. Tout agent qui travaille sur l'actualité a donc besoin d'une recherche web. En production, on lui impose aussitôt trois exigences : des résultats accompagnés de liens, un contrôle sur les sources jugées fiables, et la garantie que les requêtes de recherche ne fuient pas à l'extérieur. Les requêtes révèlent souvent sur quoi travaille une équipe. AWS répond à ces exigences avec la nouvelle Web Search API d'Amazon Bedrock AgentCore et la présente à travers un cas pratique : un « gardien » quotidien des dépendances pour une équipe de sécurité.

Ce qui a été lancé

La Web Search API fournit à l'agent des résultats actuels en un seul appel. Chaque résultat comprend le titre de la page, l'URL, la date de publication et un extrait pertinent par rapport à la requête. La requête peut être restreinte par domaines (inclusion ou exclusion) et par plage de dates. Elle est servie par un index web géré par Amazon elle-même, et non par un moteur de recherche tiers.

L'authentification passe par AWS Signature Version 4, avec le rôle sous lequel l'agent s'exécute déjà : sur Lambda, ECS ou dans le runtime AgentCore. Il n'y a pas de clé de recherche distincte, donc rien à stocker ni à faire tourner. Pour les équipes plateforme, il existe une seconde voie, AgentCore Gateway : l'administrateur définit une politique de sources unique pour tous les agents et clients MCP, et l'agent ne peut pas la lever.

Pour ceux qui utilisent LangChain, l'outil de recherche web de langchain-aws appelle désormais cette API. Il fonctionne avec les agents LangChain, LangGraph et Deep Agents.

Comment fonctionne le gardien

Un graphe LangGraph vérifie chaque matin si de nouveaux éléments sont apparus concernant les paquets et images que l'équipe publie. Trois branches (npm, PyPI, images de base de conteneurs) s'exécutent en parallèle. Dans chacune, un modèle Claude de Bedrock décide quoi chercher et renvoie à la fin des trouvailles structurées selon un schéma Pydantic : paquet, titre, CVE ou identifiant de bulletin, criticité déclarée, indicateur d'exploitation, action recommandée et URL de la source.

L'idée centrale est la répartition des rôles : le modèle imagine les requêtes et rédige les conclusions, tandis que tout ce qui doit s'exécuter quel que soit le comportement du modèle réside dans le code. L'outil est créé avec des paramètres figés : liste noire de domaines, borne inférieure de date, maximum de quatre recherches par branche. L'option model_filters=False ne laisse au modèle qu'un seul argument : le texte de la requête. L'outil renvoie les résultats deux fois : sous forme de texte pour le modèle et sous forme d'artefact pour le graphe, afin que le code puisse les vérifier.

Avant d'être renvoyée, chaque trouvaille subit quatre contrôles par rapport à ce qu'ont retourné les recherches de cette même branche :

• l'URL figurait bien dans les résultats ;
• le titre ou le texte de la source nomme le paquet comme un mot entier ;
• la CVE ou l'identifiant de la trouvaille figure dans le texte de la source ;
• la date de publication est comprise dans la fenêtre de veille (pas de date : considérée comme hors fenêtre).

Ensuite, l'étape keep_new confronte les trouvailles restantes au store de LangGraph pour éviter que la même information arrive deux fois, et report assemble un tableau avec des liens.

Ce qu'a montré l'exécution

Sur une fenêtre de sept jours, les trois branches ont effectué 12 recherches et obtenu 80 sources. Cela a pris 36 secondes, contre 99 si les branches s'étaient enchaînées. La vérification a écarté deux trouvailles : pour l'une, la source ne nommait pas le paquet ; pour l'autre, le numéro de CVE était absent du texte. Quatre sont passées, mais le rapport n'en a montré que deux : les deux autres se trouvaient déjà dans le store après des tests antérieurs. Une relance avec les mêmes données a produit un rapport vide, comme il se doit pour une tâche quotidienne.

Limites et conseils pratiques

Le point le plus important : les contrôles détectent les URL et identifiants inventés, les sources qui ne mentionnent pas le paquet et les pages périmées. Mais ils ne confirment ni la criticité, ni le fait d'exploitation, ni les versions concernées, ni la recommandation. Une page indexée cette semaine peut décrire un ancien incident. Pour un véritable processus de sécurité, recoupez les trouvailles avec des bases de vulnérabilités faisant autorité, et faites-les examiner par un humain avant toute action.

Quelques détails pratiques supplémentaires :

• InMemoryStore ne vit que le temps de la session. Pour une exécution quotidienne, il faut un stockage persistant, par exemple DynamoDBStore, car les sessions du runtime AgentCore sont éphémères.
• La limite par défaut est de 10 requêtes par seconde par région pour l'ensemble du compte ; les branches parallèles se la partagent.
• L'outil s'appelle web_search. Si l'agent dispose déjà d'une autre recherche portant ce nom, renommez l'une des deux.
• Les droits requis sont minimaux : une seule action, bedrock-agentcore:InvokeWebSearch, sur une ressource appartenant à AWS.

Le choix entre les deux voies est simple. Si l'application appelle elle-même la recherche et fixe elle-même les règles, utilisez l'API directement. Si une équipe plateforme distribue la recherche à de nombreux agents et veut une politique de sources unique, il vous faut Gateway. Celui-ci convient aussi lorsque la recherche est destinée à des clients MCP comme Claude. Pour des équipes différentes, il suffit de créer un web search target distinct avec sa propre liste de blocage.