Identité de l'agent et identité de l'identifiant : cessez de dissimuler les acteurs

Un agent IA qui détient un identifiant de production crée deux problèmes d'identité à la fois. L'agent peut agir au nom du compte, puis l'équipe doit faire comme si le nom du compte expliquait qui a agi. Ce n'est pas le cas. Une requête API authentifiée comme deploy-bot indique que quelqu'un possédait l'identifiant de deploy-bot. Elle ne dit pas si l'appelant était l'agent de programmation approuvé, un script shell copié, une dépendance malveillante ou un processus resté actif après un test.

Les équipes doivent identifier séparément le processus qui a demandé une action et le compte autorisé à l'exécuter. Ce n'est pas une question de présentation des journaux d'audit. Cela détermine si vous pouvez approuver une exécution précise d'un agent, l'arrêter sans perturber le travail indépendant, enquêter sur un mauvais déploiement et contenir un identifiant divulgué sans agir à l'aveugle.

Un identifiant établit une autorité, pas l'appelant

Un identifiant décrit l'autorité qu'un service accordera, tandis que l'identité de l'agent décrit le processus qui a demandé cette autorité. Les confondre rend toutes les décisions de sécurité ultérieures trop générales.

Prenons une requête qui supprime un objet dans un stockage cloud. L'API destinataire peut voir un jeton bearer et l'associer à un compte de service appelé release-publisher. Ce compte répond à une question d'autorisation : ce compte peut-il supprimer cet objet ? Il ne répond pas à la question d'attribution : quel processus local a utilisé le jeton, qui l'a lancé, quel code a-t-il exécuté et cette exécution a-t-elle été approuvée ?

Ces questions semblent similaires lorsque tout va bien, car le processus attendu et le compte ont souvent le même propriétaire. Sous pression, ils se séparent. Un développeur copie le jeton dans un environnement local. Un agent de programmation hérite de cet environnement. Un module lancé par l'agent le lit. Chaque requête apparaît toujours comme venant de release-publisher. La couche d'autorisation fonctionne exactement comme prévu, tandis que l'enquête perd la trace de l'acteur.

L'identité d'un identifiant a généralement une durée de vie longue et une fonction large. Il peut s'agir d'un jeton API, d'un identifiant privé SSH, d'un compte de service cloud ou du sujet d'un certificat client. L'identité du processus doit décrire quelque chose de bien plus précis : cet exécutable, signé par telle autorité, lancé dans tel contexte, pendant telle exécution.

Cette distinction a une conséquence pratique :

• Révoquer une session de processus lorsqu'une exécution d'agent n'est plus fiable.
• Désactiver ou renouveler un identifiant lorsque son secret a peut-être été divulgué.
• Modifier les permissions du compte lorsque l'autorité elle-même était excessive.
• Examiner l'enregistrement du processus pour comprendre ce qui s'est réellement passé.

Si un seul champ doit remplir ces quatre fonctions, il ne les remplira correctement aucune. Appeler un identifiant agent-prod-42 ne résout rien. Une meilleure étiquette ne transforme pas un jeton bearer en preuve de l'identité de celui qui le porte.

Quatre identités apparaissent dans une requête d'agent

Une action de production implique généralement au moins quatre identités. Un enregistrement d'audit doit toutes les conserver au lieu de les réduire à un nom de compte.

La première est celle de la personne ou du système responsable du lancement du travail. Il peut s'agir d'un développeur dans un terminal, d'un déclenchement de tâche CI ou d'une tâche planifiée. Cette identité indique qui a demandé l'exécution de l'agent et qui doit recevoir les alertes.

La deuxième est celle du processus de l'agent. Pour un agent de programmation local, les éléments utiles peuvent inclure le chemin de l'exécutable, l'autorité de signature, l'identifiant du processus, le processus parent, l'heure de lancement et un identifiant de session aléatoire attribué au démarrage. Dans un environnement conteneurisé, les éléments équivalents peuvent être le condensat de l'image, le document d'identité de la charge de travail, le nom de la charge de travail de l'orchestrateur et l'instance du pod ou de la tâche. Cette identité indique quel programme en cours d'exécution a demandé l'action.

