# Pourquoi un agent IA ne devrait jamais détenir de clé privée

> Une clé accorde une autorité illimitée et toute limite posée par-dessus est du logiciel. Une nomination se retire ; une clé copiée, non.

- Source: https://defiloops.com/fr/blog/why-an-ai-agent-should-never-hold-a-key
- Published: 2026-07-21
- Category: Security
- Tags: agentic-wallet, ai-agents, key-management, custody
- Author: DeFiLoops

---
La façon la plus rapide de construire un portefeuille agentique est de générer une clé
privée, de la donner à l’agent et d’écrire quelques règles sur ce qu’il peut en faire.
Presque toutes les premières versions fonctionnent ainsi, et le secteur cherche aujourd’hui à
en sortir — Coinbase a défendu l’argument publiquement, et il tient en une phrase.

Une clé privée n’est pas une permission. C’est *la* permission. Tout ce que vous empilez
par-dessus est une requête.

## Ce qu’une clé accorde réellement

<Compare left="Ce que disent les règles" right="Ce que la clé accorde" verdict>
  <Fragment slot="left">
    Dépense jusqu’à 500 USDC par mois. Seulement ces trois protocoles. N’envoie jamais à une
    adresse hors de la liste.
  </Fragment>
  <Fragment slot="right">
    Signe n’importe quelle transaction que ce compte peut faire, pour n’importe quel montant,
    vers n’importe quelle adresse, sur n’importe quelle chaîne, pour toujours.
  </Fragment>
</Compare>

La colonne de gauche est appliquée par le code qui se trouve tourner entre l’agent et la
chaîne. Celle de droite est appliquée par les mathématiques. Quand les deux divergent — bug,
compromission, modèle persuadé, processus redémarré avec la mauvaise configuration — la
droite gagne à chaque fois.

<Callout type="danger" title="Des règles au-dessus d’une clé sont un filtre, pas une frontière">
  Un filtre est évalué contre des attaques que quelqu’un a déjà imaginées. Il doit refuser
  correctement des choses qu’il n’a jamais vues, sous pression adverse, à vitesse machine.
  C’est un travail difficile, et il n’existe que parce que la clé l’a rendu nécessaire.
</Callout>

## L’asymétrie que personne n’anticipe

Voici la partie qui change l’architecture et non la configuration.

**On ne peut pas décopier une clé.**

Si une clé fuit — une ligne de log, un dump mémoire, une dépendance compromise, une sauvegarde
qui n’aurait pas dû exister — quiconque en a une copie a l’autorité totale, définitivement, et
vous ne pouvez pas savoir combien de copies existent. La faire tourner signifie déplacer tous
les actifs vers une nouvelle adresse, ce qui est à son tour un ensemble de transactions
auxquelles vous devez désormais faire confiance.

Une nomination, c’est l’inverse. Elle vit sur la chaîne, elle est vérifiée à chaque appel, et
elle se retire par une transaction qui n’exige la coopération de personne.

<Spec title="Une clé fuitée contre une nomination retirée" rows={[
  ['Combien de copies existent', 'Clé : impossible à savoir. Nomination : ce n’est pas une chose copiable'],
  ['Comment on l’arrête', 'Clé : en déplaçant tous les actifs. Nomination : une transaction depuis votre portefeuille'],
  ['Délai d’effet', 'Clé : quand le dernier actif a bougé. Nomination : au prochain appel'],
  ['De l’aide de qui', 'Clé : assez de gas sur chaque chaîne, et du temps. Nomination : de personne'],
  ['Si l’opérateur est hostile', 'Clé : il en a peut-être déjà une copie. Nomination : il ne peut pas s’en accorder une'],
]} />

## Ce qui remplace la clé

Trois réponses circulent, et elles ne sont pas équivalentes.

