Aller au contenu
Sécurité

Les secrets dans OpenClaw

Des références plutôt que des clés en clair, les quatre fournisseurs, le coffre partagé, et l’audit qui prouve qu’il ne reste rien

6 min de lecture

Les pages sur les secrets d’OpenClaw partent d’un fait inconfortable : un identifiant en clair dans le fichier de configuration, un fichier dot-env, une ancienne archive de profils d’authentification ou un fichier de modèles généré est lisible par l’agent qui peut inspecter ces fichiers. Les références de secrets sont la réponse, additives et facultatives par identifiant : la configuration contient une référence, et la valeur est résolue depuis une variable d’environnement, un fichier, une commande ou un coffre partagé. Voici à quoi ressemblent les références, le modèle d’exécution qui garde les valeurs hors de portée de l’agent, le coffre et son proxy de sortie, et le flux qui prouve qu’aucun résidu en clair ne subsiste.

Le clair fonctionne toujours. Les références de secrets sont facultatives, identifiant par identifiant.

Les quatre fournisseurs

  • Env : la référence nomme une variable d’environnement, résolue sur l’hôte de la passerelle ; une entrée de fournisseur explicite peut porter une liste d’autorisation de noms de variables, et une liste vide refuse tout.
  • Fichier : la référence pointe vers un secret adossé à un fichier, les clés d’API en fichier étant le cas courant.
  • Exec : la référence lance une commande qui imprime le secret, ce qui est la façon dont 1Password, Bitwarden, Vault, pass et sops sont branchés dans les exemples de la documentation ; les chemins de commande stricts et en lecture seule font partie du contrat.
  • Coffre : le coffre de secrets SQLite partagé pour les secrets et valeurs d’environnement d’équipe, avec un proxy de sortie des secrets et une liste d’autorisation de trafic devant lui.

Le modèle d’exécution

Les secrets sont possédés et isolés : les valeurs sont injectées au moment de la sortie par des sentinelles plutôt que placées dans le contexte de l’agent, il y a une frontière explicite d’accès de l’agent, et seules les surfaces actives voient leurs secrets résolus, si bien qu’un identifiant pour un canal non activé n’est jamais chargé. Le démarrage échoue vite sur une référence cassée, les signaux de dégradation et de rétablissement sont remontés, et un instantané du dernier état valide garde la passerelle en marche lors d’un échec transitoire de résolution. L’outil masqué des secrets enseigne à l’agent une découverte par métadonnées d’abord et des demandes masquées limitées à la tâche, et l’invite achemine la collecte des identifiants par des flux masqués, jamais par la discussion.

Le flux

  • Audit : la commande d’audit des secrets avec son option de vérification signale les résidus en clair sur toute la surface d’identifiants prise en charge, pour que vous sachiez ce qui reste à migrer.
  • Configurer et appliquer : la commande de configuration construit un plan de références pour les champs pris en charge, et l’application l’exécute contre un contrat de plan, avec une politique de sécurité à sens unique qui n’efface jamais une valeur en clair tant que la référence n’a pas prouvé qu’elle se résout.
  • Ré-auditer, et garder en tête les notes sur l’héritage : les anciens fichiers plats de profils d’authentification ne sont pas un format d’exécution et sont importés dans le coffre SQLite par le docteur avec une sauvegarde.

Le fichier de configuration d’OpenClaw montre où se placent les références dans le fichier, et Bonnes pratiques de sécurité pour OpenClaw liste l’audit à côté des autres vérifications.

Où elles apparaissent

Chaque surface d’identifiants que décrit la documentation les accepte : clés de fournisseurs, jetons de canaux, variables d’environnement et en-têtes de serveurs MCP, matériel SSH de bac à sable, et les configurations d’extensions qui portent des clés. OpenClaw et les serveurs MCP est le cas que les gens rencontrent en premier, parce qu’une définition de serveur est exactement l’endroit où une clé se trouverait sinon à découvert.

Sur Diali

Sur Diali, les identifiants que vous ajoutez vivent dans le coffre, sont injectés dans l’instance à la sortie, et n’apparaissent jamais dans un fichier que l’assistant peut lire ; l’audit que décrit la documentation est la posture que nous exploitons pour vous. OpenClaw hébergé sur Diali est l’assistant et La sécurité sur Diali décrit la frontière.

  • Une référence dans la configuration ; la valeur depuis l’environnement, un fichier, une commande ou le coffre.
  • Injectés à la sortie, filtrés sur les surfaces actives, jamais dans le contexte de l’agent.
  • Auditer, configurer, appliquer, ré-auditer ; l’effacement est à sens unique et vient en dernier.
Commencer

Arrêtez de lire, construisez le vôtre

Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.