En novembre 2025, Anthropic publie un rapport gênant. Un acteur étatique a détourné Claude Code, son agent de codage, pour mener une campagne d’espionnage contre une trentaine d’organisations. Reconnaissance, écriture d’exploits, vol d’identifiants, déplacement d’un serveur à l’autre, exfiltration. Depuis, les exemples ont fleuri.

L’IA a exécuté 80 à 90 % de l’opération toute seule, l’humain n’intervenant qu’à quatre à six points de décision. Des milliers de requêtes, exécutées jusqu’à plusieurs fois par seconde.

Ce qui rend cette histoire intéressante pour toi, ce n’est pas l’acteur étatique. C’est l’outil.

Claude Code, Cursor, un agent que tu lances toi-même le soir pour ranger ton infra, tournent tous avec tes droits à toi. Tes fichiers, ton terminal, ton réseau. Et tes clés SSH. L’agent n’a pas besoin de voler quoi que ce soit, il hérite de ton trousseau au démarrage.

Le jour où une page web piégée, un dépôt Git empoisonné ou un serveur MCP malveillant lui glisse les mauvaises instructions, il ne fait pas une bêtise sur ton Mac. Il ouvre une session ssh root@ton-serveur-maintenant-compromis et il continue, ailleurs, sur toutes les machines que ta clé déverrouille.

Le risque, tu l’as déjà entendu cent fois, et chaque jour voit de nouvelles alertes tomber. On va donc parler de la parade, celle que j’ai dû imaginer et mettre en place pour avoir un garde-fou efficace (stop, je ne revendique aucune paternité : si d’autres ont eu la même idée avant moi, mille excuses ; mais si personne d’autre ne l’a eue, maman, purée, j’suis trop fier !).

L’agent a tes clés, et tes clés ouvrent tout

Pose-toi la question que personne ne pose. Un agent IA qui déraille sur ton poste, qu’est-ce qu’il peut atteindre en une commande ?

Sur le Mac d’un indépendant ou d’une petite structure, la réponse est brutale. La clé SSH vit dans ~/.ssh, elle est chargée dans l’agent système au premier usage de la journée, et elle ouvre le serveur de prod, le serveur mail, le serveur de sauvegarde.

Une seule clé, un passe-partout, parce que c’est pratique et que ça a toujours marché. C’est comme laisser le même trousseau sur le contact de toutes les voitures du parking.

Le scénario n’a rien de théorique. Un agent capable de lire tes fichiers et de lancer des commandes peut :

• lire ta clé et ta configuration SSH, donc savoir exactement quelles machines existent et comment les joindre.
• ouvrir une session vers chacune d’elles avec tes propres droits, sans rien casser, sans alerte.
• rebondir de serveur en serveur en réutilisant l’accès de l’agent SSH resté ouvert sur chaque machine intermédiaire.

Ce dernier point est le cœur du problème, et il porte un nom. Le mouvement latéral. C’est exactement ce que la campagne de novembre 2025 a fait faire à un agent de codage grand public. Pas un malware exotique compilé pour l’occasion, un assistant que des milliers de développeurs installent chaque semaine.

La suite est mécanique. Un serveur compromis en compromet un second, qui en compromet un troisième. À la vitesse machine, en silence, pendant que tu bois ton café.

Tout le monde crie au loup

Le risque agents IA n’est pas un secret que Mac Souverain t’apprendrait. Il est partout. Ce qui est rare, c’est une autorité qui le met noir sur blanc.

Au printemps 2026, le CERT-FR, l’équipe de réponse aux incidents de l’ANSSI, tranche : ces assistants « ne doivent pas être déployés sur des postes de travail ». Pas « faites attention », un non catégorique.

Le document liste ce qui doit t’empêcher de dormir : compromission du poste par des outils encore en bêta, fuite de données vers des ressources externes, droits d’accès démesurés accordés à l’agent, partage des secrets d’authentification, et perte de maîtrise des actions, y compris destructrices et irréversibles.

