L’approbation d’un script pour des agents IA peut-elle se fier à un interpréteur signé ?

Un interpréteur signé ne prouve pas quel script vous avez approuvé. Il prouve quelque chose de plus limité : le système d’exploitation a lancé un binaire d’interpréteur précis dont il a pu valider la signature. L’interpréteur peut ensuite lire n’importe quel nombre de fichiers modifiables, accepter du code source depuis une chaîne de commande, charger du code via un résolveur de paquets et agir avec des identifiants que le script ne détenait pas lui-même.

Cette distinction disparaît lorsqu’une fiche d’approbation affiche « Python » ou « Node » avec un badge de signature rassurant. J’ai vu des examinateurs approuver cette demande parce que le nom du binaire leur était familier, puis passer une partie pénible de l’après-midi à découvrir quel checkout du dépôt, lien symbolique, paramètre d’environnement ou préchargement de paquet avait réellement fourni le code. Les exécutables connus méritent une confiance adaptée aux exécutables. Ils ne rendent pas n’importe quel code source digne de confiance.

Un interpréteur signé identifie seulement l’interpréteur

La signature du code répond à une question de provenance concernant un fichier exécutable. Sur macOS, les outils codesign peuvent examiner la signature et l’exigence désignée d’un exécutable. Gatekeeper et les protections d’exécution de la plateforme utilisent des informations connexes lorsqu’ils évaluent un logiciel. Aucun de ces mécanismes n’affirme qu’un fichier Python transmis sur la ligne de commande vient du même développeur, qu’il n’a pas changé depuis son examen ou que ses imports sont inoffensifs.

Considérez ces deux invocations :

/usr/bin/python3 /Users/dev/work/release/publish.py
/usr/bin/python3 -c "import os; os.system('curl ...')"

L’identité de l’interpréteur peut être identique dans les deux cas. L’identité de la source est complètement différente. Le premier appel contient un chemin qui peut aider l’examinateur à trouver le code. Le second ne contient aucun fichier de script. Une demande qui réduit l’un ou l’autre appel à « Python signé demande un accès réseau » supprime précisément l’information dont une personne a besoin pour juger.

La documentation Python décrit des formes distinctes de ligne de commande pour exécuter un fichier, exécuter une commande avec -c, lancer un module avec -m et lire du code source depuis l’entrée standard. C’est le comportement normal d’un interpréteur, pas un défaut. L’erreur consiste à traiter ces formes comme si elles reposaient toutes sur un même programme stable et signé.

La même erreur apparaît avec l’identité du processus. Un système d’approbation peut vous indiquer correctement qu’un processus d’agent vient d’une autorité de signature que vous reconnaissez. Il ne peut toujours pas en déduire que chaque fichier local que le processus demande à un interpréteur d’exécuter mérite la même approbation. L’identité de l’appelant et celle de la source répondent à des questions différentes :

• L’identité de l’appelant demande qui a lancé la requête.
• L’identité de l’interpréteur demande quel binaire analyse la source.
• L’identité de la source demande quels octets l’interpréteur va analyser.
• L’identité de l’action demande quel hôte, quelle route d’API, quel compte ou quelle commande reçoit la requête produite.

Si une interface d’examen ne peut afficher que les deux premières, elle donne une fausse impression de précision. En pratique, ce sont la source et l’action qui déterminent si la demande est acceptable.

La cible de l’examen est un tuple d’exécution

L’examinateur a besoin d’une description stable de l’exécution exacte, pas d’un libellé convivial. J’appelle cette description un tuple d’exécution : l’interpréteur résolu, ses arguments, l’artefact source, le contexte d’exécution et l’action externe demandée. Si vous modifiez un élément important du tuple, vous obtenez une exécution différente qui nécessite une nouvelle décision.

Pour un appel Python fondé sur un fichier, le tuple minimal utile ressemble à ceci :

