Ne jamais exposer ses secrets dans le contexte IA : credentials, clés API et vault

Un agent IA a besoin de vos credentials pour agir. Mais les lui passer en clair dans le contexte, dans un fichier MEMORY.md ou dans un message Telegram — c'est une catastrophe silencieuse. Une surface d'attaque que la plupart des équipes n'ont pas encore identifiée.

Le billet précédent de cette série couvrait la sécurisation de l'infrastructure OpenClaw : auth, SSL, reverse proxy. Ce quatrième volet s'attaque à un problème différent, plus subtil et souvent négligé : la gestion des secrets dans le contexte de l'agent IA lui-même.

1. Le paradoxe fondamental

Pour qu'un agent OpenClaw soit réellement autonome, il doit avoir accès aux services sur lesquels il agit. Clé API GitHub pour créer des PRs. Token SMTP pour envoyer des emails. Mot de passe Vaultwarden pour lire des credentials. Accès SSH pour piloter un serveur.

Le paradoxe : l'agent a besoin de ces secrets pour opérer — mais la façon dont on les lui fournit est critique. Passer une clé API directement dans un message, la coder en dur dans un script du workspace, ou la déposer dans MEMORY.md revient à l'exposer dans le contexte IA.

Et le contexte IA, contrairement à une variable d'environnement, est une surface d'attaque à part entière.

2. Pourquoi le contexte IA est une surface d'attaque

Voici ce qui rend le contexte IA fondamentalement différent d'une variable d'environnement classique :

Les logs d'historique

OpenClaw conserve l'historique des échanges. Telegram garde l'historique des messages. Ghost garde les logs de session. Si une clé API transite dans un message ou dans un fichier de workspace versionné, elle persiste dans des endroits auxquels on ne pense pas. Un git log devient un vecteur d'exfiltration.

Les réponses du modèle

Les LLMs peuvent reproduire — et reproduisent parfois — des données qu'ils ont vues dans leur contexte. Si une clé API est présente dans le contexte au moment d'une inférence, il n'est pas impossible qu'elle apparaisse dans une réponse, un log, ou un artefact généré. Ce n'est pas théorique : plusieurs incidents documentés impliquent des modèles "citant" des tokens de sécurité qui traînaient dans leur contexte d'entrée.

La prompt injection

Si un agent traite du contenu externe — emails entrants, pages web, issues GitHub — un acteur malveillant peut injecter des instructions dans ce contenu. Ces instructions peuvent tenter d'exfiltrer les secrets présents dans le contexte vers un endpoint distant. C'est le vecteur de la prompt injection indirecte, documenté par OWASP dans son Top 10 LLM Security.

La persistance mémoire

MEMORY.md, CODEX.md, les fichiers de state — tout ce qui persiste dans le workspace peut être relu par l'agent dans des sessions futures, ou par d'autres agents du réseau. Mettre un secret dans un fichier mémoire, c'est l'exposer à toutes les sessions qui liront ce fichier.

3. Les erreurs classiques — et pourquoi elles arrivent

Ces erreurs ne sont pas le fait de débutants. Elles arrivent souvent parce que la ligne entre "config opérationnelle" et "secret sensible" n'est pas clairement tracée.

La clé API dans MEMORY.md

Scénario : on configure l'agent pour envoyer des emails. On lui donne la clé SMTP dans un message. L'agent, pour ne pas redemander à chaque session, la note dans MEMORY.md. Résultat : la clé est maintenant dans le contexte permanent de toutes les sessions, dans Git (si le workspace est versionné), et potentiellement dans des logs d'historique.

Le mot de passe dans un message Telegram

Scénario : on veut que l'agent accède à un service. On lui envoie le mot de passe par Telegram pour "aller vite". Le message est stocké côté Telegram (serveurs tiers), dans l'historique de la session OpenClaw, et potentiellement loggé localement. Ce mot de passe est maintenant dans au moins trois endroits non contrôlés.

Le hardcode dans un script du workspace

Scénario : un script Python dans le workspace contient une variable API_KEY = "sk-..." en dur. Le workspace est Git. Le git log conserve la clé même si elle est ensuite supprimée. Un git log -p la retrouvera.

Les credentials dans les fichiers de config

Scénario : openclaw.json, config.yaml, ou tout fichier de configuration contient des tokens en clair. Si ce fichier est accidentellement commité, partagé, ou lisible par un autre process, les secrets fuient.

4. La solution : vault + injection dynamique

La règle d'or : les secrets ne vivent que dans le vault, et ne sont récupérés qu'au moment de l'exécution. Jamais en dur, jamais dans le contexte, jamais dans un fichier versionné.

Vaultwarden / Bitwarden CLI

BOTUM utilise Vaultwarden (Bitwarden self-hosted) comme gestionnaire de secrets central. Chaque credential est stocké dans le vault avec un identifiant unique. Aucun secret n'existe en dehors du vault.

L'agent, via le skill vault d'OpenClaw, peut récupérer un secret à la demande :

bw get password "github-token-fdbot"
bw get password "smtp-openclaw"
bw get password "docker-registry-key"

Ce secret est utilisé immédiatement en mémoire (variable shell, variable Python) et n'est jamais écrit dans un fichier.

Le pattern d'injection dynamique

#!/bin/bash
# ✅ Bon pattern : récupération au moment de l'exécution
TOKEN=$(bw get password "api-service-x")
curl -H "Authorization: Bearer $TOKEN" https://api.service-x.com/endpoint
unset TOKEN  # nettoyage immédiat

#!/bin/bash
# ❌ Mauvais pattern : hardcode
TOKEN="sk-abc123xyz"  # NE JAMAIS FAIRE
curl -H "Authorization: Bearer $TOKEN" https://api.service-x.com/endpoint

