InfrastructureAWS ML Blog1h

Exécuter des proxies MCP personnalisés en serverless sur Amazon Bedrock AgentCore Runtime

Résumé IASource uniqueImpact UE

Amazon Web Services vient de détailler une architecture permettant de déployer des proxys MCP (Model Context Protocol) personnalisés en mode serverless sur Amazon Bedrock AgentCore Runtime. Cette solution s'adresse aux équipes qui souhaitent insérer une couche de contrôle programmable entre leurs agents IA et les outils auxquels ils accèdent, bases de données, API tierces, systèmes de fichiers, sans modifier ni le client ni le serveur MCP en amont. Le proxy s'exécute comme une charge de travail sans état sur AgentCore Runtime, découvre automatiquement les outils disponibles au démarrage, les réexpose avec la logique personnalisée appliquée, puis transfère les requêtes de manière transparente. L'infrastructure est entièrement gérée par AWS, avec mise à l'échelle automatique, observabilité intégrée via Amazon CloudWatch et OpenTelemetry, et gestion des identités via AgentCore Identity.

L'intérêt concret est d'ordre gouvernance et conformité. En production, les interactions entre agents IA et outils doivent respecter des politiques de sécurité internes, des réglementations sectorielles et des exigences d'auditabilité spécifiques : nettoyage des entrées avant qu'elles atteignent les systèmes backend, génération de journaux d'audit dans des formats particuliers, ou encore rédaction de données sensibles au niveau du protocole. AgentCore Gateway propose déjà des intercepteurs Lambda pour intégrer ce type de logique, mais certaines organisations disposent de bibliothèques de filtrage MCP internes ou de systèmes de conformité on-premises qu'elles ne souhaitent pas refactoriser en fonctions Lambda. Le proxy serverless sur Runtime offre alors une alternative portable, réutilisable dans des environnements hybrides ou multi-systèmes, sans dépendance à un intercepteur spécifique à une plateforme.

Ce développement s'inscrit dans l'adoption rapide du Model Context Protocol comme standard de facto pour connecter les agents IA à leurs outils. MCP, initialement proposé par Anthropic fin 2024, est désormais supporté par la plupart des grandes plateformes d'agents, et AWS positionne AgentCore comme son infrastructure de référence pour les déploiements en production. La solution présentée s'appuie sur une implémentation open source disponible sur GitHub, ce qui facilite l'adoption et la personnalisation. Elle peut également se connecter à AgentCore Gateway pour bénéficier de la découverte gérée des outils, de la gestion des credentials et de l'application de politiques à l'échelle, y compris sur des fonctions Lambda et des intégrations SaaS. Pour les équipes qui industrialisent leurs agents IA, ce pattern représente une brique d'infrastructure critique pour passer du prototype au déploiement régi par des exigences d'entreprise réelles.

Impact France/UE

Les entreprises européennes déployant des agents IA sur AWS peuvent s'appuyer sur cette architecture pour implémenter des couches de conformité RGPD et AI Act sans refactoriser leurs bibliothèques de filtrage MCP existantes.

Dans nos dossiers

Anthropic Agents IA Open weight & Open source

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

Amazon Bedrock propose désormais une attribution détaillée des coûts

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité d'attribution granulaire des coûts pour Amazon Bedrock, son service d'inférence d'IA en cloud. Désormais, Bedrock attribue automatiquement chaque dépense d'inférence à l'identité IAM (Identity and Access Management) qui a effectué l'appel, qu'il s'agisse d'un utilisateur IAM classique, d'un rôle assumé par une application Lambda, ou d'une identité fédérée via un fournisseur comme Okta ou Microsoft Entra ID. Ces données apparaissent directement dans AWS Cost and Usage Reports (CUR 2.0) sans aucune ressource supplémentaire à gérer ni modification des workflows existants. Concrètement, un rapport peut montrer qu'Alice a dépensé 0,069 dollar en tokens d'entrée et 0,214 dollar en tokens de sortie avec Claude Sonnet 4.6, pendant que Bob a consommé 1,188 dollar au total avec Claude Opus 4.6, avec une précision à l'identité près. Il est également possible d'ajouter des tags de coût sur les identités IAM pour regrouper les dépenses par équipe, projet ou centre de coût dans AWS Cost Explorer. Cette visibilité fine répond à un besoin croissant des entreprises qui voient l'inférence IA représenter une part de plus en plus significative de leur facture cloud. Sans attribution précise, il est impossible de refacturer correctement les équipes internes, d'identifier les usages inefficaces ou de planifier les budgets. Grâce à cette fonctionnalité, un DSI peut désormais savoir exactement quelle équipe produit, quel service applicatif ou quel développeur génère quels coûts LLM, sans déployer d'infrastructure de monitoring supplémentaire. Pour les organisations qui font transiter leurs appels via une passerelle LLM centralisée, AWS recommande d'utiliser AssumeRole avec des tags de session dynamiques afin de préserver la granularité par utilisateur final, même derrière un proxy unique. Cette annonce s'inscrit dans une tendance de fond : les grands fournisseurs de cloud cherchent à rendre l'IA générative compatible avec les pratiques de gouvernance financière des entreprises. Amazon Bedrock, qui donne accès à des modèles de plusieurs éditeurs dont Anthropic, Mistral et Meta, doit convaincre les directions financières que la dépense IA est traçable et contrôlable. La concurrence avec Azure AI et Google Vertex AI pousse AWS à muscler ses outils de FinOps autour de l'IA. À mesure que les modèles comme Claude Opus deviennent plus coûteux à l'usage, la capacité à attribuer précisément chaque dollar dépensé devient un argument de vente central pour les déploiements en entreprise, où la responsabilisation budgétaire par équipe est souvent non négociable.