{
  "caller": {
    "pid": 48172,
    "signing_authority": "Example Development Team"
  },
  "interpreter": {
    "resolved_path": "/usr/local/bin/python3.12",
    "signing_identity": "Python Software Foundation",
    "sha256": "c44e...9a10"
  },
  "argv": ["/usr/local/bin/python3.12", "/private/var/run/gateway-src/publish.py"],
  "source": {
    "display_path": "/Users/dev/work/release/publish.py",
    "sha256": "6ab1...ee42"
  },
  "context": {
    "working_directory": "/Users/dev/work/release",
    "environment": {"DEPLOY_ENV": "staging"}
  },
  "requested_action": "POST https://api.example.invalid/releases"
}

Les abréviations des condensats ont leur place dans la fiche d’approbation, mais le condensat complet doit figurer dans le journal. Un examinateur a généralement besoin du chemin lisible ainsi que d’un diff ou d’un aperçu du code. Un enquêteur a besoin d’une valeur sans ambiguïté, qui pourra être comparée ultérieurement.

N’affichez pas toutes les variables d’environnement dans la fiche. Cela transforme une décision en test de vue. Capturez les valeurs qui influent sur la sélection du code, la résolution des commandes, les identifiants, le routage du proxy, le choix de la cible et les options de fonctionnalité. Pour Python, cela peut inclure PYTHONPATH, PYTHONHOME et un chemin de configuration fourni explicitement. Pour une exécution shell, il s’agit souvent de PATH, du répertoire courant et des variables interpolées dans la commande. Enregistrez l’environnement complet dans des données d’audit protégées si votre modèle de menace le demande, tout en présentant à la personne le sous-ensemble important.

C’est aussi à ce stade que les équipes confondent une deuxième distinction : la reproductibilité n’est pas une autorisation. Un lockfile, un commit Git ou une image de conteneur peut aider à reproduire ce qui s’est exécuté. Il ne dit pas si ce code doit appeler la production, supprimer une branche distante ou ouvrir une session SSH. Associez l’identité de la source à une demande d’action claire.

Python peut dissimuler du code derrière des lanceurs ordinaires

Python donne à une invocation de fichier ordinaire une apparence plus simple qu’elle ne l’est. python deploy.py indique où l’exécution commence, mais l’interpréteur peut importer des modules depuis le répertoire du script, les paquets installés, les chemins de recherche configurés et du code sélectionné par la logique de l’application. Un environnement virtuel peut aussi modifier l’interpréteur vers lequel un python non qualifié est résolu.

Commencez par résoudre l’exécutable avant d’évaluer sa signature. Le libellé python, python3 ou venv/bin/python n’est pas une identité. Un lanceur peut être un lien symbolique, un shim ou un autre binaire après une mise à jour de la chaîne d’outils. La passerelle doit résoudre l’objet que le noyau va lancer, examiner cet objet et enregistrer son chemin ainsi que son condensat.

Traitez ensuite le chemin de la source comme une aide à l’affichage, pas comme une limite de sécurité. Résolvez les liens symboliques vers un emplacement canonique pour le compte rendu, mais n’exécutez pas l’original mutable après l’examen. Un checkout de dépôt peut remplacer deploy.py sans changer le chemin. Un lien symbolique peut pointer vers une autre cible. Une vérification du chemin ne détecte à elle seule aucun de ces événements.

Voici une séquence pratique :

1. Lisez les octets du script demandé et calculez leur SHA-256.
2. Copiez ces octets dans un répertoire privé appartenant à la passerelle, avec des permissions restrictives.
3. Affichez le chemin fourni par l’appelant, le chemin canonique, le condensat et un aperçu du code pour l’approbation.
4. Lancez l’interpréteur vérifié avec la copie privée, puis enregistrez le résultat en l’associant à ce condensat.

Cette copie n’est pas une formalité inutile. Elle comble l’écart entre le moment de la vérification et celui de l’utilisation. Si l’examinateur a approuvé le condensat 6ab1...ee42, l’interpréteur doit lire les octets dont le condensat est 6ab1...ee42. Hacher le fichier du dépôt puis demander à Python de relire ce fichier plus tard laisse une fenêtre, petite mais réelle, pour un remplacement.

