Signature de code pour les agents IA : approuver les sessions avec des éléments de preuve

Une demande d'approbation qui dit seulement « l'agent IA demande un accès » demande à un humain de donner son accord à une inconnue. Sur une machine de développement partagée, c'est ainsi que quelqu'un approuve un script copié, un terminal oublié ou un processus lancé par la mauvaise personne. La question utile est plus précise : quel processus exécutable fait la demande, qui l'a signé, comment est-il arrivé ici et que peut-il faire pendant cette exécution ?

La signature de code fournit des éléments pour prendre cette décision. Elle peut relier un programme en cours d'exécution à une autorité de signature et indiquer si le contenu signé a changé. Elle ne peut pas dire si un agent a reçu une instruction malveillante, si un éditeur de confiance a publié une mauvaise version ou si l'action de production demandée est pertinente. Les équipes rencontrent des problèmes lorsqu'elles prennent une signature pour une garantie de comportement.

Sur un Mac partagé, utilisez l'autorité de signature pour reconnaître les clients d'agent connus, refuser les éléments inattendus et faire expirer chaque approbation avec le processus qui l'a méritée. Ajoutez à cela une séparation claire des comptes, des identifiants limités et des enregistrements permettant de reconstituer à la fois l'approbation et l'appel qui a suivi.

Une signature identifie le code, pas l'intention qui le sous-tend

Une signature de code peut établir qui a signé un élément de code précis et si macOS peut encore vérifier son contenu signé. Elle n'établit pas que ce code mérite d'accéder à vos systèmes. Cette distinction doit rester visible dans chaque parcours d'approbation.

La documentation Apple sur la signature de code, notamment la note technique TN2206, décrit les signatures comme un moyen de valider le code et d'exprimer une exigence désignée, que macOS peut ensuite utiliser pour reconnaître le même code. Cette exigence est importante, car elle est plus précise qu'un nom de fichier. Un exécutable appelé agent peut être copié n'importe où et renommé. Son identité signée reste mieux définie si la chaîne de signature et l'exigence sont toujours valides.

Cette continuité répond à une question pratique : « Est-ce bien le client que nous avons décidé d'autoriser ? » Elle ne répond pas aux questions tout aussi concrètes suivantes :

• L'agent a-t-il reçu des instructions qui ne devraient jamais atteindre la production ?
• Un utilisateur a-t-il démarré ce processus volontairement, depuis le répertoire de projet attendu ?
• Le processus contient-il une extension, un plugin ou une configuration qui modifie son comportement ?
• L'appel d'API demandé correspond-il à cette tâche ?
• L'identifiant utilisé pour l'appel possède-t-il davantage de droits que nécessaire ?

On s'appuie souvent sur le nom de l'éditeur comme s'il suffisait à rendre une décision. Ce n'est pas le cas. Une autorité de signature indique qui contrôlait l'identifiant de signature utilisé pour cet artefact. Un grand éditeur peut signer de nombreux programmes. Une petite équipe interne peut signer une version parfaitement adaptée. Votre décision doit comparer l'identité observée à une liste d'autorisation que votre équipe sait expliquer, et non à la vague impression que l'émetteur est familier.

Il existe aussi une limite facile à manquer : la signature vérifie le code qui a été signé. Elle ne couvre pas automatiquement tout ce qu'un processus lira ensuite. Les fichiers de configuration, les fichiers d'instructions, les variables d'environnement, les données du dépôt, les extensions téléchargées et les réponses distantes peuvent tous modifier le comportement d'un programme correctement signé. Si vous approuvez un agent parce que son binaire vous semble familier, vous devez tout de même contrôler ses actions.

Lisez une fiche d'approbation comme un relevé d'attribution

Une fiche d'approbation doit donner à l'opérateur suffisamment d'informations pour attribuer une demande à un véritable processus avant de l'approuver. L'autorité de signature doit apparaître en premier, car elle est plus difficile à falsifier qu'un libellé de processus, mais elle doit être affichée à côté du chemin du processus et des détails de la session.

