Turnkey lance Managed Secrets pour gérer l’accès des agents IA aux identifiants

Turnkey a lancé Managed Secrets, qui étend son infrastructure de portefeuilles reposant sur des enclaves aux clés API, mots de passe, informations de paiement et éléments de récupération dont les applications et les agents IA ont besoin pour fonctionner. Dans son annonce du 29 octobre, l’entreprise élargit son champ d’action au-delà de la gestion des clés privées pour s’attaquer à un problème plus vaste : donner aux logiciels le pouvoir d’agir sans disperser des identifiants réutilisables dans leur infrastructure.

Le produit permet aux équipes de déterminer quel service peut récupérer un identifiant et si cette demande nécessite l’approbation d’une personne ou de plusieurs parties. Pour les applications financières, cela pourrait consister à transmettre une clé API d’une plateforme d’échange à un système d’arrière-plan de négociation autorisé, tout en la gardant hors de la conversation et de l’environnement d’exécution d’un assistant IA.

Placer l’accès aux identifiants derrière une enclave

Les identifiants stockés dans des variables d’environnement ou des fichiers de configuration sont pratiques pour les logiciels, mais une compromission du processus qui les lit peut en révéler le contenu. Un coffre-fort peut centraliser le stockage et les contrôles d’accès ; reste à savoir à quel endroit un identifiant devient lisible et quels systèmes doivent alors être considérés comme fiables.

Managed Secrets effectue ses vérifications d’autorisation au sein des enclaves sécurisées de Turnkey. Un client chiffre un secret avant de l’importer, puis l’enclave le chiffre de nouveau pour le stocker. Lorsqu’une demande arrive, l’enclave évalue les règles et les approbations applicables avant de chiffrer le résultat avec la clé du destinataire prévu. Le demandeur et le destinataire peuvent être des services différents.

Cette séparation est importante. Une application peut lancer une opération et recueillir les approbations sans acquérir la capacité de déchiffrer l’identifiant nécessaire à son exécution. La signature d’un approbateur autorise la transmission ; elle ne donne pas automatiquement accès au secret transmis.

La cryptographie utilisée pour l’importation et l’exportation

La documentation sur le canal sécurisé de Turnkey décrit un protocole fondé sur le chiffrement hybride à clé publique, ou HPKE. Celui-ci associe un accord de clés fondé sur la cryptographie à clé publique au chiffrement authentifié, afin que des données sensibles puissent transiter par des systèmes intermédiaires sous forme de texte chiffré. Lors de l’importation, le client vérifie les éléments de clé signés par l’enclave ; lors de l’exportation, le chiffrement utilise une clé publique fournie dans la demande signée.

Les clés des destinataires sont destinées à un usage unique. Turnkey précise que les clients doivent eux-mêmes respecter cette règle : le protocole ne peut empêcher un client défectueux de réutiliser la clé cible. La mise en œuvre côté client fait donc partie du modèle de sécurité, au même titre que l’enclave.

La page du produit Managed Secrets précise que chaque secret est chiffré au repos avec AES-256-GCM. Son API permet de gérer des identifiants individuels ainsi que des demandes portant sur plusieurs secrets. Les exportations par lots échouent dans leur ensemble si l’un des secrets demandés n’est pas autorisé, ce qui empêche la transmission d’un ensemble dont seule une partie a été approuvée.

Pourquoi le destinataire reste important

L’expression « les agents peuvent utiliser des identifiants sans les voir » décrit un mode d’intégration, et non la garantie qu’aucun processus destinataire ne pourra jamais lire les données en clair. La documentation destinée aux développeurs de Turnkey indique explicitement que des données en clair peuvent exister dans l’enclave ainsi que sur le client qui importe ou exporte un secret.

Si un service d’exécution distinct détient la clé du destinataire, il peut déchiffrer un identifiant et l’utiliser sans le rendre accessible au modèle. Si cette clé est détenue par l’environnement d’exécution de l’agent lui-même, celui-ci peut le déchiffrer. Il reste donc nécessaire de protéger le destinataire, sa mémoire et ses journaux.

Il existe une deuxième limite : les règles peuvent examiner le contexte de la demande, par exemple un domaine de paiement déclaré, mais Turnkey ne vérifie pas de manière indépendante si cette déclaration est vraie. Une déclaration signée établit qui en est l’auteur. Les applications doivent tout de même effectuer des vérifications fiables reliant cette déclaration à l’opération réelle.

Des approbations évolutives au fil du processus

Les équipes peuvent autoriser la récupération directe, exiger qu’une personne approuve une demande ou demander l’accord de plusieurs rôles d’agent. Les règles peuvent être modifiées sans réimporter le secret sous-jacent, ce qui permet de commencer un processus sous étroite supervision, puis d’automatiser certaines demandes.

Le guide sur les accès programmables de Turnkey illustre une situation dans laquelle un agent de navigation et un agent de paiement cosignent une demande. Seul l’agent de paiement reçoit des données de carte qu’il peut déchiffrer. Avant de donner son approbation, le composant de navigation vérifie que le domaine proposé correspond à la page qu’il utilise. Cet exemple montre pourquoi l’indépendance des rôles et la validation comptent davantage que le simple fait de compter deux approbations.

Les rôles d’agent peuvent utiliser des identifiants de session à portée limitée et à durée de validité définie, ce qui permet aux opérateurs de révoquer une instance en cours d’exécution. Toutefois, la révocation des accès futurs ne peut pas effacer un secret déjà déchiffré par un destinataire ; la rotation des identifiants en aval reste une mesure opérationnelle distincte.

De l’infrastructure de portefeuilles à l’automatisation financière

L’architecture de sécurité actuelle de Turnkey repose sur AWS Nitro Enclaves et associe l’isolation matérielle à des compilations reproductibles et à une attestation à distance. La reproductibilité permet de comparer les compilations logicielles, tandis que l’attestation fournit des preuves concernant le code exécuté dans l’enclave. Managed Secrets étend cette base aux identifiants autres que les clés de signature de blockchain.

L’entreprise présente les sociétés de trading, les systèmes dorsaux de la fintech, les développeurs d’agents IA et les dépositaires MPC comme des utilisateurs visés. Les identifiants d’accès aux plateformes d’échange et les jetons OAuth permettent de maintenir l’accès aux services ; les sauvegardes des parts de clé et les clés de récupération contribuent à la résilience. Il s’agit d’usages distincts, soumis à des exigences différentes en matière d’approbation et de destinataires, même s’ils reposent sur la même infrastructure de stockage.

Pour les équipes des technologies financières, l’intérêt réside dans une distinction plus nette entre la demande d’une action, l’autorisation de l’accès et la réception d’un identifiant utilisable. Managed Secrets fournit l’infrastructure nécessaire à cette séparation. La protection qui en résulte dépend de politiques restrictives, d’approbateurs fiables et d’un service bien protégé qui utilise finalement le secret.