Guide IA Agency : Permissions, Scopes & Limites de Dépenses Crypto

Points Clés à Retenir

• La délégation d'un agent IA consiste à accorder à un logiciel autonome une autorité limitée pour agir au nom d’une personne, d’une organisation, d’une application ou d’un compte blockchain.
• La délégation diffère de la transmission d’un mot de passe, d’une clé privée ou d’un compte administrateur illimité. Une délégation bien conçue ne fournit que le strict minimum d'autorité nécessaire à une tâche donnée.
• Les permissions définissent les actions autorisées pour un agent, telles que la lecture de fichiers, l’envoi de paiements, l'échange de tokens ou la création d'événements dans un calendrier.
• Les périmètres (scopes) déterminent les frontières de ces permissions, incluant quels comptes, applications, actifs, destinataires, réseaux et données l’agent peut accéder.
• Les plafonds de dépense restreignent la valeur financière qu’un agent peut mobiliser : par transaction, quotidiennement, par session, selon le token ou de façon cumulative.
• L’autorité déléguée peut être implémentée hors-chaîne via des jetons d’accès OAuth et des moteurs de politique d’API, ou en onchain au moyen de smart accounts, clés de session, modules d’allocation et contrats de permission.

Les agents IA ne se limitent plus à la génération de texte. Ils peuvent interroger des bases de données, gérer des calendriers, appeler des API, exécuter des trades, payer des services, interagir avec des smart contracts et coordonner avec d'autres agents. À mesure qu’ils gagnent en autonomie, la question centrale n’est plus seulement ce qu’ils peuvent comprendre, mais bien ce qu’il convient de les autoriser à faire.

Donner un accès illimité à un agent est dangereux. Un agent de voyage peut avoir besoin de rechercher des vols ou de réserver un hôtel, mais ne devrait pas accéder à tous les comptes bancaires. Un agent de trading peut requérir le rééquilibrage d’un portefeuille, mais ne doit pas pouvoir transférer l’ensemble d’une trésorerie vers un portefeuille inconnu. Un assistant d’entreprise peut lire des factures, mais ne doit pas pouvoir approuver ses propres paiements sans contrôle humain.

La délégation des agents IA résout ce problème en séparant l’autorité en permissions limitées et prédéfinies. Le principe s’apparente à la délégation des responsabilités dans une entreprise : un employé reçoit un accès aux systèmes, un budget et un périmètre de tâches précis, sans contrôle total sur l’organisation. La délégation numérique applique ce principe aux agents logiciels.

Pourquoi les Agents IA Ont-ils Besoin d’Autorité Déléguée ?

Un chatbot basique peut attendre une validation humaine à chaque étape. Un agent autonome utile doit souvent agir en l'absence active de l’utilisateur. Prenons l’exemple d’un agent gérant les abonnements logiciels d’une société : il doit surveiller les factures, vérifier les montants, payer les prestataires approuvés, identifier les doublons d’abonnements et alerter la comptabilité en cas d’anomalie.

Exiger une validation humaine pour chaque paiement de 20 $ limite l’intérêt de l’automatisation. Accorder à l’agent un accès illimité au compte bancaire comporte un risque inacceptable. La délégation apporte une solution intermédiaire.

L'entreprise peut autoriser l’agent à ne payer que les prestataires logiciels approuvés, via un compte désigné, avec une limite de 100 $ par transaction et 1 000 $ par mois. Toute opération hors de ce cadre requiert une validation humaine. Cela reflète le principe de sécurité du moindre privilège : chaque utilisateur ou processus doit recevoir seulement les ressources nécessaires à sa fonction. La délégation pour IA ne vise donc pas à accorder plus de pouvoir, mais à rendre leur autonomie assez sûre pour être utilisée.

Les Principaux Acteurs de la Délégation d’un Agent IA

Le Principal

L’Agent

La Ressource ou le Compte

La Couche d’Autorisation

L’Exécutant

Authentification vs. Autorisation

L’authentification et l’autorisation sont liées mais distinctes. L’authentification désigne – quel agent ou utilisateur réalise la demande ? L’autorisation pose la question – que peut faire ce demandeur authentifié ?

Un agent peut prouver son identité via des identifiants API, signature cryptographique, passkey ou adresse de wallet. Cela ne signifie pas pour autant qu’il doit avoir accès à toutes les fonctions. Un système sécurisé authentifie d’abord l’agent puis vérifie l’action demandée par rapport à ses permissions déléguées.

Par exemple, un agent peut prouver le contrôle d’une clé de session reconnue. Le wallet vérifie alors si cette clé est autorisée à transférer de l’USDC, si le destinataire est approuvé, si la limite journalière est atteinte et si la délégation n’est pas expirée. Seules toutes ces conditions réunies permettent l’exécution de l’opération.