Lis bien la liste. « Droits d’accès démesurés » et « partage des secrets d’authentification », c’est ta clé SSH, décrite par l’autorité nationale française. Quand l’ANSSI et l’éditeur de l’agent lui-même décrivent ainsi la même menace, le débat « est-ce que c’est grave » est clos.

Alors regardons ce que l’ANSSI recommande ensuite : cantonner les agents à des environnements isolés, exiger une validation humaine avant l’exécution de commandes système, durcir, cloisonner. De bons principes.

Aucun ne te dit comment, sur ton Mac, empêcher concrètement l’agent d’utiliser ta clé root. C’est ce trou-là qu’on comble.

Avant d’aller plus loin, si tu veux comprendre par où l’agent peut recevoir de mauvaises instructions, l’article dédié détaille un des vecteurs d’entrée. Ce n’est pas exhaustif, mais c’est parlant.

À lire : Les MCP, la porte dérobée de ton IA

Pourquoi le durcissement SSH classique ne suffit pas

Tu connais peut-être déjà les recettes de durcissement SSH. Elles sont bonnes. Elles ne répondent juste pas à cette menace-ci, parce qu’elles ont toutes été pensées contre un attaquant distant, pas contre un programme qui tourne déjà chez toi, avec tes droits.

La passphrase sur la clé privée. Elle chiffre le fichier ~/.ssh/id_ed25519 au repos. Très bien contre le vol du disque. Sauf qu’une fois la passphrase saisie le matin, la clé est déchiffrée et chargée en clair dans la mémoire de l’agent SSH. À partir de là, n’importe quel programme avec tes droits, ton agent IA compris, tape dans le socket de l’agent sans qu’on lui redemande quoi que ce soit. Aucune présence humaine exigée par connexion.

L’agent SSH et le forwarding. Le confort d’une seule saisie pour enchaîner les rebonds. C’est précisément le vecteur du mouvement latéral. L’agent garde tes clés déchiffrées en mémoire, et son socket est joignable sur chaque machine où tu te connectes. Qui contrôle une machine intermédiaire, détourne tes signatures. Ce n’est pas un bug obscur, c’est une technique cataloguée depuis des années.

Le bastion, le serveur de rebond. Il centralise et journalise les accès. Utile. Mais il devient une cible unique, et si l’agent a les droits pour l’atteindre, il pivote à travers lui comme à travers le reste. Le bastion sait qui s’est connecté, il ne sait pas si un humain l’a voulu.

Le coffre à secrets, façon Vault. Rotation, secrets courts, certificats jetables. Lourd pour une PME, et surtout, l’agent qui tourne avec tes droits peut souvent demander le secret exactement comme tu le ferais. Il se présente à ta place, on le sert.

Les demandes d’autorisation de l’agent lui-même, le petit « Autoriser cette commande ? » de Claude Code. C’est un vrai garde-fou, jusqu’au jour où la fatigue te fait cliquer « oui » par réflexe, où quelqu’un lance l’agent en mode sans confirmation, ou où le message décrit ce que l’agent dit faire, pas ce qu’il fait. C’est un contrôle logiciel, dans le même système que l’agent.

Le fil rouge de toutes ces limites : rien n’exige la présence physique d’un humain au moment de la connexion. La clé est un objet numérique, manipulable par tout ce qui a tes droits. Pour casser la chaîne, il faut sortir la clé du monde que l’agent peut toucher.

Deux verrous que l’agent ne peut pas forcer seul

L’idée tient en une phrase. On ajoute deux conditions indépendantes pour qu’une connexion SSH aboutisse, et on en met une hors de portée de tout logiciel.

• Le réseau. Le serveur n’écoute plus sur l’internet public. On ne peut le joindre qu’en étant membre d’un réseau privé, ton tailnet. Fini l’attaque à distance, et surtout tu réduis la surface de rebond.
• La présence. La clé privée ne vit plus dans un fichier. Elle vit dans la puce de sécurité de ton Mac, et chaque signature exige ton doigt sur le lecteur Touch ID. Un agent ne pose pas de doigt.

Ces deux facteurs sont indépendants : appartenir au réseau, poser le doigt. Un agent qui tourne sur ton poste tient peut-être le premier, ta machine est déjà membre du tailnet. Il n’aura jamais le second. C’est toute la bascule. On passe d’une clé que n’importe quel programme peut utiliser à une clé qui exige un geste que seul un humain présent peut faire.