Les imports doivent eux aussi faire l’objet d’une décision. Si publish.py importe un fichier local release_helpers.py, un helper modifié peut changer le comportement même si le fichier d’entrée reste identique. L’option stricte consiste à créer un manifeste des sources qui inclut chaque module local autorisé pour cette exécution. Pour le travail courant, une option plus pratique consiste à mettre ensemble le script d’entrée et l’arborescence déclarée de son paquet local, à refuser les imports en dehors de cette arborescence intermédiaire et à exiger une nouvelle approbation lorsque le condensat du manifeste change.

Ne prétendez pas que cela détecte les imports dynamiques, les extensions natives, sitecustomize ou le code arbitraire récupéré pendant l’exécution. Ce n’est pas le cas. La fiche d’approbation doit nommer ces possibilités lorsqu’elles existent. Un script qui contient importlib.import_module(os.environ["PLUGIN"]) n’a pas obtenu la même approbation étendue qu’un script autonome simplement parce que tous deux commencent par le même interpréteur signé.

Le fichier d’entrée de Node n’est qu’une partie du programme

Node ajoute une autre couche d’ambiguïté. node task.js possède un fichier d’entrée, mais la résolution des modules peut sélectionner du code via package.json, les exports de paquets, les lockfiles, les liens symboliques et le répertoire courant. La documentation de la CLI Node décrit aussi des préchargements tels que --require et --import, qui peuvent exécuter du code avant le début du fichier d’entrée.

Un système d’examen doit donc afficher le vecteur complet des arguments, pas seulement le dernier chemin .js. Ces appels méritent une attention différente :

node tools/publish.mjs
node --import ./tools/setup.mjs tools/publish.mjs
node --require ./tools/patch.cjs tools/publish.mjs
node -e "require('child_process').execSync(process.argv[1])" "git push --force"

Un examinateur qui ne voit que tools/publish.mjs ne voit pas le code exécuté plus tôt dans les deuxième et troisième appels. Dans le dernier appel, il n’y a aucun fichier d’entrée examiné. La chaîne de commande est l’artefact source et doit être affichée, conservée et hachée comme telle.

La variable d’environnement NODE_OPTIONS de Node mérite la même attention. Node la documente comme un moyen de transmettre par l’environnement des options de ligne de commande autorisées. Si un processus peut y fournir des préchargements ou un comportement de débogage, une passerelle qui l’ignore a examiné une commande incomplète. Il n’est pas nécessaire d’effrayer les examinateurs avec chaque paramètre d’exécution, mais vous devez faire ressortir ceux qui chargent du code ou modifient le choix de la cible.

Les gestionnaires de paquets créent un autre piège. npm run publish ressemble souvent à une tâche nommée, mais son comportement vient d’un package.json mutable, de ses scripts, du lockfile, des hooks du gestionnaire de paquets et des binaires trouvés dans l’arborescence des dépendances du projet. Développez une tâche avant l’approbation. Affichez la commande résolue, la révision du projet ou le manifeste intermédiaire, ainsi que chaque hook de cycle de vie qui sera exécuté. Si cette expansion est impossible, demandez une approbation plus étroite ou refusez la demande. « Exécuter un script de paquet » ne décrit pas une action pertinente lorsque le fichier du paquet peut changer pendant ce temps.

Pour une automatisation Node reproductible, préparez un instantané contrôlé de l’espace de travail ou utilisez un artefact de build immuable. Le hachage de publish.mjs seul suffit uniquement lorsque le script n’a aucune dépendance locale et aucun chemin de préchargement. La plupart des projets un tant soit peu complexes ne remplissent pas cette condition.

Les chaînes shell doivent être traitées comme du code source

Les demandes shell échouent lors de l’examen lorsque quelqu’un les appelle des commandes au lieu de les considérer comme des programmes. sh -c analyse une chaîne source avec des expansions, substitutions, redirections, pipelines, fonctions et recherches de commandes. La chaîne peut être courte, mais elle peut invoquer une suite illimitée d’autres programmes.