La troisième est l'identité de l'identifiant. Il s'agit du compte de service, du principal SSH, du client OAuth ou de l'enregistrement du jeton API accepté par la destination. Elle indique ce que la destination autorisera.

La quatrième est l'identité de la cible : le nom d'hôte, le dépôt, le projet cloud, la base de données ou l'audience API concernée par la requête. Les équipes journalisent souvent un point de terminaison générique, puis découvrent que l'action a franchi une limite d'environnement qu'elles n'avaient jamais voulu autoriser.

Un enregistrement clair peut se présenter ainsi :

{
  "event": "http.request",
  "session_id": "ses_7zQ2...",
  "process": {
    "pid": 8421,
    "signing_authority": "Example Developer ID",
    "parent_pid": 8190,
    "launch": "interactive-terminal"
  },
  "credential_ref": "cred_release_publisher",
  "credential_subject": "release-publisher",
  "target": "api.example.internal",
  "operation": "POST /releases",
  "decision": "approved",
  "result": 201
}

La référence credential_ref pointe vers un enregistrement du coffre. Ce n'est pas le secret. Le bloc du processus fournit les éléments que le sujet de l'identifiant ne peut pas fournir. Un contrôleur peut maintenant voir qu'une session approuvée a utilisé release-publisher sur une cible donnée et distinguer cette exécution d'une autre utilisant le même compte par la suite.

Ne surchargez pas non plus le champ du responsable humain. La personne qui a demandé à un agent de mettre à jour la documentation n'est pas automatiquement celle qui a approuvé un déploiement de production que l'agent a ensuite tenté. Séparez le lancement, le processus, l'identifiant et la destination. Les zones d'ombre gênantes deviennent visibles, et c'est précisément le but.

Les jetons bearer effacent les éléments dont vous avez le plus besoin

Un jeton bearer est accepté parce que l'appelant le possède. Il ne peut donc pas établir quel processus le présente. C'est une propriété du mécanisme, pas un défaut des journaux de votre fournisseur d'API.

La RFC 6750 définit directement l'utilisation des jetons bearer : toute partie qui possède le jeton peut l'utiliser. Cette portabilité a facilité le déploiement des jetons, mais elle signifie aussi qu'une API ne peut pas distinguer l'agent approuvé d'un processus copié si vous n'ajoutez pas un contrôle séparé. La réponse courante, « nous avons placé le jeton dans un gestionnaire de secrets », protège le stockage au repos. Elle ne dit rien de ce qui se passe après qu'un processus a reçu la valeur.

Les bonnes pratiques actuelles de sécurité OAuth 2.0, RFC 9700, vont dans la bonne direction en recommandant, lorsque c'est pertinent, des jetons d'accès liés à l'émetteur, ainsi que des durées de vie courtes et une restriction d'audience. Cette liaison peut réduire la réutilisation d'un jeton, car le serveur de ressources vérifie la preuve fournie par le client prévu. Elle ne supprime pas le besoin d'identifier le processus qui contrôle cette preuve. Si un processus d'agent peut utiliser le matériel de preuve privé, un attaquant qui contrôle ce processus peut toujours agir comme le client.

Cette distinction compte particulièrement pour les agents IA, car leur environnement d'exécution est exceptionnellement poreux. Ils lisent des dépôts, exécutent des commandes, appellent des outils, inspectent des variables d'environnement et agissent parfois sur des instructions fournies dans des fichiers ou des commentaires de tickets. Un jeton exposé à l'agent ne reste pas dans une frontière de confiance propre simplement parce que l'équipe le destinait à un seul appel d'outil.

