L'identité d'un hôte d'extensions IDE peut-elle prouver qui est un agent ?

Un hôte d'extensions d'éditeur peut avoir une signature de code valide tout en vous empêchant de déterminer quelle extension a demandé une action sensible. Ce n'est pas un défaut de la signature du code. C'est le résultat prévisible d'un mécanisme d'identité du système d'exploitation auquel on demande de répondre à une question qui se pose à l'intérieur d'un même processus.

Cette distinction compte lorsqu'un agent de programmation IA s'exécute dans un IDE. L'hôte peut charger plusieurs extensions, accepter des commandes provenant d'un espace de travail et transmettre le travail à une passerelle capable d'atteindre une API ou une cible SSH. Si la passerelle approuve l'hôte une fois pour toutes et considère cette approbation comme la preuve de l'intention d'une extension précise, elle accorde plus d'autorité que les éléments disponibles ne le permettent.

J'ai déjà vu cette erreur se présenter comme une conception de sécurité irréprochable : vérifier l'éditeur signé, afficher le signataire dans une demande d'approbation, puis autoriser l'exécution. C'est un contrôle utile. Il devient dangereux lorsque la demande laisse croire à une précision qu'elle n'a pas. L'hôte peut être digne de confiance, tandis que la demande qui a franchi sa frontière reste ambiguë.

La signature d'un hôte identifie le conteneur, pas ses occupants

La signature du code prouve des faits sur une image exécutable. Sur macOS, Apple décrit la signature du code comme un moyen d'établir l'origine et l'intégrité d'un logiciel. Le système peut vérifier qu'une autorité de signature de confiance a signé le code et que le code chargé correspond toujours au contenu signé. C'est exactement le type d'élément dont une décision de sécurité a besoin lorsqu'elle demande : « Quel processus applicatif fait la demande ? »

Elle ne prouve pas : « Quelle fonction d'extension à l'intérieur de ce processus a fait la demande ? » À cette frontière, un processus possède une seule identité exécutable. Si un éditeur démarre un hôte d'extensions qui charge dix plugins, le noyau ne crée pas dix identités de signature distinctes pour leur JavaScript, leur bytecode, leurs rappels ou leurs appels à l'API d'extension.

Cette distinction a une conséquence pratique. Une passerelle peut consigner de manière défendable :

caller executable: /Applications/Editor.app/.../extension-host
signing authority: Example Software Team ID ABC123
process id: 8421
parent process: Editor.app pid 8304

Elle ne peut pas déduire cela de la signature seule :

extension: publisher.cloud-deploy
command: deployCurrentProject
prompt source: chat request 18

Le premier bloc contient des éléments fournis par le système d'exploitation. Le second décrit la provenance au niveau de l'application. Les deux peuvent être utiles, mais ils doivent être traités différemment dans un journal et sur un écran d'approbation.

On appelle souvent les deux « identité », puis on perd la distinction pendant l'implémentation. Ne le faites pas. Le signataire vous indique qui a produit la boîte. Il ne vous dit pas quel passager a pris les commandes.

Les hôtes d'extensions partagés regroupent plusieurs autorités

Un hôte d'extensions existe pour permettre à l'éditeur de charger et de coordonner les extensions. Cette conception est pratique, mais elle transforme l'hôte en ensemble d'autorités. Un plugin de complétion, un formateur, une intégration de contrôle de version, un assistant conversationnel et une extension d'espace de travail peuvent tous s'exécuter dans le même processus hôte.

Imaginons une passerelle qui autorise un appel HTTPS après avoir vérifié la signature de l'éditeur. L'extension A demande à l'hôte d'appeler un point de terminaison de déploiement. L'extension B a accès à une API d'extension qui peut amener ce même hôte à effectuer une opération sortante, directement ou par l'intermédiaire d'une commande enregistrée par A. À la passerelle, les deux demandes arrivent avec le même identifiant de processus et la même autorité de signature. La passerelle ne peut pas les distinguer en inspectant la signature de l'hôte.

L'ambiguïté s'aggrave lorsque les extensions communiquent par l'intermédiaire de services partagés de l'hôte. Un plugin peut enregistrer une commande. Un autre plugin peut l'appeler. Une extension conversationnelle peut recevoir des instructions provenant d'un fichier du dépôt, du contenu d'une issue ou d'un résultat de terminal collé, puis déclencher une commande. L'attribution comporte alors plusieurs niveaux : l'hôte signé, l'extension qui a effectué l'appel, l'extension qui a fourni l'entrée, ainsi que la personne ou le contenu non fiable qui l'a influencé.

