Clés de session et permissions : délégation sur blockchain

Les clés de session et les autorisations d'agent sont un moyen pour un compte intelligent de déléguer un mandat étroitement défini à une application ou à un agent IA, appliqué sur la chaîne par la logique de validation du portefeuille.

L'objectif est une exécution autonome sur la chaîne sans transformer un agent en signataire à plein pouvoir, en utilisant des limites telles que des fenêtres temporelles, des listes d'autorisation et un plafond de dépenses que le contrat peut refuser de dépasser.

Points clés

• Une clé de session est un justificatif de signature temporaire avec une autorité limitée, conçu de manière à ce qu'une approbation puisse couvrir un ensemble d'actions limitées à l'intérieur d'un champ défini.
• La mise à niveau de sécurité provient des comptes intelligents appliquant la politique sur la chaîne, et non du fait que la clé soit « temporaire ».
• ERC-4337 rend l'exécution déléguée opérationnelle grâce aux UserOperations, aux bundlers et à un contrat EntryPoint canonique, avec des paymasters optionnels qui peuvent sponsoriser.gaz.
• ERC-8196 propose la prochaine étape pour la conception de portefeuilles d'agents : une preuve cryptographique de conformité aux politiques plus une chaîne de hachage.auditpiste pour l'activité de session.

Bases des clés de session et des autorisations des agents

La délégation commence par une simple séparation : une identité conserve le contrôle total, tandis qu'une autre identité obtient une tâche limitée. Dans une configuration de compte intelligent, la clé maîtresse du propriétaire reste "racine", tandis qu'une clé de session est créée ou autorisée pour une fenêtre et un périmètre spécifiques. Ce périmètre est ce que les gens entendent par permissions d'agent ou accès d'agent limité.

L'application ou l'agent peut signer, mais uniquement à l'intérieur de la zone que le contrat de portefeuille reconnaît.

Ce cadre est important pour l'exécution autonome onchain car les agents savent déjà comment signer des transactions. Le mode de défaillance consiste à leur donner une clé d'accès total et à espérer que l'hôte, l'invite, l'arbre de dépendance et l'interface utilisateur ne vous trahissent jamais. Les clés de session adoptent une posture opposée.

Elles représentent un budget de risque que vous pouvez évaluer : temps + cibles + limites de valeur, avec le contrat de portefeuille agissant comme le videur.

Un modèle mental utile est « badge, pas clé maîtresse ». Le badge peut ouvrir quelques portes, pendant quelques heures, pour une tâche spécifique. Si le badge fuit, le rayon d'explosion est censé être limité par conception. C'est pourquoi l'expression clés de session crypto apparaît souvent aux côtés des comptes intelligents et des portefeuilles intégrés. L'idée est d'avoir moins d'approbations répétées sans donner un contrôle permanent et illimité à une application.

Deux détails sont faciles à manquer. Tout d'abord, « temporaire » n'est pas la propriété de sécurité. C'est la portée qui l'est. Deuxièmement, les clés de session ne sont pas standardisées partout aujourd'hui. Les implémentations varient encore d'un portefeuille à l'autre, ce qui signifie que la sémantique exacte de la révocation, des listes autorisées et des cas particuliers varie selon les fournisseurs.

Comment les comptes intelligents appliquent les permissions

ERC-4337 change l'endroit où l'autorisation se produit. Au lieu qu'un EOA diffuse une transaction normale dans le mempool public, un compte intelligent attend une UserOperation qu'il peut valider selon ses propres règles avant que quoi que ce soit ne s'exécute. L'agent signe la UserOperation avec une clé autorisée, un bundler agrège les UserOperations, et le bundler appelle un contrat EntryPoint canonique qui les traite. Le système de permission se trouve au niveau de validation du compte intelligent, et non dans l'interface utilisateur.

Cette architecture est la raison pour laquelle « faites confiance à l'application » peut être remplacé par « le contrat refuse ». RebelFi capture le changement avec deux phrases qui valent la peine d'être conservées telles quelles : « faites confiance au code de l'application agent pour ne pas dépasser le budget » contre « le contrat impose la politique de dépenses indépendamment de ce que fait l'application ».

La deuxième phrase est le mécanisme réel. Si la politique dit non, l'opération ne se valide pas, et EntryPoint ne l'exécute pas.

Les payeurs sont l'autre élément qui permet aux agents de se sentir toujours actifs. Dans l'ERC-4337, un payeur peut sponsoriser le gaz, ce qui signifie qu'un agent détenant des USDC et aucunETHpeut toujours effectuer des transactions si un paymaster est configuré pour accepter des USDC en échange de la couverture des frais de gaz ETH. Ce n'est pas un simple truc cosmétique d'UX.

Cela supprime l'exigence opérationnelle de maintenir un solde ETH séparé rechargé juste pour que l'agent puisse continuer à fonctionner.