Évitez la recommandation courante consistant à donner à chaque agent un jeton dédié de longue durée et à considérer le problème comme réglé. Elle est populaire parce qu'elle produit des noms de comptes ordonnés et des tableaux de bord simples. Elle échoue lorsque l'agent peut lire le jeton, lorsqu'un autre processus peut lire le même environnement ou lorsque le compte persiste après la fin de l'exécution de l'agent. Des identifiants dédiés améliorent le suivi du périmètre d'impact, mais ils ne prouvent pas la provenance du processus.

Vous avez besoin de deux contrôles : empêcher l'agent de recevoir un secret réutilisable et conserver un enregistrement distinct du processus de l'agent qui a demandé chaque action. Le premier limite le vol. Le second rend l'approbation, la révocation et l'enquête assez précises pour être utiles.

L'identité du processus doit reposer sur des preuves qui résistent à une invite

L'identité d'un processus doit provenir de faits que le système d'exploitation ou l'environnement d'exécution peut déclarer, et non d'une chaîne fournie par l'agent dans une requête d'outil. Un agent qui déclare name: trusted-release-agent émet une affirmation, il ne fournit pas une preuve d'identité.

Sur un Mac géré, l'autorité de signature du code constitue un bon point de départ. Le système d'exploitation peut indiquer à une application de supervision quel exécutable signé a été lancé et quelle autorité l'a signé. Cela ne signifie pas que tout programme signé mérite une approbation. Cela signifie qu'un écran d'approbation peut afficher un fait plus difficile à falsifier qu'une étiquette fournie par le processus.

Sur un serveur, recherchez des éléments équivalents. Une identité de charge de travail délivrée par l'environnement d'exécution, un condensat d'image vérifié, un canal mutuellement authentifié ou une attestation du superviseur de processus peuvent relier une action à une instance de charge de travail. SPIFFE décrit ce modèle avec le SPIFFE Verifiable Identity Document et les SVID X.509 : la charge de travail reçoit une identité de son environnement, puis la présente à une autre charge de travail. Ce modèle est plus solide qu'une variable d'environnement partagée, car l'identité est limitée à une charge de travail.

Ne prenez pas un condensat d'image statique pour une identité complète du processus. Il identifie le contenu du code, mais une décision d'action utile doit aussi connaître l'instance en cours d'exécution et le contexte de lancement. La même image peut s'exécuter dans la tâche de production prévue, dans l'environnement expérimental d'un développeur ou dans une tâche contrôlée par un attaquant. La destination et la session font toujours partie de la décision.

Pour un travail local avec un agent, recueillez les éléments à la création de la session, puis liez les actions suivantes à cette session. Un enregistrement minimal peut inclure :

session_id: ses_7zQ2...
executable: /Applications/Agent.app/Contents/MacOS/agent
signing_authority: Example Developer ID
parent_process: /Applications/Terminal.app
started_at: 2025-03-08T14:03:19Z
owner: [email protected]

Les champs exacts varient selon le système d'exploitation. La règle ne change pas : le composant qui autorise une action doit recueillir lui-même les caractéristiques du processus. Il ne doit pas faire confiance à l'agent pour se décrire correctement après avoir reçu des données non fiables.

L'identité du processus a aussi ses limites. La signature du code ne prouve pas qu'un agent signé a suivi des instructions sûres. Un condensat d'image ne prouve pas que sa configuration est sûre. L'identité indique quel acteur vous avez approuvé et fournit un point d'appui pour la révocation. Elle ne rend pas à elle seule sûre une action risquée.

L'approbation doit être liée à une exécution, pas à un nom de compte

Une approbation humaine doit autoriser une session de processus précise pour une durée limitée, et non bénir définitivement tout processus qui utilisera ensuite un compte. Sinon, l'approbation devient une autorisation permanente déguisée.

La lassitude face aux approbations commence généralement par une mauvaise unité d'approbation. Les équipes demandent soit à une personne d'approuver chaque requête sans danger, ce qui l'habitue à cliquer machinalement, soit elles approuvent une fois un compte de service et ne montrent plus jamais d'invite utile. Aucune de ces options n'identifie le processus actif.