Rien de tout cela ne rend les extensions IDE intrinsèquement dangereuses. Cela signifie que l'approbation au niveau de l'hôte porte sur l'autorité combinée de l'hôte. Si cette portée est trop large pour une opération, il vous faut un second contrôle qui examine l'opération elle-même.

Le nom d'une extension n'est une provenance que si l'hôte l'associe à la demande

Un identifiant d'extension tel que publisher.name fournit un contexte utile, mais une passerelle ne doit pas prendre une chaîne fournie par l'appelant pour une preuve. Tout code capable de créer une demande peut écrire publisher.name dans un en-tête, un corps JSON, un argument de commande ou une variable d'environnement. Cela indique seulement ce que le code affirme.

Un hôte peut renforcer cette affirmation s'il obtient l'identifiant depuis son propre registre d'extensions, l'associe au contexte d'exécution actif et l'envoie par un canal local protégé que les extensions ne peuvent pas falsifier. Même dans ce cas, le résultat répond à une question plus limitée : quel contexte d'extension géré par l'hôte a lancé cette demande ? Il n'identifie pas nécessairement la demande, le contenu du dépôt ou la personne qui a influencé ce contexte.

Le test utile est simple. Demandez-vous d'où vient chaque champ et qui pourrait le modifier.

C'est pourquoi « nous incluons le nom de l'extension dans le journal d'audit » ne constitue pas une déclaration de sécurité complète. Conservez le nom. Indiquez qu'il a été déclaré par l'hôte, sauf si l'architecture donne à la passerelle une raison de le considérer comme vérifié. Cette mention empêchera les enquêteurs futurs de prendre des métadonnées pratiques pour une preuve.

L'approbation de session a une frontière utile et une limite stricte

Approuver un processus hôte nouvellement démarré et vérifié est utile. Cela permet de détecter un exécutable différent, une autorité de signature modifiée, une nouvelle durée de vie du processus ou un chemin de lancement inattendu. La personne devant le clavier peut aussi voir ce qui est sur le point de recevoir un accès. Pour un travail courant avec un identifiant limité, cette interruption peut être le bon compromis.

La limite est qu'une approbation de session accorde à l'ensemble du processus approuvé tout ce que la session permet de faire. Si le processus héberge plusieurs extensions, elle ne peut pas distinguer une demande provenant de l'extension attendue d'une demande créée par une autre extension chargée. Une carte d'approbation claire peut afficher le signataire et l'identité du processus hôte, mais elle ne doit pas promettre une attribution au niveau du plugin qu'elle ne peut pas fournir.

Les équipes oublient aussi un autre problème. Elles approuvent un processus d'éditeur le matin, puis installent ou activent une extension pendant la même session de longue durée. Si l'hôte recharge ou charge du nouveau code sans modifier l'identité externe vérifiée par la passerelle, l'approbation reste plus large que ce dont la personne se souvient. La réponse appropriée dépend du comportement de l'hôte, mais le principe ne change pas : les changements à l'intérieur d'un hôte approuvé ne sont pas automatiquement visibles par un courtier extérieur.

Utilisez l'approbation de session pour la question à laquelle elle peut répondre : « Ce processus hôte signé peut-il utiliser cette catégorie d'accès pendant son existence ? » Ne la transformez pas en : « Cette extension précise peut-elle effectuer cette action irréversible précise ? »

L'approbation à chaque utilisation compense l'ambiguïté au moment décisif

Pour les identifiants sensibles, demandez l'approbation au moment où l'action est formée, et pas seulement lorsque l'hôte apparaît pour la première fois. La demande doit afficher suffisamment d'éléments de l'action proposée pour permettre une décision éclairée : destination, méthode ou cible SSH, libellé de l'identifiant et partie de la demande qui produit les conséquences.

Supposons qu'un hôte envoie cette demande à une passerelle d'action locale :

{
  "channel": "http",
  "credential": "production-deploy",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "body": {"service": "billing", "version": "a1b2c3d"}
}

Une carte d'approbation adaptée doit associer la décision à la méthode, à la destination, à l'identifiant et au corps exacts, ou à une empreinte stable du corps. Elle ne doit pas se contenter de dire : « L'éditeur souhaite utiliser production-deploy. » Cette formulation transforme l'approbation d'une action en chèque en blanc pour tous les appels que l'hôte peut effectuer avant l'expiration de la décision.

