Chiffrement des agents IA : ce que Pacerelle protège

Quand vous envoyez une question à un agent IA, « chiffré » ne dit pas encore qui peut la lire. Il faut suivre la donnée : téléphone, relais, machine de l'agent, modèle et éventuels outils. Cette lecture du parcours permet de choisir une configuration cohérente avec la confidentialité de votre travail.

Les extrémités de la conversation

Pacerelle utilise le protocole Signal pour les échanges chiffrés entre appareils et agents. Votre message est déchiffré à l'arrivée sur la machine de l'agent, là où le programme doit le lire pour agir. Le relais peut acheminer le contenu sans disposer de son texte en clair.

Le chiffrement de transport TLS reste utile, mais il répond à une autre question : protéger une connexion réseau. Le chiffrement de bout en bout vise à conserver le contenu illisible pour l'intermédiaire lui-même. Cela ne signifie pas que les appareils destinataires ou le programme de l'agent ne voient jamais le texte.

Ce qui reste visible au relais

La documentation de sécurité Pacerelle distingue le contenu chiffré et les informations nécessaires au service. Le relais connaît notamment des informations de compte, les membres des conversations, les horaires, les tailles de messages et l'état de connexion des agents.

Il serait donc inexact de dire qu'il « ne voit rien ». Pour un usage sensible, examinez aussi ce que révèlent les noms et descriptions d'agents. Dans un groupe, les destinataires autorisés reçoivent le contenu : le chiffrement ne rend pas un membre du groupe incapable de recopier ce qu'il lit.

Vérifier l'identité du programme

Le code de vérification permet de comparer l'identité publiée par le programme avec celle présentée dans l'application. Avec le SDK Python, publiez les préclés puis affichez le code sur la machine de l'agent :

client.publish_prekey_bundle()
print(client.get_verification_code())

Ce fragment s'ajoute à un client déjà configuré ; le démarrage rapide montre cette configuration. Ouvrez ensuite la vérification de l'agent dans Pacerelle et comparez le code complet avec celui du terminal par un canal fiable.

Un code envoyé uniquement dans la conversation n'est pas une comparaison indépendante. Une correspondance établit la cohérence des identités comparées ; elle ne prouve pas que le programme est exempt de bug ou que sa machine est saine. Si le code change de façon inattendue, examinez l'identité et l'état local avant de poursuivre.

Comprendre les limites du Double Ratchet

Le Double Ratchet de Signal fait évoluer les clés des messages. Ses propriétés de protection des anciens messages et de récupération après compromission dépendent de conditions précises, notamment de l'effacement des anciennes clés et de nouveaux échanges secrets. Ce n'est pas une promesse d'effacement universel de toutes les copies de messages.

Les fichiers, les groupes et l'historique impliquent aussi leurs mécanismes de clés. Dans Pacerelle, les pièces jointes sont chiffrées séparément. Un historique conservé utilise des clés d'archive : il faut donc examiner sa rétention et ses sauvegardes au lieu de déduire sa protection du seul nom Double Ratchet.

Après déchiffrement, suivre encore la donnée

Si l'agent appelle un modèle hébergé, le fournisseur reçoit le contenu que votre code lui transmet. Même avec un modèle local, les journaux, captures, fichiers temporaires et sauvegardes peuvent conserver des données. Le stockage du SDK Python contient notamment des clés privées et des demandes en clair en attente ; le fichier n'est pas chiffré au repos par ce SDK.

Protégez le dossier d'état par les droits du système, limitez ses copies et gardez un seul processus par état. Ne confondez pas les mécanismes de stockage des différents SDK ou du serveur MCP. La mise en production précise leur utilisation.

Les quatre vérifications utiles

• L'identité de l'agent correspond au programme auquel vous souhaitez parler.
• Les destinataires de la conversation sont appropriés au contenu partagé.
• Le modèle et les outils n'envoient les données qu'aux services prévus.
• Le stockage local, l'historique et les sauvegardes ont une politique explicite.

Ces contrôles permettent d'utiliser le chiffrement pour ce qu'il apporte réellement, sans lui attribuer la protection de tout le poste de travail ni le contrôle des actions de l'agent. Pour ce dernier point, utilisez aussi des autorisations délimitées.