AWS offre aux agents de codage un aperçu en direct du site, depuis leur session isolée

Amazon Web Services a ajouté la fonction Session endpoints à AgentCore runtime. AgentCore runtime exécute chaque session d'agent IA dans sa propre microVM isolée. Jusqu'ici, tout ce que l'agent lançait à l'intérieur, un site par exemple, restait invisible depuis l'extérieur. Désormais, la session dispose d'une URL protégée : vous l'ouvrez dans le navigateur et vous regardez l'agent de codage assembler l'application web. Chaque modification apparaît sur la page en quelques secondes, avant même que quiconque ait pu déployer quoi que ce soit sur un hébergement.

Pourquoi regarder le site pendant que l'agent code

Les agents de codage produisent déjà des tableaux de bord, des fiches produit et des prototypes fonctionnels. Le plus simple pour contrôler ce travail est de le faire à la main : ouvrir l'application, cliquer un peu partout, demander un changement, regarder le résultat. La boucle est rapide tant que l'application tourne là où l'agent édite les fichiers. S'il faut d'abord la copier et la déployer ailleurs, chaque modification attend son déploiement, et la relecture ralentit à sa vitesse.

Les Session endpoints suppriment cette étape. Ils ne remplacent pas un hébergement de production : AWS recommande explicitement de servir l'application aux utilisateurs via un service comme AWS Amplify Hosting. L'endpoint sert à construire, tester et valider ce que l'agent a produit.

Comment fonctionne le banc de démonstration

L'exemple du dépôt agentcore-samples comprend quatre éléments :

• Le agent de codage tourne dans la session sur le port 8080 et modifie les fichiers du site avec quatre outils : list, read, write et edit.
• Le serveur de développement Vite écoute sur le port 8090, sert le site et signale au navigateur, par WebSocket, chaque fichier enregistré.
• Sur votre machine, l'application PreviewApp affiche la page : le chat à gauche, le site en direct à droite. Elle envoie vos requêtes à InvokeAgentRuntime et ouvre un point d'entrée local vers le site.
• Pour ses décisions, l'agent appelle le modèle Claude Haiku 5.5 dans Amazon Bedrock.

Le premier appel à InvokeAgentRuntime démarre la session, et l'adresse du Session endpoint arrive dans l'en-tête de la réponse. La suite est simple. Vous demandez de passer le site à un thème sombre « café ». L'agent lit src/main.js, src/style.css et index.html, enregistre les styles, et le site change sans rechargement de la page. Les étapes de l'agent s'affichent dans le chat en streaming, sous forme de server-sent events. La demande suivante, rendre le bouton « Order ahead » vert, se déroule de la même façon : l'agent ne modifie que style.css.

Six points à connaître pour la configuration

• Vous choisissez les ports. Le paramètre allowedPorts, renseigné à la création du runtime, accepte de 1 à 5 ports ou plages dans l'intervalle 8000–12000, hors ports réservés de la plateforme. Un port autorisé ne lance pas de serveur pour autant : l'application doit y écouter sur 0.0.0.0.
• L'URL arrive avec la session, dans l'en-tête X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url.
• Chaque requête est authentifiée. Pour un runtime IAM, il faut une signature SigV4 et l'autorisation bedrock-agentcore:InvokeAgentRuntimeProxy ; pour un runtime avec autorisation JWT, il faut un jeton bearer. Connaître l'adresse ne suffit pas.
• Le port est choisi par le préfixe du nom d'hôte, par exemple 8090--<id>.runtime.bedrock-agentcore.<region>.on.aws. Le client se connecte toujours au port 443.
• HTTP/1.1, HTTP/2, server-sent events, gRPC et WebSocket sont pris en charge.
• L'endpoint est lié à une seule session et disparaît avec elle.

Le navigateur ne sait pas signer lui-même les requêtes de la page en SigV4. C'est pourquoi le SDK bedrock-agentcore ouvre sur votre machine un point local sur localhost:8088, qui ajoute les identifiants à chaque requête et à chaque poignée de main WebSocket. Il n'écoute que sur 127.0.0.1 et rejette les connexions WebSocket provenant de pages d'autres origines.

Par ailleurs, le port 8081 est ouvert dans la session : l'agent y expose une route /status avec la liste des requêtes et des fichiers modifiés. Seul le numéro de port change pour passer par le même endpoint. Le port 8080 ne figure volontairement pas dans la liste : InvokeAgentRuntime atteint l'agent même sans Session endpoint.

Ce que l'endpoint rejette et ce qu'il faut garder en tête

Les refus du runtime arrivent avec un statut HTTP, un corps vide et un code d'erreur dans l'en-tête, ce qui permet de les distinguer facilement des erreurs de votre application :

• port hors de allowedPorts : 403 AccessDenied ;
• requête sans identifiants valides : 403 AccessDenied ou 401 AuthenticationRequired ;
• port autorisé mais sans processus à l'écoute : 502 PortNotReachable ;
• URL d'une session déjà fermée : 404 SessionNotFound.

Toutes les requêtes sont enregistrées dans AWS CloudTrail sous forme d'événements InvokeAgentRuntimeProxy. Le runtime supprime ses propres en-têtes d'authentification avant de transmettre la requête, si bien que le site ne voit pas la signature.

Il y a aussi des limites. La fonction ne marche qu'avec les runtimes microVM, pas avec le type de calcul Instances. L'URL est accessible en HTTPS public, et AWS PrivateLink n'est pas pris en charge pour les connexions entrantes.

Si le runtime remplace le nœud de calcul de la session, les connexions se ferment, et les modifications de l'agent peuvent être perdues en l'absence de stockage persistant. Le site et l'agent vivent dans la même session sans séparation des droits : mieux vaut donc n'accorder au rôle d'exécution que les permissions nécessaires. Les outils de fichiers de l'agent ne sortent pas du dossier du site.

Si des tiers peuvent envoyer des prompts, AWS recommande Amazon Bedrock Guardrails et une relecture manuelle des changements avant publication.

L'exemple se déploie sans Docker : l'agent part sous forme de fichier zip vers Amazon S3 via le direct code deployment pour Node.js 22. Il faut Python 3.10+, bedrock-agentcore 1.25.2+ et boto3 1.43.122+. Après vos essais, lancez cleanup.py : il supprime le runtime, le code et le rôle IAM.

Pour les équipes qui construisent des agents développeurs, c'est un moyen pratique de raccourcir la boucle « demander, regarder, corriger ». À une condition : ne laissez pas le preview activé plus longtemps que nécessaire, car le point local fonctionne avec vos propres identifiants.