UELes entreprises européennes utilisant Amazon Bedrock peuvent désormais attribuer précisément leurs dépenses d'inférence IA par équipe ou projet, facilitant la gouvernance financière et la refacturation interne sans infrastructure supplémentaire.

InfrastructureActu

1 source

2AWS ML Blog

Amazon Bedrock AgentCore Runtime introduit des capacités MCP client avec état

Amazon a introduit des capacités client MCP (Model Context Protocol) avec état dans son service AgentCore Runtime sur Amazon Bedrock, marquant une évolution majeure pour les développeurs d'agents IA. Jusqu'à présent, les serveurs MCP hébergés sur cette plateforme fonctionnaient en mode sans état : chaque requête HTTP était traitée de façon indépendante, sans mémoire entre les appels. Le nouveau mode avec état, activé via un simple paramètre stateless_http=False, provision une microVM dédiée par session utilisateur, persistant jusqu'à 8 heures ou 15 minutes d'inactivité. Cette architecture permet désormais trois capacités clés du protocole MCP : l'élicitation (demander une saisie utilisateur en cours d'exécution), le sampling (solliciter du contenu généré par un LLM côté client), et les notifications de progression (streamer des mises à jour en temps réel). La continuité de session est assurée via un en-tête Mcp-Session-Id, échangé lors de l'initialisation et inclus dans toutes les requêtes suivantes. Ces nouvelles capacités transforment fondamentalement la nature des workflows agents. Là où les implémentations sans état forçaient les agents à s'exécuter de bout en bout sans interruption, les agents peuvent désormais mener de véritables conversations bidirectionnelles avec leurs clients : s'arrêter pour demander une clarification à l'utilisateur au milieu d'un appel d'outil, déléguer dynamiquement la génération de contenu au LLM présent côté client, ou signaler l'avancement d'opérations longues en temps réel. Pour les équipes qui construisent des assistants IA complexes, des pipelines de traitement de documents ou des agents d'automatisation nécessitant validation humaine intermédiaire, c'est un changement de paradigme concret qui élimine des contournements architecturaux souvent coûteux à maintenir. Le Model Context Protocol, standard ouvert définissant comment les applications LLM se connectent à des outils et sources de données externes, gagne rapidement en adoption depuis son lancement par Anthropic fin 2024. Amazon avait déjà intégré l'hébergement de serveurs MCP sans état dans AgentCore Runtime dans une version précédente ; cette mise à jour complète l'implémentation bidirectionnelle du protocole. L'isolation entre sessions via des microVMs dédiées garantit la sécurité et l'indépendance des contextes, chaque session bénéficiant de CPU, mémoire et système de fichiers séparés. Si une session expire ou que le serveur redémarre, les clients reçoivent une erreur 404 et doivent réinitialiser la connexion. Cette approche positionne AWS comme un acteur central dans l'infrastructure d'agents IA d'entreprise, en rivalité directe avec les offres similaires de Microsoft Azure et Google Cloud dans la course à standardiser les architectures agentiques.

UELes équipes européennes développant des agents IA sur des plateformes cloud peuvent désormais implémenter des workflows agentiques bidirectionnels natifs sans contournements architecturaux coûteux.

OutilsActu

1 source

3VentureBeat AI

Google et AWS répartissent la pile des agents IA entre contrôle et exécution