Utilisez une approbation de session lorsqu'un agent commence une exécution. Affichez les éléments que l'opérateur peut évaluer : exécutable ou nom de la charge de travail, autorité de signature ou condensat d'image, parent ou lanceur, canaux prévus et identifiant de session. Une fois la session approuvée, autorisez ses actions jusqu'à l'arrêt du processus ou à la révocation par l'opérateur. Un nouveau processus doit demander une nouvelle session, même s'il prévoit d'utiliser le même identifiant.

Réservez l'approbation action par action aux identifiants dont l'impact justifie une interruption. Un identifiant d'administrateur de base de données de production, une identité SSH pouvant atteindre les hôtes d'un parc ou un compte capable de publier des artefacts publics peuvent nécessiter une décision humaine à chaque utilisation. Ce n'est pas le cas d'un accès ordinaire en lecture. Le mécanisme d'approbation doit rendre cette différence explicite au lieu de l'enfouir dans un immense fichier de règles que personne ne consulte.

Cette organisation vous donne des options de confinement impossibles avec un accès partagé. Si un agent commence à se comporter de manière anormale, révoquez sa session. L'identifiant reste disponible pour un autre processus de publication approuvé. Si vous soupçonnez une divulgation du secret, désactivez aussi l'identifiant et examinez chaque session qui l'a référencé.

Sallyport applique directement cette séparation : un nouveau processus d'agent reçoit par défaut une autorisation propre à sa session, tandis que les identifiants restent dans son coffre chiffré et que les actions s'exécutent en dehors du processus de l'agent. Son invite de session met en avant l'autorité de signature du code du processus, c'est-à-dire l'élément dont l'approbateur a besoin avant d'autoriser une exécution.

L'enregistrement de l'approbation doit contenir à la fois la session du processus et la référence de l'identifiant utilisé ensuite. N'affichez pas la valeur de l'identifiant dans l'invite et ne la renvoyez pas dans le résultat d'une action. Un système qui masque un jeton dans l'interface mais le place dans la réponse d'un outil de l'agent l'a tout de même remis à l'agent.

L'injection des identifiants maintient les secrets hors de portée de l'agent

L'agent doit demander une action en indiquant une référence d'identifiant et une cible, tandis qu'un exécuteur de confiance injecte le secret uniquement au moment où il effectue l'appel HTTP ou SSH. L'agent reçoit le résultat, pas l'identifiant réutilisable.

Cette limite est beaucoup plus nette que de placer un jeton dans l'environnement shell en demandant à l'agent de ne pas l'afficher. Les variables d'environnement se retrouvent dans les processus enfants, les sorties de débogage, les rapports de plantage, les enveloppes de l'historique des commandes et les appels d'outils. La redaction aide à éviter un affichage accidentel après coup ; elle ne peut pas récupérer un secret qu'un processus a déjà lu.

Une requête d'action sûre contient assez de détails pour autoriser et exécuter l'appel sans contenir l'identifiant lui-même :

{
  "session_id": "ses_7zQ2...",
  "credential_ref": "cred_release_publisher",
  "channel": "http",
  "request": {
    "method": "POST",
    "url": "https://api.example.internal/releases",
    "headers": {"Content-Type": "application/json"},
    "body": {"version": "1.4.2"}
  }
}

L'exécuteur vérifie que la session reste approuvée, confirme que le coffre est disponible, récupère cred_release_publisher, l'injecte dans l'en-tête d'autorisation requis, effectue la requête et enregistre la décision et le résultat. Il doit renvoyer les données nécessaires à la tâche de l'agent, après avoir appliqué les mesures habituelles pour traiter les réponses sensibles.

Le même principe s'applique à SSH. L'agent peut demander git fetch ou une commande distante via un canal SSH, mais il ne doit pas recevoir l'identifiant privé sous la forme d'un bloc PEM ni un socket d'agent que n'importe quel processus enfant pourrait utiliser sans supervision. L'exécuteur peut utiliser l'identifiant privé pour la connexion et associer l'événement à la session de l'agent.

