Webinar en anglaisWebinar avec Jason Lee, mer. 14 oct.Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkS'inscrire

La sécurité de vos agents de code, en une commande.

Règles suivies, actions dangereuses bloquées, code corrigé avant le commit, et chaque agent visible par votre équipe.

npx -y @cybedefend/vibedefend@latest install

Région UE ou États-Unis, choisie à l'installation. Le garde-fou décide sur votre machine.

Une commande. Cinq agents. L'installeur branche Claude Code, Cursor, Windsurf, GitHub Copilot et OpenAI Codex sur le poste du développeur, en une seule fois, sans rien configurer agent par agent.

8 fois moins de règles enfreintes.

Règles enfreintes par ticket, même agent, mêmes tâches.
  • Sans outil2,28
  • Un fichier de règles tenu à la main2,27
  • VibeDefend0,28

Étude contrôlée, 24 août 2026. Lire l'étude
Un fichier de règles face à VibeDefend

  1. Vos règles, servies avant chaque modification.

    Les règles métier apprises dans votre code et les règles de sécurité de votre stack, choisies pour le fichier modifié.

    Claude Code écritbilling/refund.ts

    async function refund(order, amount) {
      if (amount > 500)
        await approvals.second(order);
      await payments.refund(order, amount);
      return receipt(order);
    }
    

    Un remboursement de plus de 500 € demande un second validateur.

    Approuvée une fois par Sofia M.

    Écrit avec votre règle, avant que la modification ne s'applique.

  2. Les commandes dangereuses ne s'exécutent jamais.

    Suppressions de schéma, sudo, lectures de secrets, push forcés : refusés. L'agent sait pourquoi et prend un autre chemin.

    OpenAI Codex veut exécuter

    rm -rf ./storage/uploads

    1. Lu
    2. Vérifié contre vos garde-fous
    3. Refusé
    4. Exécuté

    Bloqué : chemin protégé, fichiers des utilisateurs

  3. Corrigé avant le commit.

    Quand l'agent termine, ses modifications sont scannées et il corrige chaque faille. Les failles du projet sont dans sa session.

    Injection SQL atteignable

    CWE-89, src/db/users.repo.ts:42
    "SELECT * FROM users WHERE id = $1", [id]

    Corrigée par l'agent avant le commit

  4. Puis prouvé, pas supposé.

    Après le commit, BLSA vérifie sa logique métier et prouve chaque verdict : la règle, le chemin, la ligne.

    1. Un remboursement de plus de 500 € demande un second validateur.

      BLSA, mode preuve

    2. POST /refunds

      Point d'entrée

    3. approvals.second(order)

      Le contrôle de la règle

    4. payments.refund(order)

      S'exécute après le contrôle

    Tient : approuvé avant d'être payé

  5. Tout ce qu'il fait, sur une seule carte.

    Chaque règle servie, chaque refus et chaque correction, rattachés à leur agent et à leur développeur dans le Brain.

    Cursor

    1. src/billing/cart-checkout.ts

      3 règles servies

    2. DROP TABLE invoices;

      Bloquée

    3. CWE-89, src/db/users.repo.ts:42

      Faille corrigée

    Rattaché à Sofia M., dans le Brain

Personne n'a prévenu votre agent. Désormais, il sait.

Une commande. Tous vos agents. Sans carte bancaire.

npx -y @cybedefend/vibedefend@latest install

En détail

Puis prouvé, pas supposé.

Après le commit, BLSA (Business Logic Security Analysis, construit avec le CNRS et le laboratoire CRIStAL) vérifie la logique métier du changement, et son mode preuve montre pourquoi chaque verdict tient ou casse : la règle, le chemin dans le code, la ligne. BLSA est ouvert aujourd'hui à nos design partners.

Les huit failles de logique métier qu'il évite
43 %

des vulnérabilités d'API exploitent la logique métier, pas une CVE connue.

Wallarm, API ThreatStats 2026

Fuite multi-tenantcloisonnement par tenant des requêtesCWE-639

Recherche par id sans filtre tenant : n'importe quel client connecté peut lire cette commande.

avant

// GET /api/orders/:id
const order = await db.order.findUnique({
  where: { id: req.params.id },
});
return res.json(order);

après

// GET /api/orders/:id
const order = await db.order.findUnique({
  where: { id: req.params.id, tenantId: req.user.tenantId },
});
if (!order) return res.status(404).end();
return res.json(order);

Règle : cloisonnement par tenant des requêtes

Contournement de remboursementplafond d'autorisation sur les remboursementsCWE-840

Remboursement créé sans contrôle de rôle ni plafond : n'importe quel montant part, sur n'importe quel PaymentIntent.

avant

router.post('/refund', async (req, res) => {
  await stripe.refunds.create({
    payment_intent: req.body.intent,
    amount: req.body.amount,
  });
  return res.json({ ok: true });
});