Pour un processus qui demande un accès sur une machine partagée, je veux voir ces éléments au même endroit :

• L'identité de l'exécutable ou de l'application et son chemin local complet.
• L'autorité de signature ou l'exigence désignée utilisée pour le reconnaître.
• L'identifiant du processus et le processus parent, afin de voir ce qui l'a lancé.
• Le compte utilisateur macOS qui le possède.
• Le canal d'action et la destination, par exemple un hôte d'API ou un hôte SSH.

Les trois premiers éléments permettent de repérer des problèmes différents. Un nom d'affichage familier associé à un chemin inattendu indique souvent un binaire copié ou un wrapper. Un chemin familier associé à une autorité inconnue peut signifier que quelqu'un a recompilé ou remplacé le programme, ou qu'un lien symbolique pointe ailleurs. Un exécutable familier lancé par un parent inattendu peut indiquer qu'un autre outil d'automatisation l'a démarré à la place du développeur qui regarde la demande.

Sur un Mac partagé, le compte utilisateur n'est pas un détail décoratif. Si deux ingénieurs utilisent le même compte, une approbation ne dit presque rien sur la personne qui a lancé l'agent. La machine peut toujours indiquer quel processus a effectué l'appel, mais votre équipe a perdu une séparation humaine claire avant même le début du parcours d'approbation. Des comptes macOS distincts coûtent moins cher qu'une discussion sur l'historique du terminal après un incident.

N'apprenez pas aux utilisateurs à approuver en se basant uniquement sur un logo, un nom de commande court ou une chaîne d'autorité. Apprenez-leur à reconnaître un ensemble complet attendu : client d'agent approuvé, autorité de signature attendue, emplacement local attendu, leur propre compte et destination liée à la tâche. Une fiche qui omet la plupart de ces éléments transforme une approbation en un clic en simple devinette.

Inspectez l'exécutable avant d'en faire une identité approuvée

Inspectez l'application ou l'exécutable exact que votre équipe prévoit d'approuver avant que quiconque ne se fie à son autorité de signature dans un flux réel. Faites-le lors de la configuration, consignez le résultat attendu dans votre guide interne et répétez la vérification lorsque vous mettez volontairement le client à niveau.

Sur macOS, codesign peut afficher les détails de la signature. Sa sortie détaillée est envoyée sur la sortie d'erreur standard, alors redirigez-la si vous souhaitez conserver une trace de l'examen :

codesign -dv --verbose=4 /Applications/ApprovedAgent.app 2\u003e\u00261

La sortie contient généralement des champs comme ceux-ci :

