Sécurité des agents IA : clés API, sandbox et limites

La sécurité des agents IA se résume à trois choses : l’agent ne voit que ce dont il a besoin, les clés API ne traînent pas là où l’agent (ou un attaquant) peut les lire, et chaque clé a un plafond de dépenses. Voici cinq étapes que l’on peut boucler en un après-midi : permissions, sandbox, rangement des clés, limites et scan des dépôts.

Pourquoi la sécurité des agents IA est-elle devenue urgente ?

Les dernières semaines ont fourni des exemples à la pelle. Après la fuite chez OpenCode, des utilisateurs ont montré des factures pour l’usage de leurs clés par d’autres. Lors de la cyberattaque IA contre plus de 100 entreprises, des agents se sont introduits presque sans intervention humaine, et des centaines de secrets traînaient sur des panneaux Cairn exposés. Sans compter que la fuite de Meta Muse a montré que même une fonction « partager le chat » peut en dévoiler plus qu’on ne le croit.

Le 21 octobre, nouvelle affaire : selon SafeDep, la version 1.107.0 de la populaire bibliothèque LiteLLM a été publiée sur PyPI avec un stealer qui collectait notamment des clés SSH, des identifiants cloud, des secrets CI/CD et des clés des fournisseurs de LLM, ainsi qu’une porte dérobée. Les attaquants disposaient des identifiants GitHub CLI de trois développeurs. PyPI a retiré cette version le jour même ; la 1.106.2, entre autres, est saine.

Ce qui distingue un agent d’un chat, c’est qu’il agit : il lit des fichiers, lance des commandes, visite des pages web. L’OWASP décrit deux risques principaux :

1. L’injection de prompt. Selon l’OWASP, dans sa variante indirecte, le modèle reçoit des instructions « from external sources, such as websites or files ». Un README ou une page contenant une instruction cachée suffit pour que l’agent fasse quelque chose qu’on ne lui a jamais demandé.
2. L’autonomie excessive (« excessive agency »). L’OWASP cite trois causes : trop de fonctionnalités, trop de permissions et trop d’autonomie. Dans l’aperçu de la liste 2026, ce risque est monté à la troisième place.

L’OWASP tient aussi un Top 10 dédié aux applications agentiques, dont la première place revient à « Agent Goal Hijack », c’est-à-dire le détournement de l’objectif de l’agent.

La règle d’or des deux listes est la même : les permissions minimales suffisantes pour la tâche, et l’accord d’un humain pour les actions risquées.

Étape 1 : comment régler les permissions dans Claude Code ?

Je vais le montrer sur Claude Code (présenté de zéro dans mon tutoriel Claude Code), mais la même logique vaut pour les autres harnais d’agents.

Les permissions se règlent dans settings.json sous forme de règles allow, ask et deny. Selon la documentation, l’ordre est fixe : « deny, then ask, then allow », donc un refus l’emporte toujours. Commençons par bloquer l’accès aux secrets. Cet exemple vient tout droit de la référence des paramètres :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

Point important : les règles deny ont leurs limites, et la documentation les énonce clairement :

1. Elles ne s’appliquent pas aux commandes qui lisent des fichiers sans les nommer, comme grep -r pattern ., ni aux sous-processus arbitraires.
2. Bash(curl *) correspond à la commande au mot près, donc elle n’arrêtera pas /usr/bin/curl ni sh -c 'curl …'.
3. Un fichier .claudeignore n’a aucun effet ; ses entrées doivent être déplacées vers des règles Read dans deny.

Les règles sont donc une première couche, pas toute la protection. On vérifie les permissions actuelles avec la commande /permissions.

Deuxième point : le mode de travail. Claude Code propose les modes default, acceptEdits, plan, auto, dontAsk et bypassPermissions. Au sujet du dernier, la documentation écrit : « Only use this mode in isolated environments like containers or VMs ». Sur un ordinateur partagé, on peut le désactiver complètement en réglant permissions.disableBypassPermissionsMode sur "disable".

Étape 2 : comment activer la sandbox ?

La sandbox est une frontière gardée par le système d’exploitation lui-même, elle agit donc là où les règles deny n’arrivent pas. Selon la documentation de la sandbox, elle est désactivée par défaut. On l’active avec une commande dans la session :

/sandbox

ou en réglant sandbox.enabled sur true dans ~/.claude/settings.json. Sur macOS, elle fonctionne d’emblée ; sur Linux et WSL2, il faut deux paquets :

sudo apt-get install bubblewrap socat

Sous Windows sans WSL2, pas de sandbox : les commandes s’exécutent sans isolation.

Ce qu’apporte la sandbox une fois activée :

1. Les commandes n’écrivent que dans le répertoire de travail et les fichiers temporaires.
2. Le trafic réseau passe par un proxy local, et la liste des domaines autorisés (network.allowedDomains) est vide au départ.
3. En revanche, elles peuvent lire la majeure partie du disque, y compris ~/.ssh et ~/.aws/credentials. Ces chemins sont à bloquer soi-même via filesystem.denyRead ou la section credentials, car, comme le dit la documentation, « There is no built-in credential deny list ».

Deux remarques tirées de la documentation. D’abord, la sandbox ne couvre que les commandes shell : les outils Read, Edit, Write et WebFetch, les hooks et les serveurs MCP locaux tournent en dehors. Ensuite, des domaines larges comme github.com dans la liste autorisée peuvent ouvrir la voie à l’exfiltration de données. Pour tout isoler d’un coup, mieux vaut lancer l’agent entier dans un conteneur ou une machine virtuelle.

