Que faire si des secrets sont transmis à un agent IA : révocation des accès, audit et reprise d'activité

Instructions vérifiées par rapport à la documentation le 16 septembre 2026.

Lorsqu’un agent autonome exécute des commandes telles que git diff, lit des fichiers de configuration locaux ou transmet accidentellement des captures de variables d’environnement directement dans les prompts du modèle, les secrets quittent le périmètre de confiance. Dans cette situation, vous devez interrompre les scripts en arrière-plan, révoquer les identifiants compromis, auditer les journaux en gardant à l’esprit leurs limites et redémarrer l’environnement selon le principe du moindre privilège.

Distinguer la configuration normale d’une fuite de contexte

Avant d’engager la réponse à l’incident, il est crucial de distinguer l’utilisation normale de l’API d’une compromission réelle.

Le fonctionnement normal implique la transmission d’une clé d’API exclusivement dans les champs d’autorisation du fournisseur de modèle prévu (par exemple, via les variables OPENAI_API_KEY ou ANTHROPIC_API_KEY) pour authentifier les requêtes de l’outil auprès du modèle de langage. Des variables telles que ANTHROPIC_BASE_URL ou OPENAI_BASE_URL définissent l’adresse réseau du point de terminaison (endpoint/base URL), et non un secret ou un jeton d’authentification.

Une fuite vers le modèle est définie comme un événement au cours duquel des secrets d’infrastructure sans rapport — tels que des jetons d’accès personnels GitLab, des clés AWS IAM à long terme, des clés SSH privées, des identifiants de base de données ou des jetons de réseau d’entreprise — pénètrent dans le corps de la requête utilisateur, le contexte conversationnel, les fichiers joints ou les flux de sortie des utilitaires (stdout/stderr) et sont effectivement transmis à un service externe. Bien qu’il ne faille pas présumer de la malveillance a priori de tous les proxys ou passerelles intermédiaires, l’envoi d’un secret hors d’un périmètre isolé exige un confinement immédiat.

Premières actions : arrêt des processus et documentation de l’incident

La priorité absolue est d’empêcher toute transmission ultérieure de données :

1. Interrompez le processus local de l’agent et désactivez les tâches de fond associées (tâches cron, scripts d’automatisation CI/CD).
2. Consignez les métadonnées de l’incident dans un rapport local sans dupliquer le secret lui-même : type d’identifiant compromis, horodatage approximatif de la première requête, identifiant de tâche/session et adresse réseau du point de terminaison (endpoint) destinataire.
3. Ne transmettez pas le secret exposé en clair dans les canaux de discussion du support ou dans de nouvelles requêtes vers des réseaux de neurones pour vérification.

Toutes les opérations de révocation et de remplacement de clés doivent être effectuées exclusivement depuis un poste de travail de confiance à l’aide des consoles de gestion officielles des fournisseurs.

Révocation des accès par type de service

Les différentes plateformes mettent en œuvre l’isolation et la révocation des autorisations selon des règles architecturales distinctes.

Clés d’accès aux modèles (OpenAI API)

Conformément aux bonnes pratiques officielles d’OpenAI pour la sécurité des clés d’API, toute suspicion de compromission exige la rotation de la clé et l’examen de la consommation des ressources.

En cas de suspicion de fuite, la clé compromise doit être révoquée en priorité :

1. Accédez immédiatement à l’interface web de gestion des clés d’API OpenAI et révoquez (Revoke/Delete) la clé compromise. Cela bloque tout appel non autorisé ultérieur au prix d’une interruption de service temporaire et contrôlée pour les services dépendants ; la révocation ne doit pas être différée dans l’attente d’un audit complet ou d’une longue mise à jour de l’ensemble des consommateurs.
2. Générez une nouvelle clé et mettez à jour les configurations des services.
3. Ouvrez le tableau de bord Usage et analysez l’activité au sein de la fenêtre d’exposition déterminée, en la confrontant aux opérations attendues.