Executable=/Applications/ApprovedAgent.app/Contents/MacOS/ApprovedAgent
Identifier=com.example.approved-agent
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=...
Authority=Developer ID Application: Example Developer (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=...

Conservez ensemble l'Identifier, l'Authority de niveau final et le TeamIdentifier. Le Team ID seul est une mauvaise règle d'approbation, car une organisation peut signer plusieurs applications. L'identifiant seul est plus faible, car quelqu'un peut créer un programme non signé avec le même identifiant de bundle. C'est la chaîne complète qui rend l'affirmation utile.

Vérifiez ensuite le contenu signé :

codesign --verify --deep --strict --verbose=2 /Applications/ApprovedAgent.app

Un résultat positif est souvent silencieux. Un échec signale un composant imbriqué modifié ou un autre problème de signature. --deep demande à codesign de parcourir récursivement le code imbriqué. C'est utile pour l'inspection, mais ne le prenez pas comme la preuve que chaque composant inclus respecte votre politique de sécurité. Apple précise que la vérification approfondie s'applique récursivement et peut masquer le fait que la conception de la signature interne d'un bundle mérite un examen direct.

Pour une application obtenue en dehors de votre canal logiciel géré, demandez également à Gatekeeper de l'évaluer :

spctl --assess --type execute --verbose=4 /Applications/ApprovedAgent.app

spctl et codesign répondent à des questions proches, mais différentes. codesign vérifie les signatures par rapport à l'artefact. spctl demande si la politique d'évaluation du système l'accepte. Une évaluation réussie est un signal de provenance utile. Elle ne signifie pas que les commandes, scripts ou comportements distants de l'application sont sûrs pour la production.

Consignez le chemin que vous avez examiné. Si quelqu'un approuve plus tard /Users/alex/bin/agent parce que son libellé ressemble à celui de l'application examinée dans /Applications, il n'a pas répété cette vérification. Le chemin fait partie des éléments de preuve.

La signature d'un interpréteur ne valide pas le script qu'il exécute

Un terminal, un environnement d'exécution ou un shell signé ne peut pas garantir un script arbitraire qui lui est transmis au lancement. C'est la faille derrière de nombreuses approbations qui semblent raisonnables en conversation, mais échouent dans la pratique.

Prenons le cas d'un développeur qui démarre un agent avec une commande comme celle-ci :

/usr/bin/python3 /Users/dev/work/demo/tools/agent_runner.py

Le Python système peut avoir une signature connue. Ce fait vous renseigne sur le binaire de l'interpréteur. Il ne dit rien sur agent_runner.py, les fichiers qu'il importe depuis le dépôt, le fichier .env qu'il lit ou les instructions transmises par l'entrée standard. Si l'interface d'approbation identifie uniquement python3, un attaquant doit modifier le script ou l'état du projet, pas l'interpréteur.

Le même problème existe avec node, les shells, les extensions d'éditeur et les exécuteurs d'automatisation génériques. Une règle générale telle que « approuver les processus signés par l'éditeur de cet environnement d'exécution » permet d'approuver quantité de comportements que personne n'a examinés. Elle est populaire parce qu'elle réduit les frictions, mais elle est inadaptée à tout canal pouvant atteindre des identifiants importants.

Choisissez l'un des deux modèles et indiquez clairement celui retenu par votre équipe. Le modèle le plus strict approuve un client d'agent signé et conçu pour cet usage, dont le processus de session est le programme qui demande l'accès. Le modèle plus souple autorise les interpréteurs, mais traite chaque lancement de script comme une session distincte et affiche le chemin du script, le répertoire du projet, les arguments et le processus parent à côté de l'autorité de l'interpréteur.

Vous pouvez inspecter le contexte de base d'un processus en cours avec des outils standard :

ps -p 4821 -o pid=,ppid=,user=,command=
ps -p 4812 -o pid=,ppid=,user=,command=

La première commande peut afficher le processus de l'agent et la seconde son parent. Comparez la ligne de commande avec le travail du développeur. Si l'enfant provient d'un terminal ouvert dans le projet attendu, les éléments concordent. S'il vient d'un planificateur sans surveillance, d'un module de navigateur ou d'un autre agent, cessez de considérer la demande comme une approbation ordinaire de développeur.

Pour un client basé sur un script, faites du condensat du script un élément de l'enregistrement d'approbation. Une simple vérification locale suffit à rendre les changements visibles :

shasum -a 256 /Users/dev/work/demo/tools/agent_runner.py

Un condensat ne rend pas un script fiable. Il donne à votre équipe une réponse concrète lorsqu'une personne demande si le script approuvé a changé entre deux exécutions. Conservez le condensat attendu uniquement pour une version examinée ou un état de projet contrôlé. Ne créez pas un rituel fondé sur la copie de condensats depuis des messages de discussion.

Les machines partagées ont besoin de comptes distincts avant les règles d'approbation

Un Mac de développement partagé reste gérable lorsque chaque personne utilise un compte distinct et que chaque exécution d'agent a un responsable clair. Si tout le monde utilise la même session, l'autorité de signature ne peut pas réparer l'absence d'attribution.

Créez un compte macOS distinct pour chaque développeur et évitez d'utiliser au quotidien un compte administrateur commun. Le processus de l'agent doit s'exécuter sous le compte de la personne qui l'a démarré. Ses fichiers de projet, son historique de terminal, ses variables d'environnement et ses décisions d'approbation ont alors un responsable identifiable. Des dépôts partagés ne nécessitent pas des comptes de système d'exploitation partagés.

Une configuration viable sépare aussi les destinations sensibles. Donnez au développement, à la préproduction et à la production des identifiants distincts, avec des libellés qui indiquent clairement l'intention à l'opérateur. Une approbation pour inventory-staging ne doit pas sélectionner discrètement l'identifiant de production parce que les deux pointent vers le même client d'API. Si le nom des identifiants masque l'environnement, l'utilisateur ne peut pas faire un choix éclairé au moment décisif.

L'accès physique reste important. Une personne devant un Mac partagé déverrouillé peut démarrer un processus sous le compte actif et attendre que son propriétaire clique sur une demande d'approbation. Verrouillez l'écran en vous éloignant, exigez une nouvelle connexion après la mise en veille et évitez de laisser un terminal privilégié ouvert dans un espace commun. Ce sont des contrôles ordinaires, et c'est précisément pourquoi les équipes les ignorent jusqu'au jour où elles doivent réparer un problème évitable.

Ne tentez pas de résoudre le risque lié aux machines partagées en publiant une immense liste d'autorités de signature approuvées. Cette liste finit par inclure les éditeurs, environnements d'exécution, gestionnaires de paquets, outils de compilation et applications auxiliaires. Elle signifie alors seulement que la machine sert au développement. Gardez la liste des agents capables de demander des actions externes très limitée et documentez la raison de chaque identité.

L'approbation d'une session doit être liée à un processus, pas rester attachée à une personne

Une approbation de session doit autoriser un processus d'agent observé pendant toute la durée de ce processus, puis expirer lorsqu'il se termine. C'est un compromis utile entre demander une décision pour chaque requête inoffensive et accorder une permission permanente qui survit au travail effectué.

La limite du processus compte davantage qu'un délai fixé au calendrier. Un agent qui se termine puis redémarre crée un nouveau contexte d'exécution. Il peut avoir un autre répertoire de travail, un binaire modifié, des extensions différentes, un parent différent ou une autre personne au clavier. Exiger une nouvelle autorisation au redémarrage donne à l'opérateur une nouvelle occasion de voir ces changements.

C'est là que la signature de code trouve sa place. Le parcours d'approbation peut afficher l'autorité en premier, car elle aide l'opérateur à reconnaître un client attendu, tandis que la liaison à la session empêche cette reconnaissance de devenir une autorisation illimitée. Si le processus de l'agent se termine, l'approbation doit disparaître avec lui. Si un opérateur observe un comportement suspect, il doit pouvoir révoquer immédiatement la session avant d'examiner la signature dans le détail.

Séparez l'autorisation de l'authentification. Touch ID ou un mot de passe peut prouver que l'utilisateur macOS présent a approuvé l'action. Cela n'identifie pas le processus. La signature de code peut aider à identifier le processus. Aucune des deux ne décide si la destination et l'action sont appropriées. Une bonne fiche d'approbation présente ces trois types d'éléments sans prétendre qu'ils sont interchangeables.

Pour le travail courant sur un dépôt, une décision de session peut couvrir des opérations de lecture répétées sur une API de développement. Pour une opération qui modifie une configuration de déploiement, renouvelle des identifiants, supprime des enregistrements ou ouvre une connexion SSH vers un hôte de production, exigez une nouvelle décision pour cet appel. La friction doit apparaître lorsque la conséquence change, et non au hasard après l'expiration d'un minuteur.

L'autorité de signature n'empêche pas les problèmes qu'on attend d'elle

Une chaîne de signature valide ne peut pas empêcher un client de confiance de recevoir une mauvaise instruction, un compte de développeur compromis de signer du code malveillant ou un processus approuvé d'effectuer une demande imprudente. Traitez ces scénarios comme des chemins d'échec distincts et placez le contrôle adapté devant chacun.

Le premier chemin est l'attaque par instructions du dépôt ou de la demande. Un assistant de code lit un commentaire malveillant qui lui ordonne d'exfiltrer un fichier de configuration via une requête HTTP. L'exécutable peut être exactement le client approuvé et correctement signé. L'approbation doit afficher la destination et le canal demandé, car la signature ne fournit aucune information sur l'instruction suivie.

Le deuxième chemin est celui d'une mise à jour légitime que votre équipe n'a pas examinée. Un éditeur peut signer une nouvelle version avec la même autorité. Si vous approuvez toute version future de cette autorité sans examiner son identité et sa source, vous avez fait de la propriété de l'éditeur toute votre politique. Cela peut convenir à un outil local à faible risque. Ce n'est pas suffisant pour un agent capable d'utiliser des identifiants de production.

Le troisième chemin est la manipulation d'un processus local. Une application signée peut charger un plugin, hériter d'une variable d'environnement ou s'exécuter avec un processus parent qui fournit des arguments inattendus. Les protections de macOS réduisent certaines formes de manipulation, mais un système d'approbation doit tout de même afficher le contexte réel du processus. Lorsque les éléments ne concordent pas, refusez la demande et inspectez la machine. N'inventez pas d'explication rassurante parce que la chaîne d'autorité vous est familière.

Le quatrième chemin est celui des privilèges excessifs. Un client correctement identifié peut utiliser un identifiant qui lui donne des droits bien supérieurs à ceux nécessaires. Limitez les identifiants à l'API, l'hôte, le dépôt et l'environnement dont l'agent a besoin. La signature de code peut vous dire quel client a utilisé un identifiant, mais elle ne peut pas réduire les droits de cet identifiant après coup.

C'est pourquoi recommander que « signé signifie sûr » est dangereux. Cette formule semble simple et produit moins de demandes. Elle encourage aussi les approbations sans destination, résumé de l'action ni limite de session. Un signal de signature aide un humain à distinguer du code connu d'un code inconnu. Il ne doit jamais effacer le reste de la décision.

L'approbation à chaque appel concerne les identifiants irréversibles ou à fort impact

Exigez une décision humaine à chaque utilisation d'un identifiant lorsqu'une seule requête peut entraîner une conséquence qu'une approbation de session ne devrait pas autoriser silencieusement. Le seuil dépend de l'impact de l'action, pas de l'apparence fiable de l'exécutable de l'agent.

Utilisez une approbation à chaque appel pour les identifiants capables d'écrire ou de supprimer des données de production, de modifier des identités ou des droits, de créer des engagements externes, de publier des logiciels ou d'ouvrir un environnement SSH sensible. L'opérateur doit voir le libellé de l'identifiant et la destination au moment de l'utilisation. Un message générique tel que « utiliser le secret » lui demande de se souvenir de trop de choses sous pression.

Gardez les tâches à faible conséquence utilisables. Un développeur qui doit approuver chaque lecture d'une API de test apprendra à cliquer sans lire. Ce comportement neutralise le contrôle et rend les demandes importantes plus faciles à manquer. L'approbation de session convient bien lorsque l'agent effectue un travail répétitif et limité vers une cible de développement et que l'identité du processus est attendue.

L'échelle de décision doit être assez simple pour être expliquée après une semaine difficile. D'abord, un coffre-fort verrouillé refuse toute action. Ensuite, un nouveau processus d'agent a besoin d'une autorisation de session. Enfin, certains identifiants nécessitent une approbation à chaque utilisation. N'enfouissez pas ces décisions dans un langage de politique personnalisé que seule une personne sait interpréter. Les exceptions cachées sont la cause du déclin des règles sur les machines partagées.

Sallyport applique directement ce modèle à trois contrôles : un coffre-fort verrouillé refuse les actions, un nouveau processus d'agent demande par défaut une autorisation de session et un identifiant choisi peut exiger une approbation à chaque utilisation. Sa fiche d'approbation affiche en premier l'autorité de signature du processus, ce qui est le bon point de départ lorsque plusieurs personnes partagent un Mac.

Auditez séparément l'approbation et l'appel

Vous avez besoin d'enregistrements distincts pour les sessions d'agents et les actions individuelles, car aucun des deux ne peut répondre seul à toutes les questions d'un incident. Un enregistrement de session explique quel processus a reçu l'autorisation et quand celle-ci a pris fin. Un enregistrement d'action explique ce que le processus a tenté après l'approbation, sur quel canal ou quelle destination, et quel résultat a été renvoyé.

Une séquence d'enquête utile ressemble à ceci :

1. Trouvez l'enregistrement de session du processus qui a demandé l'accès.
2. Vérifiez le compte utilisateur, le chemin de l'exécutable, l'autorité de signature, le processus parent et l'heure de l'approbation.
3. Trouvez les appels effectués pendant cette session et comparez les destinations avec la tâche attribuée.
4. Révoquez la session si elle est encore active, puis désactivez ou renouvelez l'identifiant concerné si les appels indiquent un usage abusif.
5. Conservez les enregistrements avant de modifier les fichiers du projet ou de réinstaller le client.

L'ordre compte. Les équipes commencent souvent par lire le code et perdent les éléments montrant ce qui s'est réellement passé. Établissez d'abord la séquence d'autorisation et d'action. Examinez ensuite l'exécutable, l'état du dépôt, l'historique du shell et la configuration pertinente.

Les éléments permettant de détecter une falsification ont ici leur utilité. Un enregistrement d'audit qu'un processus local peut réécrire apporte peu de garanties lorsque ce processus fait partie de l'événement examiné. Le chaînage de condensats permet de détecter une modification ou une suppression dans la séquence enregistrée, même s'il ne prouve pas que tous les événements possibles ont été capturés. Soyez précis sur cette limite. La détection des falsifications n'est pas l'omniscience.

Sallyport regroupe les journaux de session et d'activité dans un journal d'audit chiffré et chaîné par hachage, et sp audit verify vérifie la chaîne hors ligne sans nécessiter d'identifiant du coffre-fort. La vérification régulière devient ainsi pratique après un incident ou avant de transmettre les enregistrements à un autre examinateur.

Rendez les décisions d'approbation reproductibles plutôt que personnelles

Une équipe doit pouvoir expliquer pourquoi une session d'agent a été approuvée sans dépendre du souvenir de la personne qui a cliqué. Rédigez un court profil d'approbation pour chaque client d'agent autorisé et conservez-le près des instructions d'utilisation du dépôt.

Le profil doit indiquer le chemin attendu de l'application ou de l'exécutable, l'identifiant, l'autorité de signature, le processus parent habituel, les comptes utilisateurs prévus, les environnements autorisés et les identifiants qui nécessitent une décision à chaque appel. Ce n'est pas de la bureaucratie pour la forme. Cela donne à un nouvel ingénieur une référence observable et à la personne d'astreinte un moyen de refuser une demande inhabituelle sans débat subjectif.

Réexaminez le profil lorsque l'un de ces éléments change : le client d'agent est mis à jour, l'équipe adopte un nouveau wrapper d'environnement d'exécution, un identifiant obtient un droit supplémentaire ou un flux autrefois local atteint un service partagé. Si l'identité de signature change, arrêtez-vous et vérifiez cette modification auprès de la source logicielle à laquelle votre équipe fait confiance. Ne normalisez pas une autorité inattendue en cliquant une fois et en prévoyant de l'examiner plus tard.

Organisez un exercice d'échec volontaire sur le Mac partagé. Démarrez le client approuvé depuis le compte attendu et vérifiez l'autorité affichée et le comportement de la session. Lancez ensuite un script non approuvé via un interpréteur signé, démarrez le client depuis un autre compte et demandez un identifiant marqué pour une approbation à chaque appel. Dans chaque cas, le comportement attendu doit être évident pour l'opérateur. Si les demandes se ressemblent trop, améliorez les informations affichées avant qu'une véritable erreur ne se produise.

La signature de code est utile parce qu'elle remplace un nom de processus vague par des éléments vérifiables. Limitez son rôle à cela. Approuvez le processus connu pour la tâche en cours, gardez les droits des identifiants réduits et rendez une session suspecte facile à révoquer tant que les éléments de preuve sont encore disponibles.