Délégation d’Agent IA Hors-Blockchain (Offchain)

La majorité des agents IA actuels interagissent avec des services web classiques, pas directement avec la blockchain. La délégation offchain utilise généralement des jetons d’accès OAuth, des clés API à rôles restreints, le contrôle d’accès basé sur les rôles (RBAC), des systèmes d’identité cloud, des coffres à secrets et des passerelles d’application des politiques.

Un agent se connectant à un service email ou agenda peut recevoir un token OAuth lui permettant de lire certaines données sans jamais exposer le mot de passe utilisateur. Pour l’entreprise, un agent peut fonctionner via un compte de service n’ayant accès qu’à une base de données, sans droits sur les outils d’administration de production. L’approche MCP suit ce modèle, traitant les serveurs MCP comme des ressources OAuth et les clients comme des applications agissant pour le compte du propriétaire de la ressource.

Délégation d’Agent IA sur la Blockchain (Onchain)

Les agents blockchain nécessitent une approche différente en raison de l’irréversibilité des transactions. Transmettre la clé privée du wallet à un agent est une pratique risquée.

Quiconque a le contrôle de cette clé peut réaliser toutes les actions permises au wallet. On ne peut pas compter sur les invites de l’agent pour s’assurer du respect des limites de dépense ; seul le code onchain ou le wallet peut imposer ces limites de façon fiable.

Modules d’Allocation et Limitations de Dépense

Certaines solutions de wallet offrent déjà des contrôles de dépense adaptés aux agents. La documentation de Safe décrit une organisation de trésorerie IA, où un module d’allocation assigne à l’agent une limite par token qui peut être ponctuelle ou récurrente, par exemple une allocation journalière d’USDC. Safe propose des modèles alternatifs de sécurité pour agents IA : validation humaine, double signature (multi-agent), ou limites de dépense.

Coinbase Spend Permissions permet à un bénéficiaire désigné (« spender ») d’utiliser les tokens d’un smart account sous des restrictions portant sur le token, le montant et la plage de temps. La documentation évoque les cas d’usage comme les paiements agentiques et le trading algorithmique.

Le principe clé : l’autorité de dépense de l’agent doit être imposée par le wallet ou le smart contract, et non par le seul logiciel de l’agent.

Délégation vs. Transmission d’une Clé Privée

Donner à un agent une clé privée équivaut à lui confier le contrôle total. La délégation ne transfère qu'une autorité définie et restreinte.

Un wallet séparé avec un solde faible vaut mieux que de donner la clé principale, mais un smart account bien configuré permet des contrôles plus puissants, y compris en présence de fonds importants.

Délégation vs. Approvals de Token

Un approval ERC-20 permet à un « spender » de transférer des tokens jusqu’à un certain montant approuvé. C’est une forme basique de délégation mais souvent trop limitée pour des agents évolués : cela ne restreint pas le destinataire final, ni le protocole utilisé, la slippage, le sens du trade, l’horaire, l’exposition cumulée ou le motif de la transaction.

Les approvals sans limite sont particulièrement risqués : si le spender est compromis, le solde autorisé peut être transféré. Les systèmes de délégation avançés peuvent encapsuler les approvals dans des règles plus riches, associant limites de valeur, fonctions approuvées, contrats, destinataires, calendriers et nécessité de validation humaine.

Exemples d’Usage de la Délégation d’Agents IA

Paiements Agentiques – Un agent paie des appels API, données, calcul, stockage ou services digitaux. La délégation peut spécifier une limite basse par appel et un total de session supérieur, pour éviter de solliciter l’utilisateur à chaque achat.

Trading Automatisé – Un agent de trading passe des ordres, rééquilibre des actifs ou exécute des stratégies sous contraintes de marchés éligibles, tokens, taille maximale des positions, levier, slippage et pertes journalières.

Gestion de Trésorerie – Un agent IA surveille les soldes, transfère la trésorerie de fonctionnement, paie les fournisseurs ou alloue des stablecoins dormants. Le plus sécurisé repose sur une allocation opérationnelle distincte plutôt qu’un contrôle complet de la trésorerie.

Gestion d’Abonnement – Un agent paie des abonnements récurrents sous plafond par marchand et par mois, tout en demandant validation pour une hausse de tarif ou un nouveau marchand.

Opérations DAO – Une DAO mandate un agent pour distribuer des subventions, payer des contributeurs, collecter les revenus ou exécuter des décisions de gouvernance. L’agent opère à partir d’un Safe ou autre smart account doté d’allocations spécifiques à chaque token et sous contrôle multi-signature.

Principaux Risques de Sécurité

• Prompt Injection – Un document, site, message ou réponse API externe peut contenir des instructions visant à manipuler l’agent. Ex : une facture malveillante incite l’agent à ignorer sa mission initiale et à transférer des fonds. Les contrôles d’autorisation durs permettent d’annuler l’opération si le destinataire n’est pas sur la whitelist.

