OpenClaw 2.0 et Sigil : Créer une autorisation vérifiable pour les agents IA autonomes

Après une période d'inactivité, « OpenClaw » a publié la version 2.0 le 30 août.

Selon les informations officielles, il s'agit de la mise à jour la plus importante de l'histoire d'OpenClaw, avec plus de 16 000 Pull Requests cumulés, touchant presque toute la pile produit : installation, messages, mémoire, Skills, modèles, Automations, navigateur, applications natives, Plugins et mécanismes de sécurité.

Mais plus que cette longue liste de fonctionnalités, ce qui mérite vraiment attention, c’est la trajectoire de développement de plus en plus claire derrière OpenClaw 2.0 : les agents deviennent de plus en plus capables de « faire les choses » véritablement.

En parallèle, il plonge l'industrie dans un dilemme de confiance incontournable : alors que les agents deviennent de plus en plus capables de décider autonomement « comment » agir, comment pouvons-nous nous assurer que chaque opération critique qu'ils effectuent ne dépasse pas les limites de l'autorisation réellement accordée par l'utilisateur ?

Au cours de la dernière année, le changement le plus évident des AI Agent n'est pas seulement que les modèles sous-jacents sont devenus plus intelligents.

À mesure que les infrastructures telles que MCP, Skills, Plugins, contrôle des navigateurs et exécution de code deviennent de plus en plus matures, les agents acquièrent de plus en plus de « membres » capables d'influencer réellement le monde extérieur, comme modifier des informations, cliquer sur des boutons ou contrôler directement le navigateur via computer use (lecture complémentaire : Agentic AI : un tournant atteint ? Lorsque l'IA apprend à « agir par elle-même », comment reconfigurer les limites de sécurité du Web3 ?).

Mais le problème se situe justement ici : dans les modèles d'interaction actuels, on tombe facilement dans deux extrêmes.

L'une consiste à accorder une autorisation complète, en remettant directement la clé privée ou une Session Key à longue durée de validité et disposant de suffisamment de droits à l'Agent, afin qu'il puisse décider et exécuter par lui-même.

L'expérience automatisée de ce modèle est bien sûr idéale, mais les risques sont également très concentrés : en cas d'injection de prompts, de pages web malveillantes ou de pollution des données, ou encore si le modèle présente lui-même un biais de compréhension, les erreurs pourraient se propager le long de toute la chaîne d'exécution pour finir par se transformer en opérations réelles (lecture complémentaire : Sign n'est pas seulement une signature : quand un AI Agent signe pour vous, qui détient encore le contrôle ?).

Après tout, dans les scénarios internet classiques, cela pourrait simplement être un e-mail envoyé à la mauvaise personne ou un fichier supprimé par erreur, mais sur la chaîne, une transaction erronée est souvent irréversible.

L'autre approche consiste à ne pas accorder du tout de permissions : chaque opération et chaque appel secondaire déclenche une fenêtre de signature demandant une confirmation. La sécurité est améliorée, mais le sens de l'automatisation en est considérablement réduit.

Après tout, lorsqu’un Agent aide un utilisateur à exécuter une stratégie DeFi complexe impliquant plusieurs étapes, si chaque étape nécessite que l’utilisateur prenne son téléphone pour approuver manuellement, l’utilisateur se contente de passer d’un « appui sur des boutons » à une fonction de « machine humaine de validation » pour l’Agent.

En d'autres termes, la liberté intermédiaire est à la fois la source de l'efficacité accrue de l'Agent et une nouvelle source de risque.

Du point de vue de cette perspective, la question centrale ne réside pas dans « l’octroi ou non de pouvoirs à l’Agent », mais dans la finesse de l’autorisation et la souplesse dynamique des mécanismes de vérification, car la gestion des autorisations traditionnelle est binaire (soit autorisé, soit refusé), tandis que les tâches auxquelles fait face l’Agent sont nettement plus complexes.

