VS Code Agent Host : contrôle à distance par navigateur
Le Copilot de votre VS Code accessible depuis Internet, depuis un téléphone personnel, une tablette ou un PC gamer : c'est désormais possible. Les équipes sécurité n'ont pas encore cadré ce cas d'usage.
L'essentiel
Le 26 août 2026, Microsoft a présenté l'Agent Host de VS Code, un processus dédié qui héberge les sessions d'agents IA (Copilot, Claude, Codex) en dehors de la fenêtre de l'éditeur. Les sessions survivent à la fermeture du dossier ou de la fenêtre, restent synchronisées entre plusieurs clients et tournent en local ou sur une machine distante, via SSH, dev tunnel ou WSL. Une fenêtre Agents dans le navigateur, accessible sur insiders.vscode.dev/agents, se connecte à la machine de développement par un dev tunnel. Le protocole AHP (Agent Host Protocol) est ouvert, avec des clients publiés en Rust, TypeScript, Go, Kotlin et Swift. Pour les équipes sécurité, le point à retenir est simple : un agent qui lit du code et exécute des commandes sur un poste de développeur devient pilotable à distance. Il faut inventorier ces hôtes, cadrer les tunnels et décider qui approuve les actions des agents.
Qu'est-ce que l'Agent Host de VS Code ?
L'Agent Host est un processus autonome qui possède les sessions d'agents IA de VS Code. Il tourne comme processus utilitaire local ou comme serveur distant autonome, et la fenêtre de l'éditeur n'en est plus que l'un des clients. Selon la documentation de VS Code, il reste la source de vérité des sessions.
Concrètement, vous lancez une session Copilot ou Claude sur un dossier. Vous fermez le dossier, voire la fenêtre, et l'agent continue de travailler. À la réouverture, l'état est là. La même session peut être ouverte depuis deux fenêtres en même temps, synchronisées. Trois adaptateurs officiels tournent dans l'Agent Host : Copilot, Claude et Codex. Le harness Claude charge le Claude Agent SDK d'Anthropic, selon l'article d'architecture de Microsoft.
Comment piloter VS Code depuis un navigateur ?
Vous connectez VS Code à un Agent Host distant, puis vous suivez l'avancée d'un agent, approuvez ses appels d'outils (tool calls) ou annulez un travail depuis un autre client. Votre machine exécute, votre navigateur pilote. D'après la documentation, la fenêtre Agents du navigateur se connecte à la machine de développement par un dev tunnel.
| Mode de connexion | Ce que décrit Microsoft |
|---|---|
| Local | Processus utilitaire, communication par port de message (IPC) |
| SSH, Tunnel, WSL | Clients desktop connectés à un Agent Host distant, en JSON-RPC sur WebSocket |
| Navigateur | Fenêtre Agents sur insiders.vscode.dev/agents, via dev tunnel |
Le protocole AHP est ouvert et conçu pour faire collaborer plusieurs clients autour de sessions longues. Selon Microsoft, des clients sont déjà publiés en Rust, TypeScript, Go, Kotlin et Swift. N'importe qui peut donc écrire son propre client de contrôle d'agents. Les deux textes précisent que l'Agent Host et AHP sont en développement actif.
Pourquoi l'Agent Host déplace-t-il la surface d'attaque ?
Résumons ce qui devient possible : un processus autonome qui lit et modifie du code et exécute des commandes sur la machine du développeur, contrôlable depuis un navigateur, via un tunnel, avec un protocole ouvert que n'importe quelle application peut implémenter.
Les RSSI ont passé des années à verrouiller l'accès distant aux postes de travail : VPN, Zero Trust, MFA, bastions, accès privilégiés dédiés aux administrateurs. Ici, une porte d'entrée distante vers la machine de développement passe par un onglet de navigateur et un compte Copilot. Côté protection, la documentation indique que la commande code agent host démarre par défaut un serveur sur localhost protégé par un jeton de connexion. Le défaut est donc raisonnable ; le risque vient de ce qu'on change ensuite.
Quelles questions poser avant de laisser les équipes l'activer ?
Où tournent les Agent Host de vos équipes, en local ou à distance ? Cet inventaire est à construire : postes, machines SSH, WSL, tunnels déclarés.
Qui approuve les appels d'outils quand l'agent travaille en autonomie la nuit ? Une session peut continuer sans qu'aucun client ne soit connecté. Il faut décider quelles actions exigent une approbation humaine et quelles actions sont refusées d'office, plutôt que de laisser chaque développeur trancher.
Qu'est-ce qui empêche un dev tunnel d'exposer un Agent Host avec un jeton faible ? Pas grand-chose si la configuration par défaut est modifiée. La parade est organisationnelle : jetons longs et non réutilisés, durée de vie limitée des tunnels, journalisation de chaque connexion.
Ce que ça change pour vos équipes
Nous trouvons cette fonction indispensable pour un développeur qui travaille avec des agents. Nous utilisons nous-mêmes Claude Code à distance via Hermes et Telegram : c'est le workflow de développement de 2026. Nous pensons aussi que les RSSI sont dépassés, parce que l'écosystème agentique avance au rythme des versions de Copilot, Claude Code et Codex, alors que la gouvernance, quand elle existe, avance bien plus lentement. Les équipes qui ont mis des mois à cadrer l'usage de ChatGPT devront absorber celui-ci, avec une différence : ça tourne déjà sur les postes des développeurs.
Ce que nous ferions en premier :
- Inventorier les Agent Host et les dev tunnels actifs, sur les postes comme sur les machines distantes.
- Interdire par politique les tunnels non déclarés et exiger des jetons de connexion longs, propres à chaque hôte.
- Définir les actions d'agent qui exigent une approbation humaine, et interdire l'exécution autonome de nuit sur les postes qui accèdent à des secrets.
- Appliquer le moindre privilège à la machine hôte : pas de clés de production, pas de secrets longue durée dans l'environnement de l'agent.
- Journaliser les connexions et les appels d'outils, et les relier à vos alertes existantes, comme pour les agents offensifs décrits dans le rapport d'Anthropic ou la chaîne d'attaque RubyGems.