Rien de tout ça n’est exotique. Ce sont deux idées éprouvées, assemblées, sans matériel à acheter, grâce à ton Mac et à sa puce Secure Enclave.

Regardons maintenant chaque verrou.

Le réseau, fermer le port et disparaître d’internet

Le premier verrou, c’est de rendre tes serveurs injoignables depuis l’extérieur. Pas mieux protégés, injoignables.

Tailscale monte un réseau privé chiffré entre tes machines, un tailnet, par-dessus le protocole WireGuard. Chaque appareil autorisé reçoit une adresse privée, en 100.x, sur une interface dédiée. Le trafic est chiffré de bout en bout entre tes appareils, et le tout est régi par une liste d’autorisations qui refuse par défaut : sans règle explicite, personne ne joint personne.

Concrètement, le changement est radical. Ton serveur écoute SSH uniquement sur l’interface Tailscale. Tu fermes le port 22 public au pare-feu, tu n’exposes plus sur l’internet ouvert que ce qui doit vraiment l’être, un site en 80 et 443 si tu en héberges un. Un scanner qui balaie internet à la recherche de serveurs SSH ne voit rien du tout. Le port n’est pas filtré, il n’existe pas de son point de vue.

Pour l’agent IA, ça déplace déjà beaucoup. Il ne peut plus atteindre une machine par une adresse publique, et un serveur qu’il compromettrait ne lui offre pas de tremplin vers l’internet entier, juste vers ce que le tailnet autorise.

Un piège à éviter, et pas des moindres. Tailscale propose une fonction maison appelée Tailscale SSH, qui remplace le SSH classique et gère l’authentification via l’identité de ton réseau, sans clé côté client. C’est séduisant, et pour notre menace, c’est exactement ce qu’il ne faut pas faire.

Sans clé côté client, il n’y a plus de Secure Enclave, plus de Touch ID, plus de second verrou. Un agent membre du tailnet se connecterait tout seul. On garde donc le réseau privé de Tailscale et le SSH classique avec une clé matérielle.

Le tailnet est le périmètre, la clé reste le geste.

Le réseau maillé Tailscale, comment on le monte proprement sur plusieurs Mac, est couvert pas à pas ailleurs. À lire : Un réseau privé entre tes Mac avec Tailscale

La clé, une puce et un doigt

Voilà le verrou qui change tout, et c’est le plus mal connu.

Ton Mac Apple Silicon embarque une puce de sécurité indépendante, la Secure Enclave. Elle a son propre processeur, sa propre mémoire isolée, et une propriété qui la définit : elle ne rend jamais ses clés.

Tu peux lui demander de signer quelque chose avec une clé, jamais de te donner la clé. Root sur la machine n’y change rien, la clé privée n’existe nulle part sous une forme copiable. Un coffre scellé qui signe pour toi et ne rend jamais la clé, même à root.

L’outil qui branche ça sur SSH s’appelle Secretive. C’est une app macOS open source, écrite par Max Goedjen, dont le rôle est simple : elle génère et garde tes clés SSH dans la Secure Enclave, et elle se présente au système comme un agent SSH ordinaire.

Tu pointes ta variable SSH_AUTH_SOCK vers son socket, et tous tes usages SSH continuent sans changer une ligne. ssh, git push, rsync, tout marche comme avant. La différence, tu la vois au moment de la connexion.

Voici le flux concret. Tu lances ssh root@serveur-prod. Le serveur réclame une signature pour prouver que tu détiens la clé. La demande arrive à Secretive, qui doit faire signer la Secure Enclave.

Et là, la puce refuse de signer tant qu’elle n’a pas vérifié ta biométrie. Une fenêtre Touch ID s’affiche, tu poses ton doigt, la signature se fait dans la puce, la connexion s’établit. Pas de doigt, pas de signature, pas de connexion.

Deux réglages font toute la solidité de l’ensemble.