Un même type de transaction, 10 dollars et 100 000 dollars ne sont pas équivalents ; interagir avec un protocole utilisé à long terme n’est pas la même chose qu’accorder une autorisation soudaine à un contrat inconnu ; effectuer un Swap demandé explicitement par l’utilisateur n’est pas du même niveau de risque qu’un Agent qui décide seul de transférer les actifs sur une autre chaîne.

Ainsi, plus l'agent peut agir de manière autonome, plus ses autorisations ne peuvent se limiter à un simple interrupteur.

Ce dont il faut vraiment, c’est un mécanisme de sécurité qui lui permette de se déplacer librement à l’intérieur des limites et qui l’arrête automatiquement lorsqu’elle les dépasse.

En fait, OpenClaw n'a pas ignoré cette question.

Il propose actuellement un mécanisme de permissions multicouches, par exemple les plugins peuvent suspendre une action spécifique et demander une confirmation de l'utilisateur, et pour les commandes hôtes, il existe des autorisations d'exécution indépendantes et des listes blanches, entre autres.

Cela représente un grand pas en avant par rapport à la transmission immédiate de tous les outils et autorisations à l’Agent. Toutefois, lorsque l’Agent entre réellement dans des scénarios de paiement, de négociation et de gestion d’actifs, un problème plus précis surgit : autoriser l’Agent à utiliser une capacité n’est pas la même chose que lui accorder l’autorisation d’accomplir une action spécifique.

Permettre à l'Agent d'utiliser un navigateur ne signifie pas lui autoriser d'acheter n'importe quoi sur n'importe quel site web ; permettre à l'Agent d'accéder à votre courrier électronique ne signifie pas lui autoriser à envoyer des e-mails au nom de n'importe qui ; de même, permettre à l'Agent d'appeler un portefeuille ne devrait jamais équivaloir à lui autoriser à envoyer n'importe quel montant à n'importe quelle adresse.

Ainsi, le système de permissions à l'ère des Agents pourrait nécessiter de distinguer deux questions distinctes. L'une concerne les permissions de capacité, c'est-à-dire si l'Agent peut utiliser un navigateur, un terminal, un courriel ou un portefeuille. L'autre concerne une autorisation d'action plus spécifique : à cet instant précis, l'action qu'il est sur le point d'effectuer est-elle véritablement autorisée par l'utilisateur ?

Comment permettre à l’agent de s’automatiser pleinement dans des limites clairement définies, tout en rétablissant la prise de décision entre les mains de l’utilisateur lorsqu’il franchit réellement ces limites ?

C'est également la raison pour laquelle imToken explore Sigil. Son objectif principal n'est pas d'ajouter un autre « popup de confirmation » au sens traditionnel à l'Agent, mais de créer une barrière de sécurité clairement encadrée entre l'utilisateur et l'Agent grâce à des signatures vérifiables et un contrôle des autorisations granulaire.

L'un des principes les plus importants est « What you see is what you sign » : ce que vous voyez, vous le signez.

En résumé, les utilisateurs peuvent accorder à l’agent des autorisations préalables dans une plage définie, permettant aux actions à faible risque et conformes à la stratégie établie d’être automatisées ; lorsque les opérations atteignent des limites de montant, des protocoles inconnus ou d’autres limites de permissions critiques, l’exécution est suspendue et la demande spécifique est renvoyée à l’utilisateur pour confirmation.

Plus important encore, cette confirmation ne devrait pas se limiter à une vague phrase du type « L'agent est prêt à exécuter la transaction, êtes-vous d'accord ? » ; ce que les utilisateurs ont réellement besoin de voir, ce sont les paramètres clés qui changeront réellement dans cette opération : quels actifs sont utilisés, quel est le montant, qui est l'entité avec laquelle l'interaction a lieu, et quelle action exacte va être exécutée.

Une confirmation n'a de sens que lorsque le contenu vu par l'utilisateur, le contenu autorisé par l'utilisateur et le contenu finalement exécuté par le système correspondent.