C'est aussi ici que eip 7702entre dans la conversation. ZeroDev positionne sa pile comme supportant à la fois ERC-4337 et eip 7702, avec des clés de session comme un élément UX de première classe pour l'automatisation. Le fil conducteur est le même : déplacer la délégation dans un portefeuille qui peut faire respecter la politique, plutôt que de la laisser comme une promesse hors chaîne.

Portées et limites de permission communes

Une politique de session n'est aussi bonne que les réglages qu'elle expose et fait respecter. L'exemple concret de RebelFi est un modèle clair de la façon dont les permissions des agents devraient se présenter lorsque quelqu'un a réellement du capital en jeu : un maximum de dépense par transaction (exemple : 50 $), une liste de destinataires approuvés, une fenêtre d'expiration (exemple : 24 heures), et un budget total de session (exemple : 500 $) avant ré-autorisation. Ce dernier point est important car « de nombreux petits coups » peuvent s'accumuler même lorsque chaque transfert individuel est plafonné.

Ces réglages correspondent à la façon dont les comptes intelligents valident l'intention :

1. Limites de temps. Une fenêtre validAfter et validUntil rend la clé inutile en dehors de la session, ce qui réduit la valeur de son vol. 2. Contraintes cibles. Les listes de destinataires autorisés ou les contrats autorisés empêchent la clé d'être réutilisée pour des transferts arbitraires. 3. Contraintes de valeur.

Un plafond de dépense par transaction limite les dommages d'un coup unique, tandis qu'un budget total limite les dommages en goutte à goutte.

La révocation est le filet de sécurité opérationnel. Dans l'architecture de RebelFi, la clé de signature racine conserve le contrôle total du compte et peut révoquer les clés de session à tout moment. C'est la différence entre délégation et abandon. La clé propriétaire ne « partage pas l'identité ». Elle émet un mandat qui peut être annulé.

Une nuance de plus : les clés de session sont souvent décrites comme « temporaires clés privées,” mais cette description est incomplète. La clé n'est qu'un signataire. La sécurité provient du compte intelligent qui refuse de valider les opérations qui violent la politique. Sans cette application on-chain, “temporaire” peut encore être catastrophique à l'intérieur de la fenêtre.

Flux de travail des agents activés par délégation

La délégation ne concerne pas seulement la commodité. Elle change ce qui est réalisable sans transformer chaque étape en une nouvelle cérémonie de signature. Le cas d'utilisation évident est les paiements des agents. Un portefeuille d'agent peut être autorisé à payer un ensemble de prestataires de services pré-vérifiés tout en étant bloqué pour transférer des fonds vers des adresses arbitraires.

Le regroupement atomique est le déverrouillage de second ordre. Les comptes intelligents ERC-4337 peuvent exécuter des transactions par lots atomiques, donc des séquences comme retirer-de-rendement + payer-pour-service réussissent ou échouent ensemble. Cela compte car cela empêche un état inachevé. Si la partie paiement échoue, la partie retrait revient en arrière, et les fonds ne se retrouvent pas bloqués dans un état intermédiaire non voulu.

Le regroupement apparaît également comme un levier de coût mesurable. RebelFi estime que deuxtransferts ERC-20 séparément coûtent environ 2 × 65 000 gaz contre environ 1 × 110 000 gaz en lot, ce qui représente environ 15 % d'économies. Sur un écran, c'est la différence entre un flux de travail d'agent qui est économiquement viable à grande échelle et un qui saigne des frais.

Le parrainage des frais de gaz relie le tout pour les agents « sans ETH ». Avec un payeur de frais, l'agent peut opérer en ne détenant que des USDC, à condition que le payeur de frais accepte les USDC pour les frais de gaz. C'est la réponse pratique à la misconception selon laquelle les agents doivent détenir de l'ETH pour fonctionner.

Le positionnement de ZeroDev est cohérent avec cette vue de flux de travail. Sa documentation présente les clés de session comme faisant partie d'un ensemble d'outils UX de compte intelligent plus large qui inclut le regroupement et l'abstraction des frais de gaz, et elle affirme alimenter plus de 6 millions de comptes intelligents à travers plus de 50 réseaux pour plus de 200 équipes.

Cette affirmation d'échelle n'est pas une garantie de sécurité, mais c'est un signal que ces modèles sont déjà utilisés dans des piles de production.

Exécution liée à la politique et pistes de vérification

L'ERC-8196 est la déclaration la plus claire de la direction que prennent les permissions des agents : des portefeuilles qui exécutent des actions uniquement lorsqu'elles sont accompagnées d'une preuve cryptographique que l'action respecte une politique définie par le propriétaire. Ce n'est pas juste « définir des limites dans une interface utilisateur ». C'est « prouver la conformité au moment de l'exécution », le portefeuille agissant comme point d'application.

La proposition spécifie les champs de politique requis qui ressemblent à une version formalisée des politiques de session d'aujourd'hui : actions autorisées, contrats autorisés et bloqués, valeur maximale par transaction, fenêtre de validité et seuil de score de vérification minimum.