Google et Amazon Web Services viennent de redéfinir leurs approches respectives pour orchestrer les agents IA d'entreprise, révélant une fracture profonde dans la façon de concevoir l'infrastructure agentique. Google a lancé une nouvelle version de Gemini Enterprise, regroupant sous une même bannière sa plateforme Gemini Enterprise et son application éponyme, tout en rebaptisant Vertex AI en Gemini Enterprise Platform. De son côté, AWS a enrichi Bedrock AgentCore d'un système de harness, un dispositif de configuration automatique alimenté par Strands Agents, son framework open source. Ce harness permet aux équipes de définir ce que l'agent doit faire, quel modèle utiliser et quels outils appeler, le reste étant pris en charge automatiquement. Dans le même temps, Anthropic a dévoilé ses Claude Managed Agents et OpenAI a renforcé son Agents SDK, confirmant que l'ensemble de l'industrie cherche simultanément à résoudre le même problème : comment gérer des agents IA qui tournent durablement en production. L'enjeu dépasse la simple question de l'outillage développeur. À mesure que les agents passent de courtes tâches ponctuelles à des workflows autonomes de longue durée, un nouveau type de défaillance émerge : la dérive d'état (state drift). Un agent qui fonctionne en continu accumule de la mémoire, des réponses et un contexte évolutif. Avec le temps, ce contexte devient obsolète : les sources de données changent, les outils renvoient des réponses contradictoires, et l'agent perd en fiabilité sans que personne ne s'en rende forcément compte. C'est ce problème systémique que Google et AWS cherchent à prévenir, par deux chemins opposés. Google mise sur un plan de contrôle à la manière de Kubernetes, centré sur la gouvernance et la visibilité. AWS privilégie la vitesse de déploiement et la simplification de la configuration, en déléguant la coordination à la couche d'exécution. Cette divergence illustre une transformation plus profonde de la pile IA, qui se stratifie désormais en couches spécialisées. Google positionne Gemini Enterprise comme une porte d'entrée unifiée vers l'ensemble de ses systèmes IA, avec des outils de sécurité et de gouvernance inclus dans l'abonnement, selon Maryam Gholami, directrice senior produit chez Google. AWS, Anthropic et OpenAI s'orientent davantage vers la vélocité et la flexibilité d'exécution. La question de savoir quelle approche s'imposera reste ouverte : Gholami elle-même reconnaît que ce sont les clients qui dicteront les usages des agents longue durée, un domaine où les bonnes pratiques restent encore à définir. Le vrai test viendra lorsque les entreprises feront tourner ces systèmes en conditions réelles, avec des agents qui devront remonter de l'information, demander des validations humaines, et résister à la dégradation progressive de leur contexte.

UELes entreprises européennes qui déploient des agents IA en production sur Google Cloud ou AWS devront arbitrer entre les deux approches d'orchestration pour leurs workflows agentiques durables.

InfrastructureOpinion

1 source

4AWS ML Blog

AWS Agent Registry : la gestion des agents à grande échelle désormais en prévisualisation

Amazon Web Services a lancé en preview l'AWS Agent Registry, une nouvelle fonctionnalité intégrée à sa plateforme Amazon Bedrock AgentCore, conçue pour permettre aux entreprises de découvrir, partager et réutiliser leurs agents IA à grande échelle. Disponible dès maintenant via la console AgentCore, les SDK AWS et une API dédiée, le registre centralise les métadonnées de chaque agent, outil, serveur MCP, compétence d'agent ou ressource personnalisée sous forme de fiches structurées. Chaque entrée documente l'auteur, les protocoles supportés, les capacités exposées et les modalités d'invocation. Le registre prend en charge nativement les standards ouverts MCP (Model Context Protocol) et A2A, et peut indexer des agents hébergés n'importe où : sur AWS, chez d'autres fournisseurs cloud ou dans des environnements on-premises. Il est également accessible comme serveur MCP, ce qui le rend interrogeable directement depuis des clients compatibles comme Kiro ou Claude Code. L'enjeu est considérable pour les entreprises qui opèrent des centaines ou des milliers d'agents simultanément. Sans registre central, trois problèmes se cumulent : l'invisibilité (personne ne sait ce qui existe), l'absence de gouvernance (n'importe qui peut publier n'importe quoi), et la duplication (plusieurs équipes reconstruisent les mêmes capacités en parallèle). AWS Agent Registry répond à ces trois défis en un seul endroit. La recherche hybride combine correspondance par mots-clés et compréhension sémantique : une requête sur "traitement de paiements" remonte ainsi des outils étiquetés "facturation" ou "invoicing", même s'ils portent des noms différents. Pour les organisations avec des fournisseurs d'identité tiers, un accès basé sur OAuth permet aux équipes de construire leurs propres interfaces de découverte sans dépendre des credentials IAM d'AWS. Ce lancement s'inscrit dans une tendance de fond : l'industrialisation des architectures multi-agents, où les organisations ne déploient plus un ou deux agents expérimentaux mais des écosystèmes entiers interconnectés. AWS positionne AgentCore comme la couche d'infrastructure universelle pour ces systèmes, indépendante du modèle, du framework ou du fournisseur cloud. Le registre est la pièce manquante qui transforme une collection d'agents dispersés en un actif organisationnel géré, versionné et auditable. La roadmap annoncée prévoit des workflows d'approbation pour la publication, des capacités de monitoring en production et des mécanismes de retrait des agents obsolètes. Dans un secteur où OpenAI, Google et Microsoft développent leurs propres orchestrateurs d'agents, AWS mise sur l'ouverture et l'interopérabilité comme différenciateurs pour conquérir les grandes entreprises déjà ancrées dans des architectures hybrides.

UELes entreprises européennes déployant des agents IA sur AWS peuvent désormais centraliser leur gouvernance et audit, facilitant la conformité aux exigences de traçabilité de l'AI Act.

InfrastructureOpinion

1 source