Sigil tente également, autour de ce point, d'utiliser des mécanismes tels que les Passkey, la biométrie, la signature unique, une durée de validité courte et la liaison des paramètres de demande, afin que les autorisations critiques puissent être non seulement comprises par l'utilisateur, mais aussi vérifiées par le système.

Cela signifie qu'une autorisation ne se limite pas à « quelqu'un a cliqué sur confirmer », mais peut aller plus loin en précisant qui a approuvé, ce qui a été approuvé, et si l'action effectivement exécutée correspond bien à celle vue à ce moment-là.

Du point de vue de cette perspective, ce que Sigil cherche vraiment à résoudre, ce n'est pas « comment faire en sorte que l'Agent en fasse moins ».

Quite the opposite.

Il cherche à résoudre la question de savoir comment permettre à un Agent d'effectuer davantage d'actions en toute sécurité sans que l'utilisateur ne perde le contrôle final (lecture complémentaire : De cliquer aveuglément sur « Oui » à comprendre avant de signer : comment Sigil ajoute une protection de sécurité aux AI Agents ?).

Si on recule encore un peu le point de vue, on constate que c'est en réalité un changement de rôle que les portefeuilles sont en train de vivre.

Depuis la naissance d'Ethereum, le portefeuille imToken a vécu et observé deux générations clés : de l'ère 1.0, gérant une clé privée unique, à l'ère 2.0, optimisant l'expérience d'interaction grâce à l'abstraction de compte (AA).

Avec la popularisation d'agents autonomes tels qu'OpenClaw 2.0, les portefeuilles entrent sans aucun doute dans une troisième génération d'évolution, nécessitant une aide accrue pour gérer des agents capables de prendre des décisions autonomes et de fonctionner en continu.

C'est pourquoi les compétences accumulées par l'industrie des portefeuilles en matière de gestion des clés privées, de signature numérique, d'authentification d'identité et d'isolation des autorisations pourraient acquérir une nouvelle signification à l'ère des agents.

Ces technologies visent apparemment à résoudre la question « Comment signer en toute sécurité une transaction sur chaîne », mais traitent en réalité un problème plus général : comment prouver qu’une action a bien été autorisée par un sujet réel.

Aujourd'hui, cette action pourrait consister à transférer 1 ETH. À l'avenir, elle pourrait également consister à envoyer un e-mail, modifier un fichier, utiliser un identité numérique, acheter un service ou permettre à un Agent d'exécuter en continu une stratégie automatisée pendant la semaine à venir.

Ces comportements ne se produisent pas nécessairement tous sur la blockchain, mais la relation sous-jacente est très similaire : l'agent appelle une capacité appartenant à l'utilisateur au nom de cet utilisateur.

Ainsi, la signification de Sigil ne se limite pas nécessairement au Crypto.

Lorsque OpenClaw, Hermes et d'autres agents exécutés sur des appareils personnels ou dans des environnements cloud se connectent progressivement aux e-mails, aux messageries instantanées, aux calendriers, aux fichiers, aux navigateurs, aux terminaux et aux outils de paiement, la question « comment prouver que cette action a bien été autorisée par l'utilisateur » deviendra de plus en plus courante.

Ainsi, Sigil pourrait éventuellement s'étendre au-delà des transactions sur chaîne pour inclure l'accès aux données, l'utilisation d'identités, la modification de fichiers, la publication de contenu, l'achat de services et les tâches automatisées.

Dans l'ensemble, en tant qu'exploration commune d'imToken et d'OpenClaw, Sigil vise à intégrer les dix années d'expérience accumulées par imToken dans les domaines de l'autogestion, des portefeuilles et de la signature numérique, dans une nouvelle phase où les agents autonomes commencent à entrer dans un environnement d'exécution réel.

Il ne remplace pas l'agent, ni le portefeuille.

Il se tient entre les deux.