Pourquoi votre assistant IA pour coder est une faille de sécurité (et comment la corriger)

La semaine dernière, j'ai pris conscience que mon assistant IA exécutait des commandes librement sur mon ordi depuis des mois. Il touchait à mes clés AWS, SSH, dépôts GitHub privés, et tout ce qui traînait dans mon home. Le pire ? Je n'y avais jamais pensé. L'outil était pratique, et aucun drame n'était survenu.

C'est ce raisonnement qui rase des bases de données en prod.

La commodité cache un piège

La vérité fait mal : les agents IA pour coder ont souvent les mêmes droits qu'un ingénieur infra senior dès le premier jour. On ne donne pas un accès SSH total à un nouveau prestataire. Pourtant, on le fait sans sourciller avec un LLM.

Pas de méchanceté. Juste de la négligence. Ces outils sont trop utiles. On oublie leurs pouvoirs. Une injection de prompt dans un repo cloné, un objectif mal aligné, ou une commande anodine suffisent pour envoyer vos creds à un attaquant. Invisible.

Bonne nouvelle : des outils comme Claude Code intègrent des contrôles solides. Il suffit de les activer.

Les risques par défaut

Par défaut, beaucoup d'agents IA tournent en mode "auto". Ils exécutent sans demander, sauf blocage explicite. Efficace ? Voyons ce que ça donne :

Avec une deny list vide et auto activé, l'IA peut :

• Lancer curl vers n'importe quel serveur
• Télécharger via wget
• Se connecter en ssh
• Ouvrir des connexions avec nc
• Lire tous les .env
• Fouiller ~/.aws/credentials, ~/.ssh, ~/.gnupg
• Pusher du code en direct

Tout en silence. Pas d'alerte.

Un modèle de sécurité en trois couches

Il faut du contrôle fin. Pas tout valider, mais bloquer l'essentiel. Voici le plan :

Couche 1 : Le blocage dur

Déniez d'office les accès aux creds :

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

C'est votre pare-feu. Rien ne passe.

Couche 2 : Le point de validation

Demandez confirmation pour les actions risquées mais réversibles :

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

L'IA push, publie ou déploie ? Vous validez d'abord. Gain de temps sans risque fou.

Couche 3 : La voie rapide

Autorisez les ops safe :

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Ça roule sans vous déranger.

Choisir le mode par défaut

Après vos listes, définissez le mode pour le reste. Trois choix :

1. auto : Tout ce qui n'est pas bloqué s'exécute seul. Rapide, si votre deny est béton.

2. acceptEdits : Lecture et suggestions libres. Bash hors allow ? Demande. Équilibré.

3. ask : Validation pour tout risque. Lent, mais ultra-sécurisé.

acceptEdits convient à la plupart des équipes. Productivité + décisions conscientes.

Exemple de config pro

Voici une config prête pour la prod :

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

L'IA teste, linte, analyse votre code. Mais pas de vol de creds, pas de push sauvage, pas de connexions folles.

Deux approches selon le contexte

J'utilise deux alias shell :

# Par défaut : sécurité équilibrée
alias cc="claude --permission-mode auto"

# Mode debug : confiance totale (rarement)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc pour 95 % du boulot. ccd pour les crises, avec choix conscient.

Un problème général

Ça touche tous les outils IA qui touchent le shell : extensions Copilot, Devin, Cursor, ChatGPT avec exécution. Même dilemme : confort vs sécurité.

Claude Code se distingue par ses contrôles fins. Les autres ? Tout ou rien.

Impact sur votre infra

En équipe, c'est vital. Les devs ne penseront pas seuls à ça.

Pensez à :

• Imposer des deny lists partagées
• Bloquer les fichiers creds au niveau FS
• Utiliser des tokens temporaires
• Contrôler le réseau contre les fuites
• Former sur productivité vs tolérance au risque

Le mot de la fin

Les assistants IA pour coder sont puissants. À utiliser. Mais pas gratis. Les sécurités existent. Activez-les.

Prenez 15 minutes. Bloquez les creds. Validez les déploiements. Choisissez un mode malin. Puis bossez serein.

"Ça n'a jamais planté" n'est pas une stratégie de sécu.