après

router.post('/refund', requireRole('finance'), async (req, res) => {
  const intent = await getOwnedIntent(req.user, req.body.intent);
  const amount = clampRefund(intent, req.body.amount);
  await stripe.refunds.create({ payment_intent: intent.id, amount });
  return res.json({ ok: true });
});

Règle : plafond d'autorisation sur les remboursements

Idempotence absenteclé d'idempotence sur les webhooksCWE-837

Aucune clé d'idempotence : le même événement Stripe rejoué crédite la commande deux fois.

avant

app.post('/webhook/stripe', async (req, res) => {
  await orders.markPaid(req.body.id);
  await ledger.append({ type: 'charge', ... });
  res.send('ok');
});

après

app.post('/webhook/stripe', async (req, res) => {
  const key = req.headers['idempotency-key'];
  if (await seen.has(key)) return res.send('dup');
  await orders.markPaid(req.body.id);
  await ledger.append({ type: 'charge', key, ... });
  await seen.add(key, '24h');
  res.send('ok');
});

Règle : clé d'idempotence sur les webhooks

Données personnelles dans les logspolitique de données personnelles dans les logsCWE-532

req.body part entier dans les logs : e-mail et mot de passe en clair chez votre fournisseur de logs.

avant

logger.info('signup', { user: req.body });

après

logger.info('signup', {
  userId: hash(req.body.email),
  region: req.body.region,
});

Règle : politique de données personnelles dans les logs

Middleware d'auth contournémiddleware d'auth obligatoire sur les routesCWE-306

Route montée sans middleware d'auth : /admin/users est accessible sans session.

avant

// public.routes.ts
router.get('/admin/users', listAllUsers);

après

// admin.routes.ts (auth + rbac applied at mount)
router.use(requireSession, requireRole('admin'));
router.get('/users', listAllUsers);

Règle : middleware d'auth obligatoire sur les routes

Déploiement de feature flagvaleurs par défaut sûres des feature flagsCWE-1188

Flag absent = true par défaut : l'export s'active tout seul en production.

avant

if (flags.allow_anyone_to_export ?? true) {
  return exportAll();
}

après

if (flags.allow_anyone_to_export === true && req.user.role === 'admin') {
  audit.log('export.all', req.user);
  return exportAll();
}

Règle : valeurs par défaut sûres des feature flags

Pas de rate limitingrate limiting sur le loginCWE-307

Aucune limite d'essais sur /login : la force brute sur les identifiants est illimitée.

avant

router.post('/login', loginHandler);

après

router.post('/login',
  rateLimit({ windowMs: 60_000, max: 8, keyGenerator: ipAndEmail }),
  loginHandler);

Règle : rate limiting sur le login

Export de tous les tenantscloisonnement par tenant des exports adminCWE-285

findMany sans filtre tenant : l'export CSV renvoie les utilisateurs de tous les clients.

avant

router.get('/admin/export', requireAdmin, async (_req, res) => {
  const rows = await db.user.findMany({});
  res.csv(rows);
});

après

router.get('/admin/export', requireAdmin, async (req, res) => {
  const rows = await db.user.findMany({
    where: { tenantId: req.user.tenantId },
  });
  audit.log('export', req.user);
  res.csv(rows);
});

Règle : cloisonnement par tenant des exports admin

Quatre couches, une seule installation.

Règles servies

Les règles métier extraites de votre code et vos règles de sécurité, servies avant chaque modification.

Claude Code écritsrc/billing/cart-checkout.ts

const total = new Decimal128(cart.sum);
const rows = await db.query(
  "SELECT * FROM carts WHERE id = $1", [id]
);

Les montants utilisent Decimal128, jamais Number.

Tirée de src/billing.ts:14

Toute requête qui mêle une saisie utilisateur est paramétrée.

OWASP Top 10

Servies avant la modification

Garde-fou des secrets

Les lectures brutes de secrets sont refusées ; l'agent reçoit la référence gérée à la place.

Cursorwebhooks.ts

  1. cat .env | grep STRIPE

    Bloqué : lecture brute d'un secret

  2. À la placeprocess.env.STRIPE_WEBHOOK_SECRET

  3. npm test -- webhooks

    Les tests passent

Consigné pour l'équipe

Garde-fou des actions

Commandes destructrices, suppressions de schéma, chemins protégés : arrêtés avant de s'exécuter.

OpenAI Codex

  1. rm -rf dist/

    Autorisé : sortie de build

  2. rm -rf .cache/

    Autorisé : cache

  3. rm -rf ./storage/uploads

    Bloqué : chemin protégé, fichiers des utilisateurs

Consigné pour l'équipe

Alertes en direct

Les alertes SAST, SCA, secrets, IaC et CI/CD, en direct dans la session, pour que l'agent les corrige.