Jetons d’accès personnels GitLab

Selon la documentation de GitLab sur les Personal Access Tokens, la révocation d’un jeton d’accès personnel le rend immédiatement invalide :

1. Dans l’interface GitLab, cliquez sur votre avatar dans le coin supérieur droit > Edit profile > Access > Personal access tokens.
2. Dans le tableau des jetons actifs, repérez l’identifiant compromis et cliquez sur Revoke.

La fonction Rotate de GitLab annule l’ancien jeton mais conserve les périmètres de droits (scopes) précédents. Si le jeton compromis disposait de droits excessifs, il convient de le révoquer totalement et d’en créer un nouveau configuré avec un périmètre minimal. La page de détails du jeton affiche la date de dernière utilisation ainsi que les cinq dernières adresses IP uniques. Notez que ces indicateurs se mettent à jour avec un délai système.

Clés d’accès AWS (IAM Access Keys)

La procédure de neutralisation des clés IAM est encadrée par le guide AWS sur la sécurisation des clés d’accès et la documentation relative à la gestion des clés d’accès pour les utilisateurs IAM :

1. Connectez-vous à la console AWS Management Console, accédez à IAM > Users, puis ouvrez l’onglet Security credentials.
2. Dans le bloc Access keys, repérez l’identifiant de la clé compromise et passez son statut à Deactivate.
3. Une fois le contrôle rétabli, supprimez la clé en cliquant sur Delete.

[!IMPORTANT] Le passage d’une clé au statut Deactivate interrompt l’acceptation de nouvelles requêtes signées avec cet identifiant à long terme, mais n’invalide pas les identifiants temporaires émis antérieurement (jetons AWS STS) et ne met pas automatiquement fin aux sessions actives. L’action Revoke active sessions s’applique uniquement aux sessions du rôle IAM correspondant ; les sessions actives d’IAM Identity Center et les autres types de jetons STS nécessitent une révocation distincte selon leurs mécanismes d’authentification propres. Un administrateur de sécurité doit également corréler les appels d’API via AWS CloudTrail et l’opération get-access-key-last-used. N’exécutez pas de commandes CLI destructives de suppression en masse non testées au cours d’un incident actif.

Clés OpenSSH et autorisation

Les procédures d’autorisation d’OpenSSH sont décrites dans les manuels de référence man sshd(8) et sshd_config(5) :

1. L’administrateur doit supprimer la clé publique compromise du fichier d’autorisation sur tous les serveurs. Le chemin du fichier est défini par la directive AuthorizedKeysFile (par défaut ~/.ssh/authorized_keys, bien que l’infrastructure puisse définir un fichier centralisé ou une validation de certificats via une autorité de certification SSH CA).
2. Avant d’appliquer des modifications, assurez-vous de disposer d’un accès de secours indépendant (comme la console web du fournisseur ou une gestion hors bande / out-of-band management) afin d’éviter tout verrouillage de votre propre accès.
3. La suppression de la clé publique empêche l’établissement de nouvelles connexions, mais n’interrompt pas les sessions déjà actives.

La commande who n’affiche que les utilisateurs disposant d’un pseudo-terminal (TTY) dédié et ne constitue pas un inventaire exhaustif des sessions : elle ne révèle ni les tunnels, ni les redirections de ports, ni les commandes non interactives. Tuer aveuglément le processus racine sshd est inadmissible, car cela ne garantit pas la rupture des sessions enfants et risque de couper l’accès de l’administrateur au serveur. L’administrateur doit examiner de manière ciblée l’arbre des processus, les connexions réseau et les journaux d’autorisation, en mettant fin individuellement aux sessions suspectes. Supprimer localement la clé privée ou modifier sa phrase de passe (passphrase) n’a aucun impact sur une clé déjà copiée vers l’extérieur.

Réseaux Tailscale et VPN d’entreprise