Sallyport prend actuellement en charge l'injection d'identifiants HTTP et les actions SSH via son assistant intégré. Un agent compatible avec MCP peut donc demander le travail sans détenir le secret API ou SSH. Cette conception ne rend pas chaque action sûre. Elle préserve la séparation nécessaire pour décider si le processus doit être autorisé à la demander.

Un jeton de déploiement partagé dissimule l'échec jusqu'au moment critique

Un identifiant partagé transforme un incident simple en exercice de reconstitution, car le même nom de compte apparaît sur chaque ligne de journal pertinente. L'échec commence souvent par un raccourci compréhensible.

Imaginez une équipe qui conserve PUBLISH_TOKEN dans le stockage des secrets de sa CI. Sa tâche de déploiement le lit, comme prévu. Un développeur l'exporte aussi localement pour reproduire un problème de publication. Plus tard, il lance un agent de programmation depuis ce shell, car l'agent doit examiner les scripts de déploiement. L'agent peut désormais appeler l'API de publication grâce à son environnement.

Une instruction dissimulée dans un fichier du dépôt demande à l'agent d'exécuter une commande qui téléverse une version préliminaire. La commande réussit. L'audit de l'API indique que release-publisher created release 1.4.2. Le journal CI ne montre aucune tâche correspondante. Le développeur affirme avoir seulement demandé à l'agent d'examiner les fichiers. Tout le monde peut s'accorder sur ces faits, mais aucun ne permet d'identifier le processus qui a effectué l'appel.

L'équipe renouvelle souvent PUBLISH_TOKEN. Cela empêche une réutilisation si le jeton a été divulgué, mais interrompt aussi la tâche CI légitime et impose une réparation précipitée. L'équipe peut ensuite accuser le développeur, l'agent ou l'instruction du dépôt sans preuve. Le nom du compte ne permet pas de distinguer une exécution CI d'une action de l'agent local.

Modifions maintenant la conception. L'identifiant de publication reste dans un coffre contrôlé par un exécuteur d'actions. L'agent ouvre une session qui enregistre son autorité de signature et son terminal parent. Il demande l'action de téléversement via cette session. L'exécuteur enregistre la décision d'approbation, la référence de l'identifiant, l'API cible, le chemin de la requête et le statut de la réponse.

Lorsque le téléversement suspect survient, le dossier d'incident répond immédiatement aux premières questions utiles : il vient d'une session d'agent locale, cette session a commencé depuis un terminal donné, elle a reçu une autorisation à une heure précise et elle a utilisé l'identifiant de publication pour une requête POST. L'opérateur révoque cette session. La CI continue, car son processus identifié séparément n'a pas été révoqué. Si l'instruction du dépôt a pu exposer d'autres secrets, l'équipe peut toujours renouveler l'identifiant, mais elle le fait parce que les éléments disponibles le justifient, et non parce qu'elle ne dispose d'aucun autre contrôle.

La différence n'est pas une prévention parfaite. Un agent approuvé peut toujours demander une action que l'humain regrettera ensuite d'avoir autorisée. La différence est que le système conserve un acteur, une décision d'autorisation et un mécanisme d'arrêt ciblé. Cela suffit à raccourcir un incident au lieu de le transformer en débat.

Les journaux d'audit doivent relier les identités sans stocker les secrets

Une piste d'audit doit permettre de relier une session de processus, une référence d'identifiant et une action externe tout en gardant les secrets hors de l'enregistrement. Si ces données vivent dans des produits séparés sans identifiant d'événement commun, la réponse aux incidents devient une corrélation manuelle sous pression.

Écrivez un événement pour la décision de session et un autre pour chaque action. Donnez-leur le même session_id, et attribuez à chaque action son propre identifiant d'événement. Stockez une référence d'identifiant et son sujet si celui-ci peut être conservé sans risque, mais ne stockez jamais le jeton bearer, l'identifiant privé ou l'en-tête d'autorisation brut.