<Steps>
  <Step title="Découper la clé (MPC ou multisig)">
    Personne ne signe seul, et un moteur de politiques décide de ce qui est cosigné. C’est la
    réponse commerciale dominante et une vraie amélioration : il n’y a plus un objet unique
    dont le vol met fin à l’histoire.

    Ce que cela ne change pas, c’est l’expressivité. Ce qui est cosigné reste une transaction
    arbitraire, donc le moteur de politiques reste un filtre décidant si une adresse de
    destination est acceptable.
  </Step>
  <Step title="Garder la clé loin du modèle">
    Mettez la clé de signature dans du matériel ou un service distinct que le modèle ne peut
    pas lire, et laissez le modèle seulement demander des signatures. Encore mieux : un modèle
    persuadé ne peut plus exfiltrer la clé.

    Mais un modèle persuadé peut toujours demander la mauvaise chose, et quelque chose doit
    encore juger la demande.
  </Step>
  <Step title="Ne lui donner ni clé ni vocabulaire pour une adresse">
    L’agent est un contrat que votre compte nomme. Ce qu’il soumet est un formulaire fixe de
    cases étiquetées, tirées d’une liste fermée d’opérations. Pas de case pour une destination
    ni pour une charge utile ; les destinations sont des rôles, résolus depuis votre compte au
    moment de l’exécution.

    Un modèle persuadé ne peut pas exprimer « envoie-le-moi », donc rien n’a besoin de détecter
    qu’il a essayé.
  </Step>
</Steps>

## Ce que nous détenons réellement

Autant être concret, car « l’agent est un contrat » appelle la question de ce qui reste de
notre côté.

<Spec rows={[
  ['L’agent', 'Un contrat. Votre compte le nomme. Une clé simple ne peut pas être nommée'],
  ['Le keeper', 'Une clé que nous détenons. Son seul pouvoir est de dire à ce contrat de faire un appel'],
  ['Le payeur de frais', 'Paie le gas. Ne détient aucun actif, aucune permission de dépense permanente'],
]} />

Une clé de keeper volée ne peut pas prendre votre compte. Le contrat refuse sur la chaîne,
avant que l’appel n’ait lieu : il ne visera pas votre compte directement, n’exécutera pas les
instructions qui installent des permissions ou changent la propriété, et ne touchera pas une
opération que vous n’avez jamais activée. Il est aussi borné par des plafonds fixés dans votre
compte que rien de notre côté ne peut relever.

<Callout type="warn" title="Là où ce n’est pas hermétique, dit clairement">
  La protection fonctionne comme une liste d’actions interdites, non comme une liste d’actions
  permises. Elle bloque totalement une prise de contrôle — l’agent ne peut jamais devenir
  propriétaire ni céder votre compte — mais elle ne bloque pas toute voie par laquelle la
  valeur pourrait bouger via une action que personne n’a pensé à interdire. Nous avons prouvé
  quatre attaques de ce type contre nous-mêmes, sur une copie du vrai réseau Base. Il n’y a pas
  d’audit externe.

  Le service qui détient la clé du keeper refuse aussi de démarrer en environnement de
  production, délibérément, parce qu’il garde pour l’instant cette clé en mémoire.
</Callout>

## La porte à sens unique

Une propriété de plus, car c’est l’autre moitié de « une nomination se retire ».

Votre compte ne peut jamais être repointé vers un **autre** agent. La première nomination
engage, et le seul changement permis est vers aucun.

<Quote>
  Un compte dont l’agent peut être remplacé contient un rôle : celui qui peut faire le
  remplacement. Ce rôle est une cible, et le problème est qu’il existe.
</Quote>

C’est une vraie contrainte pour nous, pas une fonctionnalité dont nous profitons. Cela veut
dire que nous ne pouvons pas corriger un agent déployé sous vos pieds. Un nouvel agent est
quelque chose vers quoi vous migrez délibérément, avec un nouveau compte. Plus lent pour
nous ; c’est le but.

## Comment évaluer tout cela

Nul besoin de croire une page sécurité. Demandez ce que l’agent peut écrire.

Si la réponse contient une adresse, tous les contrôles listés par ce fournisseur sont un
filtre entre un modèle persuadable et votre argent — et les filtres sont jugés contre les
attaques que quelqu’un a déjà imaginées. Si la réponse ne contient pas d’adresse, demandez où
le plafond de dépense est appliqué et si vous pouvez partir avec leurs serveurs éteints.

Ces deux questions séparent les conceptions plus vite que n’importe quelle documentation.