Selon la documentation de Tailscale sur les Auth Keys, une clé d’authentification est exclusivement destinée à l’enregistrement des nœuds :

1. Dans la console Tailscale, accédez à la section Keys et révoquez l’auth key compromise. Cela empêchera l’enregistrement de nouveaux appareils.
2. La révocation d’une auth key ne déconnecte pas les nœuds déjà enregistrés. L’administrateur a l’obligation de se rendre sur l’onglet Machines, de vérifier la liste des équipements et de supprimer manuellement (Remove/Delete) tout appareil non autorisé.

Pour les VPN d’entreprise traditionnels (IPsec, OpenVPN, WireGuard et solutions propriétaires), il n’existe pas de procédure universelle unique de révocation via CRL : le mécanisme exact dépend du schéma d’autorisation utilisé (certificats x509, clés prépartagées statiques, jetons RADIUS/IdP). Sur de nombreuses passerelles, le changement de mot de passe d’un compte ne met pas instantanément fin au tunnel. La procédure doit être transmise à un administrateur réseau pour révoquer le certificat ou le compte et interrompre de force les sessions actives via la console d’administration de la passerelle VPN concernée.

Analyse des conséquences : journaux, fenêtres temporelles et risques irréversibles

Lors de la corrélation de l’incident avec les journaux système, prenez en compte les limites techniques de la télémétrie :

• Fenêtre d’exposition : déterminez l’intervalle de temps précis entre la transmission initiale du secret à l’agent et la révocation confirmée de la clé ainsi que l’interruption des sessions actives.
• Limites des journaux : tenez compte des délais d’ingestion des événements (ingestion delay), des durées de rétention des logs (retention period) et des angles morts (absence d’audit détaillé des paramètres dans certaines API, absence de journalisation des sessions sans TTY).
• Principe de l’absence de preuve : l’absence d’entrées anormales dans les journaux ou une consommation nulle de jetons dans la fenêtre accessible ne prouve pas que le secret n’a pas été intercepté ou conservé par un tiers pour une exploitation différée.

La révocation des clés bloque les requêtes futures, mais ne permet pas de récupérer les données, le code source ou les variables d’environnement déjà transmis à un service externe. La fonction de suppression d’une conversation dans l’interface web d’un agent ou d’une plateforme masque l’historique, mais ne constitue en rien une preuve technique de la suppression des données des journaux ou des caches du côté du fournisseur en aval (downstream).

Redémarrage sécurisé : atténuation des risques et vérification de l’isolation

La remise en service de l’agent doit réduire le risque de récidive de l’incident :

1. Jetons à courte durée de vie : privilégiez les identifiants de session temporaires partout où les plateformes et l’infrastructure le permettent.
2. Délimitation de l’espace de travail : excluez les fichiers .env, les clés privées et les répertoires contenant des secrets de l’espace de travail de l’agent ; déplacer les secrets en dehors de cet espace ne garantit pas une isolation totale et ne remplace pas le contrôle d’accès au niveau du système d’exploitation.
3. Test des barrières sans tokens canaris réseau : pour tester les autorisations, créez un répertoire temporaire isolé, totalement dépourvu de véritables secrets. Placez-y un fichier contenant une chaîne factice de substitution et vérifiez si l’agent bloque l’accès au fichier, l’exécution de commandes shell et la lecture des variables via env. Ne recourez pas à des services externes de jetons canaris réseau (canary tokens) pour la validation élémentaire des droits.
4. Défense en profondeur : l’interception réussie de la lecture d’un chemin donné ne démontre pas l’isolation complète du processus si l’agent conserve un accès illimité au terminal ou au réseau.

Les approches architecturales détaillées pour restreindre les appels système et cloisonner les droits sont traitées dans le guide sur la gestion des autorisations et des secrets dans Claude Code. La minimisation des privilèges des comptes et l’abandon des secrets statiques réduisent les risques lors de la délégation de tâches à des outils d’IA autonomes.