Comparez ces demandes :

/bin/sh -c 'curl -fsS "$RELEASE_URL" | sh'
/bin/sh /private/var/run/gateway-src/release.sh

La première demande nécessite la chaîne de commande exacte, chaque valeur d’environnement importante et une explication de ce que reçoit le programme en aval. La seconde nécessite le même traitement du chemin et du contenu du script que Python ou Node. La signature de /bin/sh vous indique qui a fourni l’analyseur. Elle ne rend sûre aucune des deux entrées source.

N’approuvez pas une commande shell à partir de son premier verbe. git status peut être inoffensif dans un vecteur d’arguments précis, tandis que git -c credential.helper=... modifie les entrées que Git chargera. curl peut récupérer des données, écrire un fichier ou transmettre des octets à un autre interpréteur. L’examinateur doit voir suffisamment de syntaxe pour repérer les redirections et substitutions, ainsi que suffisamment de contexte d’exécution pour voir où les programmes sont résolus.

PATH est souvent oublié. Un script qui appelle deploy sans chemin absolu délègue la sélection de l’exécutable à l’environnement. Si la demande vient de l’espace de travail d’un agent, un attaquant capable de modifier cet espace peut placer un programme plus tôt dans PATH. Capturez si possible le chemin de l’exécutable résolu pour chaque sous-commande sensible. Lorsque l’évaluation complète du shell serait elle-même dangereuse ou trop incertaine, utilisez une interface de commandes limitée au lieu d’essayer de construire un analyseur shell parfait.

Ce dernier point va à l’encontre d’une recommandation répandue : « Autorisez simplement un shell signé et demandez une approbation à chaque appel. » Elle est populaire parce que le shell existe partout et que l’approbation semble simple. Elle est fausse, car une approbation unique n’a aucun objet source stable sauf si le système enregistre la chaîne exacte ou le script immuable ainsi que le contexte important. L’approbation à chaque appel peut encore valider la mauvaise chose avec une régularité remarquable.

Un condensat de contenu a besoin d’un fichier auquel il peut réellement être lié

Un hachage fournit une preuve sur des octets, pas la preuve que le programme prévu les utilisera. L’implémentation doit lier les octets examinés à l’exécution. C’est à cet endroit que de nombreuses conceptions pourtant soigneuses se brisent.

Le modèle dangereux est facile à reconnaître :

1. Read /workspace/scripts/publish.py
2. Calculate and display SHA-256
3. Wait for approval
4. Run python /workspace/scripts/publish.py

Entre les étapes 2 et 4, un autre processus peut modifier le fichier, remplacer un lien symbolique ou changer un répertoire monté. Le compte rendu de l’approbation reste exact concernant ce que l’examinateur a vu, mais ne dit plus rien d’utile sur ce qui a été exécuté.

Utilisez plutôt l’un de ces modèles :

• Copiez les octets examinés dans un répertoire d’exécution privé, configurez les permissions pour que le processus demandeur ne puisse pas les modifier, puis exécutez la copie.
• Exécutez un artefact immuable construit au préalable, dont le condensat a été examiné et enregistré.
• Conservez un objet fichier déjà ouvert pendant toute la vérification et l’exécution, uniquement si l’interpréteur et le système d’exploitation permettent d’exécuter cet objet précis sans résoudre à nouveau un chemin mutable.

Le modèle de la copie privée est généralement plus facile à expliquer et à auditer. Il vous fournit aussi un artefact stable pour l’examen d’un incident. Conservez le chemin d’affichage d’origine comme contexte, car les personnes doivent savoir quel fichier du projet a déclenché l’exécution, mais ne le confondez pas avec les octets exécutés.

Le hachage du contenu a des limites qui doivent rester visibles. Il ne peut pas décider si le code source est sûr. Il ne peut pas stabiliser les réponses distantes, les comportements dépendant du temps, les valeurs aléatoires ou le code chargé après le hachage. En revanche, il empêche une catégorie précise d’erreur d’approbation : examiner une version locale d’un script et en exécuter une autre. C’est une limite utile, à condition de la décrire honnêtement.

