La réalité du Vibe Coding : les agents d’IA et la crise de la dette de sécurité

le mois dernier, un réseau social entièrement géré par des agents IA a été l’expérience la plus fascinante sur Internet. Au cas où vous n’en auriez pas entendu parler, Moltbook est essentiellement une plateforme de réseau social pour les agents. Les robots publient, répondent et interagissent sans intervention humaine. Et pendant quelques jours, c’était tout ce dont tout le monde pouvait parler : des agents autonomes formant des sectes, divaguant contre les humains et construisant leur propre société.

Ensuite, la société de sécurité Wiz a publié un rapport montrant une fuite massive dans l’écosystème Moltbook. [1]. Une base de données Supabase mal configurée avait exposé 1,5 million de clés API et 35 000 adresses e-mail d’utilisateurs directement sur l’Internet public.

Comment est-ce arrivé ? La cause première n’était pas un hack sophistiqué. C’était du codage d’ambiance. Les développeurs ont construit cela grâce au codage d’ambiance et, dans le processus de création rapide et de raccourcis, ils ont manqué ces vulnérabilités ajoutées par les agents de codage.

C’est la réalité du vibe coding : Les agents de codage s’optimisent pour faire exécuter le code, et non pour le sécuriser.

Pourquoi les agents échouent

Dans mes recherches à l’Université de Columbia, nous avons évalué les meilleurs agents de codage et outils de codage d’ambiance. [2]. Nous avons trouvé des informations clés sur les endroits où ces agents échouent, soulignant la sécurité comme l’un des modèles d’échec les plus critiques.

1. La vitesse plutôt que la sécurité : Les LLM sont optimisés pour l’acceptation. Le moyen le plus simple d’amener un utilisateur à accepter un bloc de code est souvent de faire disparaître le message d’erreur. Malheureusement, la contrainte à l’origine de l’erreur est parfois un garde-fou.

Dans la pratique, nous avons observé des agents supprimant les contrôles de validation, assouplissant les politiques de base de données ou désactivant les flux d’authentification simplement pour résoudre les erreurs d’exécution.

2. L’IA ignore les effets secondaires : L’IA ignore souvent le contexte complet de la base de code, en particulier lorsqu’elle travaille avec de grandes architectures complexes. Nous l’avons constamment constaté avec le refactoring, où un agent corrige un bug dans un fichier mais provoque des modifications brutales ou des fuites de sécurité dans les fichiers le référençant, simplement parce qu’il n’a pas vu la connexion.

3. Correspondance de modèles, pas de jugement : Les LLM ne comprennent pas réellement la sémantique ou les implications du code qu’ils écrivent. Ils prédisent simplement les jetons qui, selon eux, viendront ensuite, sur la base de leurs données de formation. Ils ne savent pas pourquoi un contrôle de sécurité existe, ni que le supprimer crée un risque. Ils savent simplement que cela correspond au modèle de syntaxe qui corrige le bogue. Pour une IA, un mur de sécurité n’est qu’un bug empêchant l’exécution du code.

Ces modèles d’échec ne sont pas théoriques : ils apparaissent constamment dans le développement quotidien. Voici quelques exemples simples que j’ai personnellement rencontrés au cours de mes recherches.

3 bugs de sécurité du codage Vibe que j’ai vus récemment

1. Fuite de clés API

Vous devez appeler une API externe (comme OpenAI) depuis une interface React. Pour résoudre ce problème, l’agent place simplement la clé API en haut de votre fichier.

// What the agent writes
const response = await fetch('https://api.openai.com/v1/...', {
  headers: {
    'Authorization': 'Bearer sk-proj-12345...' // <--- EXPOSED
  }
});

Cela rend la clé visible à tout le monde, puisqu’avec JS, vous pouvez faire « Inspecter l’élément » et afficher le code.

2. Accès public aux bases de données

Cela arrive constamment avec Supabase ou Firebase. Le problème est que j’obtenais une erreur « Autorisation refusée » lors de la récupération des données. L’IA a suggéré une politique d’UTILISATION (vrai) ou d’accès public.

-- What the agent writes
CREATE POLICY "Allow public access" ON users FOR SELECT USING (true);

Cela corrige l’erreur en exécutant le code. Mais cela a simplement rendu l’intégralité de la base de données publique sur Internet.

3. Vulnérabilités XSS

Nous avons testé si nous pouvions restituer du contenu HTML brut dans un composant React. L’agent a immédiatement ajouté la modification du code pour utiliser dangereusementSetInnerHTML pour restituer le code HTML brut.