Le premier, c’est l’option « exiger Touch ID à chaque fois ». Sans elle, un déverrouillage vaut pour un moment et l’agent pourrait enchaîner des signatures dans la foulée. Avec elle, chaque connexion réclame sa propre présence. C’est le réglage à activer, sans discussion.

Le second est un point technique qui vaut d’être dit clairement. La Secure Enclave ne sait manier nativement qu’un seul type de clé, une clé à courbe elliptique ECDSA P-256 (Elliptic Curve Digital Signature Algorithm sur la courbe NIST P-256). C’est ton socle, et il est parfaitement solide pour du SSH.

Tu liras peut-être ici ou là des promesses de clés post-quantiques dans Secretive. Méfie-toi de l’amalgame : ce qui est post-quantique n’est pas dans la Secure Enclave, qui ne fait que du P-256. Le vrai garde du corps, c’est la clé matérielle non copiable et le doigt qui l’active, pas une courbe à la mode.

Un mot d’expérience. J’utilise ce montage au quotidien, et il change un réflexe. Ouvrir un accès root ne se résume plus à taper un mot de passe la tête ailleurs, il faut poser le doigt. Le geste le plus dangereux de ta journée redevient un geste conscient.

Pour le fond, ce qu’est réellement la Secure Enclave et ce qu’elle protège dans ton Mac, c’est expliqué en détail ici. À lire : Apple Silicon, ce que la Secure Enclave change vraiment

Ce que ça change, et ce que ça te coûte

Fais le bilan honnête, gains d’un côté, factures de l’autre.

Le gain principal, on l’a dit : la connexion SSH la plus sensible, celle qui ouvre root sur un serveur, exige désormais un humain physiquement présent. Un agent malveillant, ou qui déraille, bute sur un mur qu’aucune ligne de code ne franchit. C’est du concret, pas une couche de politique de sécurité qu’un --dangerously-skip fait sauter.

Le gain de bord, c’est le vol de clé qui devient sans objet. Il n’y a plus de fichier de clé privée à voler. Un attaquant peut copier tout ton ~/.ssh, il n’en tire rien, la clé n’y est pas. Elle est dans une puce qui ne la donnera jamais.

Maintenant la facture, parce qu’il y en a une et qu’elle est réelle.

La clé n’est ni exportable, ni sauvegardable, ni transférable. C’est le revers exact de sa force. Puisqu’elle ne quitte jamais la puce, tu ne peux pas la copier sur un autre Mac. Nouveau Mac, nouvelle clé. Concrètement, tu déclares plusieurs clés autorisées sur tes serveurs, une par machine, et tu retires l’accès d’un Mac perdu ou revendu en supprimant sa clé publique côté serveur.

Il te faut un plan de secours hors-ligne. Si ton seul Mac tombe en panne et que la seule clé qui ouvre tes serveurs est dans sa puce, tu es dehors, verrouillé hors de ton propre parc.

La discipline qui va avec ce montage, c’est de garder une clé de récupération distincte, générée classiquement, chiffrée par une phrase forte, rangée hors-ligne, sur un support froid que tu ne branches qu’en cas de sinistre. Ce n’est pas un détail de confort, c’est ce qui sépare une bonne pratique d’un enfermement.

Et garde une porte de sortie hors du montage lui-même. La clé de récupération règle le problème de la clé perdue, pas celui du réseau fermé. Si tu as coupé le port 22 public et que ta seule machine du tailnet vient de mourir, ta clé de secours ne sert à rien, il n’y a plus de porte où la présenter.

La vraie issue, c’est l’accès console de ton hébergeur, le KVM ou la console série de son panel, qui te donne la main sur le serveur sans passer ni par SSH, ni par le tailnet. Vérifie qu’il marche et que tu sais t’y connecter avant d’en avoir besoin, pas le jour du sinistre.

Ces contraintes ne sont pas des défauts cachés. Ce sont les conditions d’un système où la clé est vraiment hors de portée du logiciel. On ne peut pas à la fois vouloir une clé qu’aucun programme ne peut copier et une clé qu’on sauvegarde d’un clic.

La Secure Enclave garantit ta présence, pas ton intention