Dans Codex d’OpenAI, l’équivalent, ce sont les modes read-only, workspace-write et danger-full-access, avec le réseau coupé par défaut. L’option --yolo (alias de --dangerously-bypass-approvals-and-sandbox) désactive à la fois les validations et la sandbox : gardons-la pour les conteneurs.

Étape 3 : où stocker les clés API ?

La règle la plus simple : une clé ne va ni dans le code ni dans le dépôt. Anthropic recommande de ne pas écrire la clé directement dans le code ou les fichiers de configuration et d’ajouter les fichiers .env au .gitignore. OpenAI conseille de transmettre les clés par des variables d’environnement ou un gestionnaire de secrets, et de les renouveler régulièrement.

En pratique :

1. Des clés distinctes pour le développement, les tests et la production (c’est aussi une recommandation d’Anthropic). Une fuite ne fait alors pas tout tomber.
2. La clé de l’agent est une clé à part avec sa propre limite, pas notre clé principale.
3. Après une fuite, on révoque la clé immédiatement, et seulement ensuite on cherche la cause.

Fait intéressant, GitHub intercepte lui-même une partie des fuites. Si une clé Claude atterrit dans un dépôt public, GitHub prévient Anthropic, qui désactive la clé automatiquement.

Étape 4 : comment fixer des plafonds de dépenses ?

Un plafond n’empêche pas une fuite, mais il limite la facture quand une clé tombe entre de mauvaises mains.

1. Anthropic. Dans la Claude Console, on va sur la page Billing (platform.claude.com/settings/billing) et, dans la section Spend limits, on clique sur Adjust limit ou Set limit. On peut aussi fixer des limites par workspace, sauf pour celui par défaut.
2. OpenAI. Dans les paramètres du projet, on ouvre Limits, on fixe un Monthly spend limit et on active Enforce a hard limit. Attention : les alertes de dépenses (« Spend alerts do not enforce a cap ») ne bloquent rien, et le plafond lui-même s’applique avec un délai, si bien que les dépenses peuvent le dépasser légèrement.

Une bonne habitude : un projet (ou workspace) par agent, chacun avec sa propre clé et sa propre limite.

Étape 5 : comment repérer les secrets avant qu’ils ne fuient ?

Les agents écrivent beaucoup de code et commitent volontiers, d’où l’intérêt d’un garde-fou automatique qui arrête une clé avant le push.

1. La push protection de GitHub. Selon la documentation, elle bloque les pushs contenant des secrets avant qu’ils n’atteignent le dépôt. Pour les comptes utilisateurs, elle est activée par défaut sur les dépôts publics ; au niveau du dépôt, elle est désactivée par défaut et nécessite GitHub Secret Protection.
2. Gitleaks en local. On l’installe avec brew install gitleaks et on scanne un répertoire ou l’historique git (README) :

gitleaks dir -v .
gitleaks git -v .

3. TruffleHog vérifie en plus si le secret trouvé fonctionne encore (README). C’est avec cet outil que NorForge a confirmé qu’une partie des secrets des panneaux Cairn étaient actifs :

trufflehog filesystem path/to/dir

À quoi faire attention avec les serveurs MCP ?

Un serveur MCP, c’est du code qui tourne avec nos permissions. La documentation de Claude Code recommande d’écrire ses propres serveurs ou de n’utiliser que ceux de fournisseurs de confiance, et précise qu’Anthropic n’audite pas les serveurs MCP.

Les bonnes pratiques de sécurité MCP (version brouillon de la spécification) ajoutent quelques points concrets :

1. Le client doit afficher la commande complète qui lance un serveur local, sans la tronquer. L’exemple d’attaque de la spécification est un npx anodin derrière lequel se cache un curl qui envoie ~/.ssh/id_rsa vers un serveur tiers.
2. Les serveurs locaux tournent idéalement dans une sandbox aux permissions minimales et via le transport stdio.
3. Un serveur ne doit pas accepter de jetons qui n’ont pas été émis pour lui (le « token passthrough » est interdit).
4. Les permissions OAuth s’accordent progressivement, sans portées larges comme *, all ou full-access.

FAQ

Les règles deny de Claude Code suffisent-elles à protéger un fichier .env ?

Pas tout à fait. Elles bloquent les outils intégrés et les commandes reconnues comme cat, mais pas grep -r ni les sous-processus arbitraires. Seule la sandbox avec filesystem.denyRead offre une protection complète au niveau du système.

Que faire si une clé API a fuité ?

La révoquer immédiatement dans le tableau de bord du fournisseur, en générer une nouvelle, la remplacer dans toutes les applications et vérifier la consommation récente du compte. Plus de détails dans l’article sur la fuite chez OpenCode.

Qu’est-ce que l’injection de prompt dans les agents IA ?

Ce sont des instructions cachées dans les contenus que l’agent lit (pages web, fichiers, e-mails). L’agent peut les exécuter comme si elles venaient de nous. C’est pourquoi les actions risquées devraient exiger notre accord, et l’agent ne devrait pas avoir accès aux secrets.

La sandbox fonctionne-t-elle sous Windows ?

Dans Claude Code, uniquement via WSL2. Sous Windows natif, les commandes s’exécutent sans sandbox.