Utilisez SHA-256 ou un autre condensat cryptographique actuel avec un encodage fixe, et incluez toujours le nom de l’algorithme dans les enregistrements. Une simple chaîne hexadécimale crée de la confusion à l’avenir. Un enregistrement doit indiquer sha256:6ab1...ee42, et non seulement 6ab1...ee42.

Les fiches d’approbation doivent afficher les éléments réellement utilisables

Une bonne fiche d’approbation permet à un examinateur de décider rapidement sans cacher les faits qui peuvent changer la décision. Ne commencez pas par un hachage de fichier. Les personnes ne peuvent pas évaluer un hachage à l’œil. Commencez par l’action demandée et l’appelant, puis affichez l’interpréteur, l’emplacement de la source, l’état de la source et le contexte d’exécution important.

Pour une demande de déploiement, une fiche concise pourrait se présenter ainsi :

Caller: signed process from Example Development Team, PID 48172
Action: POST release data to api.example.invalid
Interpreter: /usr/local/bin/python3.12, signed by Python Software Foundation
Source: /Users/dev/work/release/publish.py
Reviewed bytes: sha256:6ab1...ee42
Execution copy: /private/var/run/gateway-src/6ab1...ee42/publish.py
Context: DEPLOY_ENV=staging, working directory /Users/dev/work/release

La fiche doit proposer l’aperçu du code ou un diff par rapport au dernier condensat approuvé. Pour un travail répété, un diff est souvent préférable, car il attire l’attention sur les lignes modifiées. Fournissez tout de même le code complet sur demande. Un aperçu tronqué de manière trompeuse vaut moins qu’aucun aperçu.

Évitez les libellés d’approbation vagues comme « Autoriser les outils de déploiement » ou « Autoriser l’accès Python ». Ils habituent les gens à cliquer en se fiant à une marque connue. Une décision doit aussi préciser sa durée de validité. Une exécution, une session de processus et une version d’artefact examinée sont trois portées différentes. Une approbation de session pour un processus d’agent peut réduire la lassitude liée aux demandes, mais tout script dont le condensat change doit déclencher une nouvelle décision sur la source avant de pouvoir réutiliser une autorité externe.

Cela diffère d’un moteur de règles. Vous n’avez pas besoin d’un langage permettant d’écrire des conditions comme « autoriser les scripts sûrs ». Vous avez besoin d’un objet d’examen fixe qui ne puisse pas s’élargir discrètement après l’approbation. Le système doit construire cet objet à partir des entrées résolues, l’afficher et y lier l’exécution.

Les limites des dépendances doivent être explicites

Le condensat d’un script d’entrée peut suffire uniquement lorsque la limite de code du programme se résume réellement à ce fichier. Considérez cela comme une exception, pas comme la règle. Les imports Python, les modules Node, les commandes shell source, les modèles, les fichiers de configuration et les plugins exécutables peuvent tous modifier le comportement après l’examen du point d’entrée.

Définissez la limite en fonction des conséquences de l’action. Pour une lecture à faible risque sur un service de développement, vous pouvez accepter un script d’entrée intermédiaire avec l’indication explicite qu’il peut importer des paquets installés. Pour une écriture en production ou une commande SSH, incluez les dépendances locales dans un manifeste, verrouillez les dépendances externes et refusez le téléchargement de code exécutable pendant l’exécution. Le compte rendu indique alors ce que vous entendiez par « le script ».

Un manifeste simple peut contenir des chemins relatifs et des condensats :

sha256  publish.py  6ab1...ee42
sha256  release_helpers.py  9d07...1a3c
sha256  config/targets.json  743e...64b1

La passerelle doit calculer ce manifeste à partir de copies intermédiaires ou d’une entrée de build contrôlée, au lieu d’accepter un manifeste fourni par le même espace de travail mutable. Si un projet définit un lockfile comme élément de sa limite, hachez aussi ce lockfile. Un lockfile n’est utile que si l’environnement d’exécution le respecte et si le processus examiné ne peut pas lui substituer une autre arborescence de dépendances.