GitHub Copilot

  1. SASTsrc/db/users.repo.ts:42

    SQL injection

  2. SCApackage.json

    lodash 4.17.20, CVE-2021-23337

  3. Secretsconfig/prod.yml

    AWS access key

  4. IaCinfra/main.tf

    S3 bucket public-read

  5. CI/CD.github/workflows/deploy.yml

    pull_request_target

Dans le contexte de l'agent, en direct

Vos référentiels, servis sous forme de règles.

Les règles de sécurité que reçoit l'agent suivent les référentiels que vos auditeurs vérifient.

  • OWASP Top 10Injections, contrôle d'accès défaillant, secrets exposés.
  • SOC 2Contrôle d'accès, journalisation, gestion des changements.
  • RGPDDonnées personnelles dans les logs, durée de conservation, minimisation.
  • ISO 27001Développement sécurisé et contrôle d'accès.

Des référentiels auxquels vos règles se rattachent, pas des certifications de CybeDefend. Notre propre posture

Essayez-le gratuitement sur votre code.

Sans carte bancaire. Pour aller plus loin, nous menons un pilote avec votre équipe et fixons le prix avec vous.

Avant d'installer.

Dans l'étude contrôlée de CybeDefend du 24 août 2026, le même agent a appliqué 89 % des règles précises avec VibeDefend, contre 12 % sans outil et 13 % avec un fichier de règles tenu à la main.

Mon code quitte-t-il ma machine ?
Ce que vous envoyez à l'analyse, oui, et il reste dans la région choisie à l'installation : Paris pour les clients européens sur une infrastructure qualifiée SecNumCloud, l'Iowa pour les clients américains, sur nos propres modèles auto-hébergés, jamais une API d'IA tierce. Le garde-fou décide sur votre machine, sa télémétrie ne transporte que des métadonnées (ni prompt, ni code brut), les résultats ne changent jamais de région, et votre code ne sert jamais à entraîner un modèle.
Avec quels agents ça fonctionne ?
L'installeur configure Claude Code, Cursor, Windsurf, GitHub Copilot et Codex. Tout autre agent compatible MCP fonctionne avec votre propre configuration, dont Gemini CLI, Cline, Continue.dev et Zed.
Que comprend le plan gratuit, et que se passe-t-il ensuite ?
Connectez-vous et lancez la commande d'installation : vos règles arrivent dans Claude Code, Cursor, Windsurf, GitHub Copilot et Codex, et les garde-fous tournent dans Claude Code, Cursor et Codex, sans carte bancaire. Pour aller plus loin, nous menons un pilote avec votre équipe, puis fixons un prix avec vous, selon votre usage.
Encore un scanner qui inonde l'agent d'alertes ?
Non. Les scanners classiques tournent sur les commits et vous noient sous les faux positifs. VibeDefend intervient en agent-time, sur le diff en cours d'écriture, en tenant compte de la reachability et du framework, et remet à l'agent une alerte qu'il peut traiter, avec le correctif.
Puis-je lire l'étude avant de m'inscrire ?
Oui, et nous vous y encourageons. L'article de 36 pages, les 90 transcriptions, les audits à l'aveugle et les six cas où la couche n'a pas fait la différence sont dans le dépôt public lié sur cette page.
Que se passe-t-il quand VibeDefend bloque une commande ?
La commande ne s'exécute jamais. L'agent reçoit la raison dans sa session, pour prendre un autre chemin, et le refus est consigné pour l'équipe dans le Brain.
D'où viennent les règles qu'il sert ?
De deux sources : les règles proposées à partir de votre propre code, qu'une personne valide une fois, et les référentiels que vous choisissez, comme l'OWASP Top 10, SOC 2 ou le RGPD, servis sous forme de règles. Avant chaque modification, VibeDefend donne à l'agent celles qui s'appliquent au fichier qu'il modifie.
Qu'est-ce qui est vérifié avant le commit ?
Les changements que l'agent vient de faire. À la fin de sa réponse, VibeDefend les relit et lui renvoie chaque alerte avec son correctif, pour qu'il réécrive la ligne avant le commit. Les alertes de vos analyses SAST, SCA, secrets, IaC et CI/CD sont aussi dans la session, en direct.
L'équipe peut-elle voir ce que chaque agent a fait ?
Oui. Chaque règle servie, chaque refus et chaque alerte sont rattachés à leur agent et à leur développeur dans le Brain, la carte de vos agents : un responsable ou une équipe sécurité les lit sans rien demander à personne.
Mon agent vérifie déjà son propre code. Pourquoi CybeDefend ?
Chaque agent vérifie son propre travail, avec ses propres réglages. CybeDefend donne aux cinq agents les mêmes règles, vos règles métier comprises, servies avant la modification plutôt que relues après, et garde une seule trace de ce que chaque agent a reçu, de ce qui a été bloqué et de ce qui a été corrigé.