Voici la section que la plupart des articles sur le sujet (s’ils existent !) vont sauter allègrement. Elle est le cœur de l’honnêteté de celui-ci.

Le Touch ID prouve une chose, et une seule : un humain était physiquement là et a autorisé l’usage de la clé. Il ne prouve pas que cet humain a compris l’action distante qui se cachait derrière. La puce vérifie ta présence, elle ne lit pas dans ta tête.

Ce n’est pas de la philosophie, c’est structurel, et ça tient à un détail de protocole. Quand une connexion réclame une signature, l’agent SSH, donc Secretive, ne reçoit pas le nom du serveur de destination ni la commande qui va s’exécuter là-bas. Il reçoit un bloc de données opaque à signer, en gros une empreinte de session et un nom d’utilisateur.

Résultat : Secretive ne peut pas t’afficher « tu te connectes à serveur-prod pour lancer rm -rf », parce qu’il l’ignore lui-même (Avec une commande comme ça, j’espère que ta sauvegarde Kopia est à jour… sinon tu pleures !). Il peut te montrer quel programme local demande la signature, pas vers où ni pour quoi.

Ce n’est pas un défaut de l’app, c’est une limite du protocole SSH.

Tu vois le scénario qui reste ouvert. Un agent détourné n’a pas besoin de forcer la puce. Il lui suffit de placer sa demande de signature au moment où tu en attends une légitime.

Tu lances un déploiement, tu sais qu’il va falloir valider deux ou trois Touch ID, tu es en mode « je signe mon workflow ». L’agent glisse sa connexion dans le lot. Tu poses le doigt par habitude. Tu viens de signer quelque chose que tu n’as pas vu venir. Là, tu es dupé en grand et le geste ne peut pas être rattrapé.

Ce mécanisme a un grand frère documenté, la fatigue d’approbation. En 2022, un sous-traitant d’Uber, noyé sous les notifications de double authentification déclenchées par un attaquant, a fini par en approuver une pour avoir la paix. L’attaquant était dans la place.

Le Touch ID à répétition est exposé au même réflexe : à force de valider, on valide sans regarder.

Alors soyons précis sur ce que la parade fait vraiment. Elle ne supprime pas le risque, elle le transforme.

• Avant. Un agent qui déraille pivote seul, en silence, à distance, à la vitesse machine. Des milliers de connexions par seconde, aucun humain dans la boucle. C’est la campagne de novembre 2025.

• Après. L’agent ne peut plus rien faire seul. Pour obtenir une signature, il doit piéger un humain précis, présent, à un instant précis, et réussir sa manipulation pile à ce moment-là.

Le gain est énorme et il faut le mesurer pour ce qu’il est. On passe d’une attaque scalable, silencieuse, asynchrone, à une attaque synchrone, ciblée, qui exige une tromperie humaine réussie au bon moment. On a tué le pivot automatique de masse, et réintroduit un humain sur le geste le plus dangereux. Mais la prise résiduelle existe, et elle a un nom, ton propre réflexe.

La discipline qui va avec

Puisque le maillon qui reste est humain, les règles qui bordent ce maillon sont humaines, elles aussi. Elles ne sont pas optionnelles, elles font partie de la parade autant que la puce.

• Une clé par serveur, jamais de passe-partout. Une signature ne doit valoir que pour un seul hôte. Secretive gère plusieurs clés sans peine, sers-t’en. Ainsi, même une signature soutirée n’ouvre qu’une porte, pas tout le couloir.

• Touch ID à chaque usage, sans cache. Le réglage vu plus haut. Il interdit à l’agent d’enchaîner des signatures sur une seule présence.

• Zéro validation en rafale. Un déploiement qui te demande de valider cinq Touch ID à la chaîne est le terrain rêvé pour en glisser un sixième. Si tu ne peux pas dire à quoi correspond chaque doigt posé, arrête-toi.

• Lis les notifications d’accès. Secretive te signale quel programme réclame une signature. Un outil que tu n’attendais pas qui demande à signer, c’est le drapeau rouge. Il ne te dit pas vers quel serveur, mais il te dit qui demande, et ça vaut le coup d’œil.