Rotation automatique

Avec le vault comme source unique de vérité, la rotation d'un secret est triviale : on change la valeur dans Vaultwarden, tous les scripts qui utilisent l'injection dynamique récupèrent automatiquement la nouvelle valeur sans aucune modification de code.

5. Variables d'environnement vs vault — quand utiliser quoi

Les deux ont leur place. La règle est simple :

La règle finale : aucun secret ne doit jamais être injecté dans le contexte de l'agent IA — ni via variable d'environnement, ni via vault. L'agent invoque un outil (script, skill) qui récupère et utilise le secret en isolation, sans que ce secret transite dans la fenêtre de contexte du LLM.

6. Bonnes pratiques OpenClaw

Le workspace Git : code + config, jamais de secrets

Le workspace OpenClaw est versionné par Git. Tout ce qui est commité devient permanent (même après suppression, le git log garde une trace). La règle absolue :

Le workspace Git ne contient jamais de secrets. Jamais.

Ce qui peut être commité : code, scripts (sans credentials), fichiers de configuration sans valeurs sensibles, templates.

Ce qui ne doit jamais être commité : clés API, mots de passe, tokens OAuth, certificats privés, clés SSH privées.

.gitignore strict — la liste minimale

# Secrets — JAMAIS dans Git
.env
.env.*
*.key
*.pem
*.p12
secrets.json
config.local.yaml
credentials.json
vaultwarden-master.txt

# OpenClaw spécifiques
MEMORY.md           # Peut contenir des infos sensibles
openclaw.json       # Contient parfois des tokens
*.session           # Sessions avec historique

Rotation régulière des secrets

Selon l'étude CyberArk 2025, 68% des incidents de sécurité impliquant des credentials sont liés à des secrets qui n'ont jamais été rotés. La recommandation BOTUM : rotation tous les 90 jours pour les tokens d'infrastructure, tous les 30 jours pour les clés d'accès API à haute valeur.

Principe du moindre privilège

Chaque agent ne reçoit que les permissions dont il a strictement besoin. L'agent email n'a accès qu'au compte email SMTP — pas au vault complet. L'agent rédaction n'a accès qu'aux APIs de publication — pas aux credentials SSH. Compartimenter = limiter l'impact d'une compromission.

7. Scénario réel : l'architecture BOTUM

Voici comment BOTUM a structuré la gestion des secrets pour son réseau de 15 agents OpenClaw :

Couche 1 : Vaultwarden self-hosted

Un Vaultwarden tourne sur us-srv-dck-01, accessible uniquement depuis le réseau interne. Tous les secrets y sont stockés, organisés par collection : infrastructure, apis-externes, agents-openclaw, smtp.

Couche 2 : Script d'injection isolé

Chaque agent dispose d'un helper script (vault-inject.sh) qui :

• Se connecte au vault via bw CLI avec un token de session éphémère
• Récupère le secret spécifique demandé
• L'injecte comme variable shell temporaire
• Exécute l'action
• Nettoie la variable immédiatement après

Couche 3 : Aucune persistance dans le contexte

Les agents ont accès au nom des secrets dans le vault (ex : "github-token-fdbot"), pas aux secrets eux-mêmes. Quand une action nécessite un credential, l'agent appelle le helper script — le secret ne transite jamais dans la fenêtre de contexte LLM.

Couche 4 : Audit et alertes

KNOX, l'agent sécurité du réseau, génère un rapport hebdomadaire sur l'usage des credentials : quels agents ont accédé à quels secrets, détection d'anomalies (accès inhabituels, horaires atypiques), rappels de rotation.

8. Checklist — 10 règles pour ne jamais leaker un secret

1. 🔐 Tout secret vit dans le vault — Vaultwarden, HashiCorp Vault, ou équivalent. Nulle part ailleurs.
2. 🚫 Zéro secret dans MEMORY.md, CODEX.md, ou tout fichier workspace — Ces fichiers sont persistants et lus par tous les agents.
3. 🚫 Zéro secret dans les messages Telegram/Slack/email — Les messageries ne sont pas des gestionnaires de secrets.
4. 🚫 Zéro hardcode dans les scripts — Même en dev local. Même "temporairement".
5. 🔎 .gitignore exhaustif — Inclure tous les patterns de fichiers sensibles avant le premier commit.
6. 🔄 Injection dynamique uniquement — Le secret est récupéré et utilisé en mémoire, jamais écrit.
7. 🔬 Principe du moindre privilège — Chaque agent n'accède qu'aux secrets dont il a strictement besoin.
8. ⏰ Rotation sur calendrier — 90 jours infra, 30 jours APIs haute valeur.
9. 📊 Audit régulier des accès — Qui a accédé à quoi, quand, depuis quel agent.
10. 🧹 Clean up des secrets révoqués — Un token expiré ou révoqué est supprimé du vault immédiatement.

Conclusion

La gestion des secrets dans un réseau d'agents IA n'est pas un problème marginal. C'est l'un des vecteurs de risque les plus silencieux de l'automatisation moderne : on déploie vite, on connecte des services, et les credentials finissent dans des endroits qu'on n'a pas anticipés.

L'approche de BOTUM — vault central, injection dynamique, aucun secret dans le contexte IA, rotation sur calendrier — n'est pas complexe à mettre en place. Elle demande de la discipline et des conventions claires. Mais elle élimine une catégorie entière de risques de façon durable.

Le billet suivant de cette série entre dans le concret opérationnel : configurer ses premiers agents spécialisés — JARVIS pour la gestion système, HERMÈS pour l'email, CHRONOS pour le calendrier — et définir les protocoles de coordination entre eux.

→ Billet 5 : Configurer ses premiers agents : JARVIS, HERMÈS, CHRONOS