Elle introduit également un concept de piste de vérification immuable et chaînée par hachage pour l'activité de session, où chaque entrée d'audit inclut un hachage précédent pour l'intégrité. L'ERC-8196 permet aux implémentations de stocker des entrées hors chaîne et de publier périodiquement des racines sur chaîne, ce qui est un compromis pragmatique entre coût et vérifiabilité.

C'est le jeu final impliqué par la thèse : les clés de session ne deviennent significativement sûres que lorsque le portefeuille peut appliquer la politique sur chaîne, et le prochain rempart est la conformité vérifiable plus l'auditabilité. Si un hôte d'agent est compromis, « les journaux disent qu'il a agi » n'est pas suffisant.

Une piste de vérification à preuve de falsification plus une exécution liée à la politique est plus proche de la posture que les plateformes régulées et les opérateurs sérieux souhaitent.

Deux mises en garde doivent être mentionnées dans la même phrase. L'ERC-8196 est explicitement en revue par les pairs, donc l'interface et les exigences peuvent changer. D'autre part, même un standard parfait ne supprime pas le risque d'implémentation. La logique de validation du portefeuille, les vérifications de conformité et la plomberie d'audit doivent toujours être construites correctement.

Risques, mises en garde et meilleures pratiques

La misconception coûteuse est de penser qu'une clé de session est sûre parce qu'elle est temporaire. Les limites de temps aident, mais un champ totalement ouvert à l'intérieur de la fenêtre reste un champ totalement ouvert. Une clé de 24 heures qui peut transférer à n'importe quelleadresse est un bouton de drainage de 24 heures.

La deuxième idée reçue est la portabilité. Les clés de session ne sont pas standardisées partout aujourd'hui, et les implémentations varient d'un portefeuille à l'autre. Cela signifie que les « autorisations d'agent » peuvent sembler similaires à travers les produits tout en se comportant différemment aux extrémités, y compris le comportement de révocation et la manière dont les listes d'autorisation sont appliquées.

La troisième idée reçue est opérationnelle : les agents ont besoin d'ETH pour fonctionner. Les paymasters ERC-4337 peuvent sponsoriser le gaz, permettant à un agent détenant des USDC et pas d'ETH de transiger si le paymaster est configuré pour accepter des USDC.

La meilleure pratique est d'écrire des politiques comme des limites de risque, pas comme des bascules de fonctionnalités :

1. Commencez par un petit plafond de dépenses par transaction. C'est le moyen le plus rapide de limiter les dommages d'un coup. 2. Utilisez une liste d'autorisation stricte de destinataires ou de contrats. Si l'agent ne peut pas nommer la cible dans la politique, il ne devrait pas pouvoir y toucher. 3. Gardez la fenêtre de validité courte. L'expiration réduit la valeur d'une clé divulguée. 4. Ajoutez un budget total de session. Cela empêche les « nombreuses petites frappes » de saigner le compte.

Le regroupement est aussi un outil de sécurité, pas seulement un truc de gaz. Les lots atomiques réduisent la probabilité de se retrouver avec un état à moitié complété lorsque le flux de travail d'un agent s'étend sur plusieurs étapes.

La révocation doit être considérée comme un contrôle de premier ordre. Les sources sont explicites que la clé racine du propriétaire peut révoquer les clés de session. Opérationnellement, cela implique de concevoir des interrupteurs d'arrêt rapides et de traiter les nonces et l'expiration comme des contrôles essentiels pour réduire les problèmes de répétition et de timing.

C'est ici que l'histoire plus large de l'exécution autonome se pose : les conceptions gagnantes déplacent la délégation des promesses d'application vers des limites imposées par contrat, puis ajoutent une conformité vérifiable et une traçabilité des audits par-dessus.

La conclusion

J'ai vu des équipes traiter la « clé temporaire » comme un argument de sécurité puis expédier discrètement une session qui était largement ouverte sur les cibles ou le budget. La clé a expiré, c'est sûr. Les fonds étaient toujours partis à l'intérieur de la fenêtre. La seule version de cela qui tient est lorsque la couche de validation du compte intelligent est celle qui dit non, pas un hôte d'agent ou une case à cocher d'interface utilisateur.

La posture propre est de considérer une clé de session comme un mandat tarifé : horloge courte, liste blanche stricte, petit plafond de dépenses par transaction, et un budget total fixe. Si le système prend également en charge le regroupement atomique et les payeurs, l'agent peut se sentir toujours actif sans être toujours dangereux.

C'est la direction vers laquelle l'exécution autonome sur chaîne converge, et l'ERC-8196 est la première tentative sérieuse de faire de la conformité et de l'auditabilité une partie du travail du portefeuille, et non une réflexion après coup.

Sources

• RebelFi
• Propositions d'Amélioration d'Ethereum
• CryptoAdventure
• Docs ZeroDev