// What the agent writes
<div dangerouslySetInnerHTML={{ __html: aiResponse }} />

L’IA suggère rarement une bibliothèque de désinfectants (comme dompurify). Cela vous donne juste l’accessoire brut. Il s’agit d’un problème car cela laisse votre application grande ouverte aux attaques XSS (Cross-Site Scripting) où des scripts malveillants peuvent s’exécuter sur les appareils de vos utilisateurs.

Ensemble, ce ne sont pas seulement des histoires d’horreur ponctuelles. Ils correspondent à ce que nous observons dans des données plus larges sur les changements générés par l’IA :

Comment Vibe Coder correctement

Nous ne devrions pas cesser d’utiliser ces outils, mais nous devons changer la façon dont nous les utilisons.

1. De meilleures invites

Nous ne pouvons pas simplement demander à l’agent de « sécuriser cela ». Cela ne fonctionnera pas car « sécurisé » est trop vague pour un LLM. Nous devrions plutôt utiliser un développement basé sur les spécifications, où nous pouvons avoir des politiques de sécurité et des exigences prédéfinies que l’agent doit satisfaire avant d’écrire du code. Cela peut inclure, sans s’y limiter : aucun accès à la base de données publique, l’écriture de tests unitaires pour chaque fonctionnalité ajoutée, la vérification des entrées utilisateur et aucune clé API codée en dur. Un bon point de départ consiste à ancrer ces politiques dans le Top 10 de l’OWASP, la liste standard du secteur des risques de sécurité Web les plus critiques.

Au-delà de cela, les recherches montrent que les invites de chaîne de pensée, demandant spécifiquement à l’agent de raisonner sur les implications de sécurité avant d’écrire du code, réduisent considérablement les sorties non sécurisées. Au lieu de simplement demander une solution, nous pouvons demander : « Quels sont les risques de sécurité de cette approche et comment allez-vous les éviter ?

2. De meilleures critiques

Lors du codage d’ambiance, il est vraiment tentant de simplement visualiser l’interface utilisateur (et de ne pas regarder le code), et honnêtement, c’est toute la promesse du codage d’ambiance. Mais actuellement, nous n’en sommes pas encore là. Andrej Karpathy — le chercheur en IA qui a inventé le terme « vibe coding » — a récemment averti que si nous n’y prenons pas garde, les agents peuvent simplement générer du slop. Il a souligné qu’à mesure que nous nous appuyons davantage sur l’IA, notre tâche principale passe de l’écriture du code à sa révision. C’est similaire à la façon dont nous travaillons avec les stagiaires : nous ne laissons pas les stagiaires pousser le code en production sans examens appropriés, et c’est exactement ce que nous devrions faire avec les agents. Affichez correctement les différences, vérifiez les tests unitaires et assurez une bonne qualité de code.

3. Garde-corps automatisés

Étant donné que le codage vibratoire encourage à aller vite, nous ne pouvons pas garantir que les humains seront capables de tout capter. Nous devrions automatiser les contrôles de sécurité que les agents doivent effectuer au préalable. Nous pouvons ajouter des conditions de pré-commit et des scanners de pipeline CI/CD qui analysent et bloquent les commits contenant des secrets codés en dur ou des modèles dangereux détectés. Des outils tels que GitGuardian ou TruffleHog permettent d’analyser automatiquement les secrets exposés avant la fusion du code. Des travaux récents sur les agents augmentés par des outils et les systèmes de vérification « LLM-in-the-loop » montrent que les modèles se comportent de manière beaucoup plus fiable et sûre lorsqu’ils sont associés à des vérificateurs déterministes. Le modèle génère du code, les outils le valident et toute modification de code non sécurisée est automatiquement rejetée.

Conclusion

Les agents de codage nous permettent de construire plus rapidement que jamais. Ils améliorent l’accessibilité, permettant aux personnes de tous horizons en programmation de créer tout ce qu’elles envisagent. Mais cela ne doit pas se faire au détriment de la sécurité et de la sûreté. En tirant parti de techniques d’ingénierie rapides, en examinant minutieusement les différences de code et en fournissant des garde-fous clairs, nous pouvons utiliser les agents d’IA en toute sécurité et créer de meilleures applications.

Références

1. https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
2. https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html
3. https://vibefactory.ai/api-key-security-scanner
4. https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/
5. https://www.csoonline.com/article/4062720/ai-coding-assistants-amplify-deeper-cybersecurity-risks.html