Un enregistrement d'action utile comprend la cible normalisée, la méthode ou la commande distante, le condensat de la requête lorsque les corps peuvent contenir des données sensibles, la décision, le statut de la réponse et les horodatages. Pour SSH, enregistrez l'hôte, l'utilisateur distant, la commande demandée et le résultat de sortie. Pour HTTP, enregistrez la méthode, l'hôte, le chemin et le statut. Ne capturez le corps brut que si vos règles de conservation et de traitement des données l'autorisent.

La preuve d'absence de modification est importante, car le processus qui effectue une action peut ensuite être accusé de l'avoir dissimulée. Une chaîne de hachage rend détectables la suppression ou la réorganisation lorsqu'un enquêteur dispose de la séquence complète. Elle ne rend pas un événement véridique. Si votre collecteur accepte un nom de processus fourni par l'agent, un journal parfaitement chaîné conservera cette fausse déclaration pour toujours. Collectez d'abord les éléments d'identité à la frontière de supervision, puis protégez l'enregistrement.

Un processus de vérification simple doit fonctionner indépendamment du contenu du coffre. Le vérificateur lit chaque bloc d'événement chiffré, vérifie que le hachage précédent enregistré correspond au hachage de l'événement antérieur, recalcule le hachage actuel et signale la première position rompue. La sortie doit indiquer la position dans la séquence sans exposer de secrets :

$ audit verify events.log
verified: 184 events
chain: valid
first_event: evt_01J...
last_event: evt_01K...

Si la vérification échoue, conservez les fichiers originaux avant toute tentative de réparation. Un enregistrement manquant peut signaler une corruption, une écriture interrompue, un mauvais traitement lors de l'export ou une modification délibérée. La chaîne révèle l'incohérence ; vos journaux environnants et vos contrôles de stockage en expliquent la cause.

Séparez les identités avant d'ajouter de l'automatisation

Les équipes peuvent adopter ce modèle sans reconstruire toutes leurs intégrations API. Commencez par les identifiants qui peuvent modifier l'état de la production, publier des artefacts, accéder aux données clients ou se connecter via SSH. Ce sont les comptes qui provoquent les incidents les plus difficiles lorsqu'un processus d'agent en hérite.

Commencez concrètement :

1. Dressez la liste de chaque sujet d'identifiant, des services qu'il peut atteindre et de tous les processus qui reçoivent actuellement son secret.
2. Supprimez les valeurs secrètes réutilisables des invites, de la configuration et des environnements des processus d'agents.
3. Définissez les éléments du processus que vous pouvez recueillir au point où les actions sont autorisées.
4. Attribuez un identifiant de session à chaque exécution d'agent et journalisez-le à côté de la référence d'identifiant pour chaque action.
5. Testez le confinement en révoquant une session tandis qu'une autre charge de travail approuvée continue d'utiliser le même compte.

Ce dernier test révèle rapidement l'erreur courante. Si vous ne pouvez arrêter un agent qu'en désactivant le compte partagé, vous n'avez pas séparé l'identité de l'agent de celle de l'identifiant. Vous avez donné un nom sympathique à un risque partagé.

Ne commencez pas par un moteur de règles tentaculaire. La plupart des équipes ont besoin de quelques décisions claires : le coffre est-il disponible, cette session de processus est-elle approuvée et cet identifiant nécessite-t-il une approbation pour cette action ? La partie la plus complexe est la discipline opérationnelle : ne plus envoyer de secrets dans les processus d'agents, recueillir des éléments fiables sur les processus et refuser de traiter le nom d'un compte de service comme celui d'une personne ou d'un programme.

Lorsque la prochaine action douteuse survient, exigez une réponse à deux questions distinctes : quel processus l'a demandée et quelle autorité l'a exécutée ? Si vos enregistrements ne permettent pas de répondre aux deux, corrigez cela avant d'accorder à un autre agent un accès à la production.