• Permissions Excessives – Les développeurs peuvent requérir des droits trop larges par facilité, ce qui amplifie les dégâts en cas de compromission de l’agent ou de ses identifiants.

• Vol d’Identifiants – Un attaquant subtilisant un token OAuth, une clé API, une clé de session ou un identifiant wallet d’agent peut soumettre des requêtes paraissant légitimes. Privilégier des identifiants à courte durée de vie, le stockage sécurisé, la révocation et des limites de transaction réduit le risque. MCP recommande en particulier des access tokens très courts.

• Confused-Deputy Attacks – Un agent de confiance peut se faire abuser pour utiliser ses droits au profit d’un attaquant, sans être lui-même compromis. Préciser des restrictions sur les destinataires, vérifier l’origine, utiliser des credentials spécifiques à une tâche et exiger la confirmation des paramètres sensibles peut réduire ce risque.

• Dépense Indirecte – Un agent peut respecter techniquement la limite de transfert mais créer ailleurs une exposition financière supérieure (ex : approuver un contrat malicieux, ouvrir une position à levier, fournir de la liquidité à un pool risqué, signer un ordre à règlement différé). Les politiques de délégation doivent englober les approbations de contrat, les engagements financiers et les risques futurs – pas seulement les transferts immédiats de tokens.

• Escalade de Privilèges – L’agent peut tenter d’installer un module, modifier un propriétaire, mettre à jour une politique ou créer des credentials à plus large autorité. Les actions administratives et de gestion des permissions doivent être exclues des scopes opérationnels.

• Redélégation Risquée – Un sous-agent peut recevoir des droits trop larges ou mal définis, rendant la chaîne de délégation peu auditable ou révocable.

• Permissions Obsolètes – Un agent conserve des accès après la fin d’un projet, d’un appareil, d’un employé ou d’une relation commerciale. L’expiration automatique et l’audit périodique des permissions sont indispensables.

• Complexité Cross-Chain – Les permissions sur une blockchain ne valent pas automatiquement sur une autre ; bridges, assets enveloppés et messages cross-chain introduisent de nouveaux contrats et tenants de sécurité non prévus à l’origine.

• Risque Oracle & Prix – Un plafond fondé sur la valeur dépend souvent d’un oracle externe. Un agent autorisé à dépenser l’équivalent de 1 000 $ peut dépasser cette somme si la source de prix est fausse ou manipulée. Les limites en token natif et en fiat se comportent donc différemment.

Existe-t-il des Standards de Permissions pour Agents IA ?

Les systèmes offchain reposent massivement sur des accès limités à la OAuth, tandis que MCP applique OAuth à la connexion agent-outil. Sur Ethereum, l’abstraction de compte et la délégation s’incarnent dans ERC-4337, EIP-7702, ERC-7710 et ERC-7715. Ces technologies permettent notamment la validation programmable, la délégation de capacités, la gestion des permissions de wallet et de l’exécution transactionnelle sous contrôle. Les fournisseurs de wallets et d’infrastructures adoptent aussi leurs propres modules d’allocation, permissions de dépense, systèmes de limitations et comptes agents.

L’avenir ne verra sans doute pas émerger un format de permission unique, mais un ensemble de standards interopérables pour permettre à agents, wallets, applications et serveurs d’autorisation d’échanger des mandats lisibles par machine.

La Délégation d’Agent IA en Une Phrase

Conclusion

Un agent IA devient utile lorsqu’il peut agir, mais agir suppose de l’autorité. La démarche la plus sûre n’est pas d’accorder un accès complet en espérant que l’agent se comporte bien, mais bien d’intégrer des frontières claires au sein des systèmes utilisés. Les permissions déterminent ce que l’agent peut faire. Les scopes déterminent où et sous quelles conditions. Les limites de dépense plafonnent la valeur en jeu. Expiration, révocation, logs d’audit et validation humaine ajoutent d’autres couches de contrôle.

Ces principes s’appliquent aussi bien au logiciel conventionnel qu’à l’infrastructure blockchain. Les jetons OAuth peuvent restreindre l’accès aux services web, tandis que les smart accounts, clés de session, contrats de délégation et modules d’allocation limitent l’exécution onchain. Avec l’essor des paiements agentiques, du trading automatisé, des agents de trésorerie et du commerce machine-à-machine, la délégation deviendra une infrastructure de base. Il faudra outiller les utilisateurs afin de donner aux agents suffisamment de pouvoirs pour travailler, mais jamais assez pour causer des pertes catastrophiques.

L’avenir des systèmes autonomes dépend donc non seulement de leur intelligence accrue, mais aussi du caractère précis, visible, limité et révocable de l’autorité qui leur est déléguée.

Inscrivez-vous maintenant sur Phemex