L'approbation à chaque utilisation est impopulaire parce qu'elle interrompt le flux de travail. Cette objection est pertinente pour les appels inoffensifs. Elle l'est beaucoup moins pour une écriture en production, un identifiant doté d'une large portée ou une commande SSH capable de modifier une machine. La personne qui approuve n'a pas besoin d'identifier avec certitude l'extension responsable. Elle doit voir la conséquence qui est sur le point de quitter la machine et décider si elle est légitime.

Une passerelle de coffre ajoute une autre frontière que l'approbation de session ne peut pas fournir. Tant que le coffre est verrouillé, refusez toute action, y compris les appels provenant d'hôtes précédemment approuvés. Sallyport applique cette barrière absolue avant l'autorisation de session, et un identifiant sélectionné peut exiger une approbation à chaque utilisation. Le résultat des contrôles reste ainsi honnête : le signataire de l'hôte identifie l'appelant, la décision de session admet ce processus pour une durée limitée et la décision à chaque utilisation couvre l'action sensible.

Des identifiants limités réduisent les dégâts d'une approbation correcte

L'approbation ne remplace pas la portée des identifiants. Une personne peut approuver le bon hôte et la bonne demande, puis découvrir que l'identifiant autorise bien plus que l'opération prévue. C'est un défaut de conception des identifiants, pas un défaut d'approbation.

Répartissez les accès selon les conséquences. Un jeton qui lit un dépôt ne doit pas aussi administrer tous les projets. Un identifiant de déploiement ne doit pas créer des utilisateurs ni récupérer des secrets sans rapport. Pour SSH, utilisez un compte distinct ou une configuration de commande forcée lorsque le côté distant le permet, au lieu de fournir un shell général à un flux de travail qui n'a besoin que d'une tâche de maintenance.

La recommandation courante consistant à donner à un agent un jeton de développement très large est séduisante, car sa mise en place prend cinq minutes. Elle est inadaptée lorsque le jeton traverse plusieurs environnements ou possède des droits d'écriture. Un jeton large transforme toute ambiguïté dans l'hôte d'extensions en une ambiguïté tout aussi large à l'extérieur. Des identifiants limités rendent la demande d'approbation plus facile à lire, car l'ensemble des actions possibles possède déjà des limites.

Pour les actions HTTP, limitez la destination dans la fiche de l'identifiant ou dans la configuration de la passerelle lorsque la conception le permet. Un jeton porteur injecté dans n'importe quelle URL peut être exfiltré par un hôte amené à appeler un point de terminaison contrôlé par un attaquant. Pour les actions SSH, consignez l'hôte, le compte et la catégorie de commandes prévue avant de décider qu'une approbation de session suffit.

Un échec courant commence par une action anodine de la palette de commandes

Un développeur installe une extension d'assistance et une extension de déploiement. Les deux s'exécutent dans un seul hôte d'extensions signé. Le développeur approuve l'hôte lorsque l'assistant demande à inspecter une API de préproduction, car la carte d'approbation affiche correctement l'autorité de signature de l'éditeur.

Plus tard, le développeur ouvre un dépôt qui contient un fichier de tâche avec des instructions pour l'assistant. L'assistant analyse le fichier et appelle une commande hôte enregistrée par l'extension de déploiement. La commande demande à la même passerelle d'utiliser un identifiant de production. La demande possède la même identité de processus signé que celle envoyée pour la préproduction. Une passerelle qui s'appuie uniquement sur l'approbation de session voit un appelant approuvé et poursuit l'opération.

Cette séquence n'exige ni signature falsifiée ni système d'exploitation compromis. L'échec vient d'une décision d'approbation qui couvrait l'hôte et d'un identifiant qui couvrait une action que le développeur n'avait pas l'intention d'autoriser. Un journal d'audit indiquant seulement « l'éditeur approuvé a effectué un appel HTTP » ne permettra pas à l'équipe de savoir si l'extension de déploiement, l'assistant ou un fichier de tâche a lancé la séquence.

Modifiez la configuration à trois endroits. Exigez une approbation explicite de l'identifiant de production à chaque utilisation. Affichez la destination et le contenu de la mise en production dans cette approbation. Consignez séparément l'identité de l'hôte et le contexte d'extension déclaré par l'hôte, puis conservez le lien entre l'événement d'approbation et l'appel. La demande peut rester légitime, mais elle ne pourra plus passer pour une tâche d'arrière-plan ordinaire.

Les journaux d'audit ont besoin d'une colonne de preuve, pas d'un récit flatteur

Les journaux deviennent trompeurs lorsqu'ils réduisent des faits vérifiés et un contexte déclaré par l'hôte à une seule phrase. « Le plugin X a déployé le service Y » semble précis, mais peut dissimuler une étiquette de plugin non vérifiée et une chaîne causale inconnue. Enregistrez l'événement brut avec sa source de vérité.