• Exige de ton agent qu’il annonce chaque connexion. Secretive ne connaît pas la destination, l’agent si. Donne-lui une consigne permanente : afficher en clair, dans le fil de la conversation, vers quel serveur il se connecte et pourquoi, avant chaque demande de signature. Le protocole ne le dit pas, l’agent le peut. Une fenêtre Touch ID sans la phrase qui l’annonce dans le transcript, c’est un doigt que tu ne poses pas.

• Méfie-toi de toute demande de doigt que tu n’as pas provoquée. La règle d’or. Tu n’as pas lancé de connexion et une fenêtre Touch ID surgit ? Tu refuses, tu cherches pourquoi. Le doute vaut mieux qu’un déploiement fantôme.

Aucune de ces règles n’est technique, et c’est justement pour ça qu’aucun outil ne peut les appliquer à ta place. La puce garde le geste, à toi de garder l’attention.

En résumé

Un agent IA ne t’attaque pas comme un pirate à l’ancienne. Il n’a rien à forcer, il hérite de tes droits et de tes clés au démarrage, et il pivote de serveur en serveur sans jamais lever le pied. L’ANSSI le déconseille sur les postes de travail, l’éditeur de l’un de ces agents a documenté une vraie campagne. Le constat est solide, il manquait la parade.

La parade tient en deux verrous indépendants. Un tailnet Tailscale qui ferme tes serveurs à l’internet public et n’expose plus le port 22, à condition de garder le SSH classique et sa clé, pas le mode sans clé de Tailscale. Une clé SSH dans la Secure Enclave, via Secretive, non copiable, activée par Touch ID à chaque connexion. Le réseau et le doigt, deux conditions qu’un programme seul ne réunit jamais.

Sois lucide sur la limite, c’est ce qui sépare un conseil d’un argumentaire. Le Touch ID prouve ta présence, pas ton intention. Un agent malin peut caler sa demande sur un moment où tu t’attends à signer.

D’où la discipline qui doit accompagner le montage : une clé par serveur, Touch ID à chaque usage, jamais de validation en rafale, et de la méfiance sur toute demande inattendue. Et n’oublie pas ta clé de secours hors-ligne, et l’accès console au serveur, sous peine de te verrouiller toi-même dehors.

Ce que tu gagnes est net. Tu passes d’un agent qui pivote seul, silencieux et massif, à un agent qui doit piéger un humain précis, présent, à un instant donné. Ça ne rend pas invulnérable. Ça remet ta main, physiquement, sur le geste le plus dangereux de ton infrastructure.

La théorie est posée. Le montage pas à pas, installer Secretive, générer la clé dans la Secure Enclave, câbler l’agent SSH, fermer le port et rédiger tes autorisations Tailscale, fera l’objet d’un tutoriel prochainement.

Cet article t’a donné le pourquoi. Le prochain te donnera chaque commande.

Les sources

L’éditeur de l’agent lui-même

• Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, le compte rendu de la campagne GTG-1002 de novembre 2025, par l’entreprise qui édite Claude Code.

L’autorité publique

• CERT-FR / ANSSI, CERTFR-2026-ACT-016, l’avis officiel français qui déconseille les agents IA sur les postes de travail et en détaille les risques.

Le code et la doc technique

• Secretive sur GitHub, l’app open source de Max Goedjen qui stocke tes clés SSH dans la Secure Enclave, code et README librement consultables.
• Apple, la Secure Enclave (guide de sécurité de la plateforme), la référence constructeur sur le fonctionnement de la puce.
• Apple, CryptoKit SecureEnclave.P256, la preuve que la Secure Enclave signe nativement en ECDSA P-256.
• Tailscale, contrôle d’accès et fermeture par défaut (ACL), la doc sur les règles qui, par défaut, n’autorisent aucune connexion non déclarée entre tes machines.

Les analyses indépendantes

• Graham Helton, Zero Effort Private Key Compromise, Abusing SSH-Agent For Lateral Movement, la démonstration du détournement de l’agent SSH pour le mouvement latéral.
• MITRE ATT&CK, T1563.001 SSH Hijacking, la fiche de référence sur le détournement de session SSH.