Il arrive que l’exécution locale fondée sur un interpréteur soit trop large pour une décision en un clic. Si le code peut découvrir des plugins dans des répertoires arbitraires, récupérer et exécuter du contenu distant, ou écrire puis exécuter des scripts générés, découpez le travail. Approuvez un build qui produit un artefact immuable, examinez l’action déclarée de cet artefact, puis approuvez cette action. Cette limite supplémentaire coûte moins cher que la reconstitution d’une modification accidentelle de la production.

Les journaux doivent indiquer ce qui s’est exécuté, pas le nom utilisé par l’interface

Lorsqu’une action tourne mal, la première question utile est généralement « qu’est-ce qui s’est exactement exécuté avec cette autorité ? » Une entrée de journal qui indique « Python approuvé » ne peut pas répondre. Conservez le tuple d’exécution, la portée de la décision, l’interaction avec l’examinateur, les horodatages et le résultat observé. Masquez les secrets dans le compte rendu, mais ne masquez ni l’identité de l’artefact source ni celle de la cible de l’action.

Un enregistrement fiable relie les événements associés. L’entrée de session identifie le processus d’agent et son autorité. L’entrée d’action identifie l’interpréteur, le condensat de la source intermédiaire, les arguments, la cible et le résultat. Si un examinateur révoque une session, cet événement doit être relié à la même identité de session. Sinon, les opérateurs ne peuvent pas savoir si la révocation a arrêté le demandeur à l’origine de l’appel.

La preuve d’altération change la qualité du compte rendu. Un journal chaîné par hachage peut rendre détectable une modification ultérieure, mais il ne répare pas les champs manquants. Vérifiez la chaîne, puis demandez-vous tout de même si elle contient le chemin résolu, le condensat de la source, le contexte et l’action réelle. L’intégrité préserve les preuves, elle ne crée pas celles que le système n’a jamais recueillies.

Les journaux séparés de Sallyport sont utiles ici, car ils distinguent l’exécution de l’agent des appels HTTP ou SSH individuels, tout en projetant les deux depuis un journal d’audit chiffré et chaîné par hachage. Sa commande sp audit verify peut vérifier la chaîne hors ligne sur le texte chiffré. C’est la propriété recherchée pour contrôler si les preuves conservées ont été modifiées après coup.

Traitez les changements de source comme une nouvelle autorité

La valeur par défaut la plus sûre est simple : lorsque le condensat de la source change, exigez une nouvelle décision pour toute action externe. Ne reconduisez pas discrètement l’approbation d’un script parce que le chemin, l’interpréteur, le nom du projet ou la signature du processus semblent familiers.

Cette règle créera quelques demandes supplémentaires pendant le développement actif. C’est normal. L’examen du code modifie l’autorité lorsque le code peut utiliser un identifiant, modifier un service distant ou exécuter une commande SSH. La solution n’est pas de supprimer toutes les demandes. Il faut améliorer l’artefact examiné, préparer une source déterministe et accorder une session plus large au processus uniquement lorsque la source reste identifiée indépendamment.

Pour les équipes qui utilisent une passerelle d’action, concentrez le contrôle sur le point où les identifiants quittent la machine locale. L’agent doit demander un appel HTTP ou une commande SSH avec un compte rendu lié à la source, tandis que la passerelle conserve l’identifiant et renvoie le résultat. Cette organisation évite de remettre des secrets à un script mutable, mais elle exige toujours d’indiquer clairement quel code a demandé l’action.

Commencez par votre appel d’interpréteur le plus sensible. Résolvez le binaire, affichez tous les arguments, hachez et préparez les véritables octets de la source, enregistrez le contexte important et faites en sorte qu’un condensat différent entraîne une approbation différente. Une fois ce compte rendu en place, un interpréteur signé devient un élément utile d’une décision complète, au lieu d’une étiquette rassurante apposée sur un script inconnu.