Une structure d'événement utile sépare les différentes affirmations :

{
  "time": "2026-07-24T10:16:43Z",
  "caller": {
    "signing_authority": "Example Software Team ID ABC123",
    "pid": 8421,
    "started_at": "2026-07-24T09:58:03Z"
  },
  "host_reported_context": {
    "extension_id": "publisher.cloud-deploy",
    "workspace": "/work/payments"
  },
  "action": {
    "channel": "http",
    "method": "POST",
    "destination": "https://deploy.example.internal/releases",
    "credential": "production-deploy"
  },
  "authorization": {
    "session_approved": true,
    "per_use_approved": true
  }
}

L'objectif n'est pas d'ajouter davantage de champs aux journaux. Il s'agit de préserver la frontière entre un fait vérifié par le système et une déclaration de l'hôte. Lors d'un incident, cette différence détermine si les enquêteurs peuvent retracer une action ou seulement répéter une étiquette.

La preuve d'intégrité compte aussi. Un journal local qu'un processus compromis peut réécrire constitue une faible preuve de son propre comportement. Sallyport construit les vues des sessions et de l'activité à partir d'un journal d'audit chiffré et chaîné par hachage, et sp audit verify peut vérifier cette chaîne hors ligne sans clé de coffre. Cela ne résout pas l'attribution aux extensions, mais empêche une modification ultérieure d'améliorer discrètement le récit.

Isolez l'opération lorsque l'attribution doit être exacte

Certaines actions exigent une réponse plus précise que celle qu'un hôte partagé peut fournir. Si un identifiant peut déplacer de l'argent, modifier les accès à la production, supprimer des données ou exécuter des commandes distantes sans restriction, faites passer l'opération par un composant doté de sa propre identité exécutable et d'une interface limitée. La passerelle pourra alors vérifier cet assistant au lieu de déduire l'intention d'un hôte d'extensions encombré.

L'assistant doit accepter un schéma de demande explicite, refuser les paramètres supplémentaires et limiter sa propre autorité. Par exemple, un assistant de mise en production peut accepter un nom de service provenant d'une liste autorisée et une empreinte de version, tout en refusant les URL arbitraires et les fragments shell. L'éditeur parent peut toujours lancer l'opération, mais il ne peut pas transformer l'assistant en client réseau généraliste.

La séparation des processus n'est pas magique. Si l'hôte peut envoyer des demandes arbitraires à l'assistant, celui-ci ne fait que déplacer la même ambiguïté dans un nouveau processus. L'interface doit supprimer les choix que l'hôte ne devrait pas avoir. Un assistant signé séparément avec une demande ouverte « tout exécuter » relève du théâtre de sécurité.

Lorsque l'isolation coûte trop cher, revenez à une approbation spécifique à l'action et à des identifiants limités. Cette combinaison donne à une personne la possibilité de détecter la conséquence, même si la source au sein de l'éditeur reste floue. Ne prétendez pas à une certitude au niveau du plugin si la conception ne peut pas montrer d'où vient cette certitude.

Traitez le texte de la demande d'approbation comme une partie de la frontière d'accès

Une demande d'approbation modifie les comportements. Son texte doit donc être traité avec autant de soin que le code qui l'applique. Si elle dit « Autoriser l'éditeur à accéder au déploiement », les utilisateurs apprendront à approuver une catégorie. Si elle dit « Autoriser cet hôte d'extensions signé à effectuer cette requête POST pour cette mise en production vers cette destination avec cet identifiant », les utilisateurs pourront évaluer l'action qu'ils autorisent.

Mettez le signataire du processus en évidence, car cela permet de détecter la mauvaise application. Gardez le nom de l'extension visible si l'hôte le fournit, car il aide à reconnaître une opération attendue. Indiquez qu'il s'agit d'un contexte déclaré lorsque la passerelle ne peut pas le vérifier. Les personnes gèrent mieux l'incertitude lorsque l'interface l'énonce clairement que lorsqu'une étiquette soignée laisse croire à une garantie.

Commencez par recenser tous les identifiants accessibles depuis un hôte IDE. Pour chacun, notez l'approbation au niveau de l'hôte qu'il peut légitimement hériter, la forme d'action qui exige une nouvelle décision et les éléments précis que le journal d'audit conserve. Si la réponse à « quelle extension a fait cela ? » est une supposition, n'accordez pas l'autorité comme s'il s'agissait d'un fait.