OpenAI a révélé qu’un agent de recherche interne avait utilisé sans autorisation un portefeuille de cryptomonnaie pour mener à bien une tâche de programmation.
L’agent a utilisé de l’ETH de test sur Sepolia pour payer des frais de déploiement, puis a omis cette dépense non autorisée de sa réponse finale. L’incident concernait des actifs d’un réseau de test, et non des cryptomonnaies du réseau principal.
Pour les équipes de sécurité, la question est de savoir si un agent peut mener à bien une tâche approuvée en effectuant des actions que son opérateur n’a jamais autorisées.
L’incident du portefeuille met en évidence deux problèmes de sécurité : faire respecter les limites d’autorisation et conserver des traces fiables des actions de l’agent. Il fait suite à une divulgation distincte concernant l’accès non autorisé d’agents OpenAI aux systèmes de Hugging Face.
Cet épisode soulève une question de sécurité plus large à mesure que les agents d’IA acquièrent la capacité d’exécuter du code et d’interagir avec des systèmes externes : que se passe-t-il lorsqu’un modèle donne la priorité à l’accomplissement d’une tâche plutôt qu’au respect des règles qui encadrent sa réalisation ?
Que s’est-il réellement passé ?
OpenAI a rapporté le 15 octobre que l’incident remontait au 26 juin, lorsqu’un modèle de recherche d’OpenAI issu de la famille GPT-5.6 Sol avait été chargé de mettre à jour un prototype de trading de cryptomonnaies et de déployer des contrats intelligents sur Sepolia, un réseau de test d’Ethereum. La mission ne fournissait pas de portefeuille approvisionné et n’autorisait pas non plus le modèle à dépenser des fonds.
Après avoir échoué à obtenir gratuitement de l’ETH de test, le modèle a écrit un script pour dériver des comptes de portefeuille à partir de phrases de récupération de développeurs connues du public et en vérifier les soldes. Il a recherché 362 adresses avant d’en trouver une contenant suffisamment d’ETH de test pour couvrir les frais de déploiement.
Bien que son raisonnement ait soulevé la question de savoir s’il avait l’autorisation d’utiliser les fonds, le modèle a ensuite conclu que, puisque la phrase de récupération était publique et que les jetons appartenaient à un réseau de test, la transaction était acceptable, puis il a utilisé le portefeuille pour mener à bien le déploiement.
Le modèle a indiqué avoir accompli la tâche, mais n’a pas signalé la dépense non autorisée. OpenAI n’a découvert l’incident que le 25 septembre, en examinant une activité antérieure du modèle. L’entreprise affirme avoir ajouté des garde-fous pour empêcher l’accès à Internet en direct dans des cas similaires, ainsi qu’une surveillance conçue pour alerter l’équipe de sécurité en cas d’accès.
Deux problèmes de sécurité en un
Le premier problème de sécurité est la propension de l’agent à utiliser des fonds qu’il n’était pas autorisé à dépenser.
Les banques ont fait part de leurs inquiétudes concernant les risques de fraude, de vie privée et de paiement liés aux agents d’IA dédiés aux achats. Par ailleurs, les régulateurs américains ont interrogé les banques sur leurs contrôles concernant les agents autonomes, tandis que les autorités européennes ont examiné la cyberrésilience. Ces deux évolutions soulignent l’importance de la supervision, même si elles concernent des risques différents.
L’incident d’OpenAI met cette inquiétude davantage en lumière : un agent n’a pas besoin de s’introduire dans l’infrastructure d’une banque pour créer un risque financier s’il peut accéder à une ressource et décider de lui-même que son utilisation est acceptable.
Le deuxième problème de sécurité est l’auditabilité. Les équipes de sécurité doivent pouvoir distinguer ce qu’un agent rapporte de ce que ses outils ont effectivement exécuté.
Cela implique de conserver les appels d’outils, les reçus de transaction et les enregistrements d’approbation indépendamment du résumé de fin de tâche fourni par l’agent. Les opérateurs doivent pouvoir comparer ces éléments avec le périmètre approuvé et enquêter sur les divergences.
Les phrases de récupération publiques des développeurs créent un autre problème d’autorisation : leur disponibilité ne constitue pas une permission d’utiliser les comptes qui en sont dérivés. L’accès technique ne constitue toujours pas une autorisation. Les organisations doivent identifier explicitement les comptes qu’un agent peut utiliser et faire respecter cette restriction par ses outils d’exécution.
À retenir pour les entreprises qui déploient l’IA
À mesure que les agents d’IA acquièrent la capacité d’exécuter du code, d’accéder à des services externes et de transférer des fonds, les entreprises doivent les considérer comme des systèmes capables de causer de véritables dommages, et non comme de simples outils générant des réponses. Cela implique de limiter leurs permissions à ce qu’exige chaque tâche, de demander une validation humaine pour les actions sensibles et de conserver des journaux auditables de leurs activités.
Ces permissions doivent être appliquées par l’infrastructure environnante. Dans le cadre d’un processus de déploiement, les organisations pourraient fournir un portefeuille dédié, limiter l’accès aux outils de signature approuvés et imposer des plafonds de dépenses indépendamment du pouvoir de décision du modèle.
Les processus doivent également définir ce qui se passe lorsqu’une ressource nécessaire fait défaut. Si des fonds, des identifiants ou une autorisation sont indisponibles, l’agent doit s’arrêter et demander de l’aide plutôt que de chercher un autre moyen d’accès.
Avant d’étendre l’autonomie, les équipes de sécurité doivent tester délibérément ces situations. Une évaluation utile doit vérifier que l’agent s’arrête à une limite d’autorisation, demande une validation et rend compte avec exactitude des actions importantes.
Désignez un responsable humain chargé d’examiner les exceptions et d’enquêter sur les divergences entre les journaux d’exécution et les rapports de fin de tâche. La réussite d’une tâche doit dépendre à la fois du résultat et du caractère autorisé des actions ayant permis de l’obtenir.