Webinar in ingleseWebinar con Jason Lee, mer 14 ottYour newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkIscriviti

La sicurezza dei tuoi agenti, in un solo comando.

Regole rispettate, azioni pericolose bloccate, codice corretto prima del commit e ogni agente visibile al tuo team.

npx -y @cybedefend/vibedefend@latest install

Prenota una demo5/5 su

Regione UE o USA, scelta all'installazione. Il guard decide sulla tua macchina.

Un comando. Cinque agenti. L'installer collega Claude Code, Cursor, Windsurf, GitHub Copilot e OpenAI Codex sulla macchina dello sviluppatore, in una volta.

8 volte meno regole violate.

Regole violate per ticket, stesso agente, stessi compiti.
  • Nessuno strumento2,28
  • Un file di regole tenuto a mano2,27
  • VibeDefend0,28

Studio controllato, 24 agosto 2026. Leggi lo studio
Un file di regole contro VibeDefend

  1. Le tue regole, servite prima di ogni modifica.

    Regole di business apprese dal tuo codice e regole di sicurezza per il tuo stack, scelte per il file che modifica.

    Claude Code sta scrivendobilling/refund.ts

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

    I rimborsi sopra i 500 € richiedono un secondo approvatore.

    Approvata una volta da Sofia M.

    Scritto con la tua regola, prima che la modifica entri.

  2. I comandi pericolosi non partono mai.

    Drop di schema, sudo, letture di segreti e push forzati vengono rifiutati; l'agente sa perché e prende un'altra strada.

    OpenAI Codex vuole eseguire

    rm -rf ./storage/uploads

    1. Letto
    2. Verificato con le tue protezioni
    3. Rifiutato
    4. Eseguito

    Bloccato: percorso protetto, file degli utenti

  3. Corretto prima del commit.

    Quando l'agente finisce, le modifiche vengono scansionate e corregge ogni problema. I problemi del progetto sono nella sua sessione.

    SQL injection raggiungibile

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

    Corretto dall'agente prima del commit

  4. Poi provato, non presunto.

    Dopo il commit, BLSA verifica la logica di business e dimostra ogni verdetto: la regola, il percorso, la riga.

    1. I rimborsi sopra i 500 € richiedono un secondo approvatore.

      BLSA, modalità prova

    2. POST /refunds

      Punto d'ingresso

    3. approvals.second(order)

      Il controllo della regola

    4. payments.refund(order)

      Eseguito dopo il controllo

    Regge: approvato prima di essere pagato

  5. Tutto ciò che fa, su un'unica mappa.

    Ogni regola servita, ogni rifiuto e ogni correzione, ricondotti al suo agente e al suo sviluppatore nel Brain.

    Cursor

    1. src/billing/cart-checkout.ts

      3 regole servite

    2. DROP TABLE invoices;

      Bloccata

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

      Problema corretto

    Ricondotto a Sofia M., nel Brain

Pensato per tutto il team.

Nessuno l'ha detto al tuo agente. Ora lo sa.

Un comando. Tutti i tuoi agenti. Nessuna carta di credito.

npx -y @cybedefend/vibedefend@latest install

Nel dettaglio

Poi provato, non presunto.

Dopo il commit, BLSA (Business Logic Security Analysis, sviluppato con il CNRS e il laboratorio CRIStAL) verifica la logica di business della modifica, e la sua modalità prova mostra perché ogni verdetto regge o cade: la regola, il percorso nel codice, la riga. Oggi BLSA è aperto ai nostri design partner.

Le otto falle di logica di business che evita
43%

delle vulnerabilità API sfruttano la logica di business, non una CVE nota.

Wallarm, API ThreatStats 2026

Fuga di dati tra tenantfiltro per tenant sulle queryCWE-639

Ricerca per id senza filtro tenant: qualsiasi cliente autenticato può leggere questo ordine.

prima

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

dopo

// 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);

Regola: filtro per tenant sulle query

Aggiramento dei rimborsitetto di autorizzazione sui rimborsiCWE-840

Rimborso creato senza controllo di ruolo né tetto: qualsiasi importo può essere rimborsato su qualsiasi intent.

prima

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

dopo

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 });
});

Regola: tetto di autorizzazione sui rimborsi

Idempotenza mancantechiave di idempotenza sui webhookCWE-837

Nessuna chiave di idempotenza: lo stesso evento Stripe, se ricevuto di nuovo, accredita l'ordine due volte.

prima

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

dopo

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');
});

Regola: chiave di idempotenza sui webhook

PII nei logpolicy PII nei logCWE-532

L'intero req.body finisce nei log: email e password in chiaro dal tuo provider di logging.

prima

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

dopo

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

Regola: policy PII nei log

Middleware di auth saltatomiddleware di auth obbligatorio sulle rotteCWE-306

Rotta montata senza il middleware di auth: /admin/users è raggiungibile senza sessione.

prima

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

dopo

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

Regola: middleware di auth obbligatorio sulle rotte

Rollout di feature flagdefault sicuri sui feature flagCWE-1188

Flag assente = true per default: l'export si attiva da solo in produzione.

prima

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

dopo

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

Regola: default sicuri sui feature flag

Rate limit assenterate limiting sul loginCWE-307

Nessun limite di tentativi su /login: i tentativi di brute force sulle credenziali sono illimitati.

prima

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

dopo

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

Regola: rate limiting sul login

Export su tutti i tenantfiltro per tenant sugli export adminCWE-285

findMany senza filtro per tenant: l'export CSV restituisce gli utenti di tutti i clienti.

prima

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

dopo

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);
});

Regola: filtro per tenant sugli export admin

Quattro livelli, un'installazione.

Regole servite

Le regole di business estratte dal tuo codice e le tue regole di sicurezza, servite prima di ogni modifica.

Claude Code sta scrivendosrc/billing/cart-checkout.ts

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

Gli importi usano Decimal128, mai Number.

Estratta da src/billing.ts:14

Ogni query che mescola input dell'utente va parametrizzata.

OWASP Top 10

Servite prima della modifica

Protezione dei segreti

Le letture dirette dei segreti sono rifiutate; l'agente riceve il riferimento gestito.

Cursorwebhooks.ts

  1. cat .env | grep STRIPE

    Bloccato: lettura diretta di un segreto

  2. Al suo postoprocess.env.STRIPE_WEBHOOK_SECRET

  3. npm test -- webhooks

    I test passano

Registrato per il team

Protezione delle azioni

Comandi distruttivi, drop di schema e percorsi protetti vengono bloccati prima dell'esecuzione.

OpenAI Codex

  1. rm -rf dist/

    Consentito: output della build

  2. rm -rf .cache/

    Consentito: cache

  3. rm -rf ./storage/uploads

    Bloccato: percorso protetto, file degli utenti

Registrato per il team

Finding in tempo reale

I finding di SAST, SCA, segreti, IaC e CI/CD, in diretta nella sessione perché l'agente li corregga.

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

Nel contesto dell'agente, in diretta

I tuoi framework, serviti come regole.

Le regole di sicurezza che l'agente riceve seguono i framework che controllano i tuoi auditor.

  • OWASP Top 10Injection, controllo degli accessi violato, segreti esposti.
  • SOC 2Controllo degli accessi, log di audit, gestione delle modifiche.
  • GDPRDati personali nei log, conservazione, minimizzazione.
  • ISO 27001Sviluppo sicuro e controllo degli accessi.

Framework a cui si rifanno le tue regole, non certificazioni di CybeDefend. La nostra postura

Provalo gratis sul tuo codice.

Senza carta. Per andare oltre, facciamo un pilota con il tuo team e fissiamo il prezzo con te.

Crea un account gratuitoCome si fissa il prezzo

Prima di installare.

Nello studio controllato di CybeDefend del 24 agosto 2026, lo stesso agente ha applicato il 89 % delle regole precise con VibeDefend, contro il 12 % senza strumenti e il 13 % con un file di regole tenuto a mano.

Leggi la documentazioneLo studio, su GitHub
Il mio codice esce dal mio computer?
Solo ciò che invii per l'analisi, e resta nella regione scelta all'installazione: Parigi per i clienti UE, su infrastruttura qualificata SecNumCloud, Iowa per i clienti USA, sempre sui nostri modelli self-hosted e mai tramite un'API AI di terzi. La protezione decide sul tuo computer, la sua telemetria contiene solo metadati (nessun contenuto dei prompt, nessun codice grezzo), i finding non passano mai da una regione all'altra e il tuo codice non viene mai usato per addestrare un modello.
Con quali agenti funziona?
L'installer configura Claude Code, Cursor, Windsurf, GitHub Copilot e Codex. Qualsiasi altro agente compatibile con MCP funziona con una configurazione manuale (bring-your-own-config), inclusi Gemini CLI, Cline, Continue.dev e Zed.
Cosa include il piano gratuito e cosa succede dopo?
Accedi e lancia il comando di installazione: le tue regole arrivano in Claude Code, Cursor, Windsurf, GitHub Copilot e Codex, e i guardrail funzionano in Claude Code, Cursor e Codex, senza carta. Per andare oltre, facciamo un progetto pilota con il tuo team, poi fissiamo con te un prezzo in base al tuo utilizzo.
È l'ennesimo scanner che inonda l'agente di avvisi?
No. Gli scanner classici girano sui commit e ti sommergono di falsi positivi. VibeDefend agisce in agent-time sul diff mentre viene scritto, con reachability e conoscenza del framework, e passa all'agente un solo finding su cui può intervenire, già con la correzione.
Posso leggere lo studio prima di registrarmi?
Sì, anzi, ti consigliamo di farlo. Il paper di 36 pagine, le 90 trascrizioni, gli audit alla cieca e i sei casi in cui il layer non ha funzionato sono nel repository pubblico indicato in questa pagina.
Cosa succede quando VibeDefend blocca un comando?
Il comando non viene mai eseguito. L'agente riceve il motivo nella sua sessione, così può prendere un'altra strada, e il rifiuto viene registrato per il team nel Brain.
Da dove vengono le regole che serve?
Da due fonti: le regole proposte a partire dal tuo codice, che una persona approva una volta, e i framework che scegli, come l'OWASP Top 10, SOC 2 o il GDPR, serviti come regole. Prima di ogni modifica, VibeDefend dà all'agente quelle che valgono per il file che sta cambiando.
Che cosa viene controllato prima del commit?
Le modifiche che l'agente ha appena fatto. Alla fine della sua risposta, VibeDefend le rivede e gli restituisce ogni finding con la sua correzione, così l'agente riscrive la riga prima del commit. I finding delle tue analisi SAST, SCA, secret, IaC e CI/CD sono anche nella sessione, in tempo reale.
Il team può vedere cosa ha fatto ogni agente?
Sì. Ogni regola servita, ogni rifiuto e ogni finding sono legati al loro agente e al loro sviluppatore nel Brain, la mappa dei tuoi agenti, così un responsabile o un team di sicurezza lo legge senza chiedere a nessuno.
Il mio agente controlla già il proprio codice. Perché aggiungere CybeDefend?
Ogni agente controlla il proprio lavoro, con le proprie impostazioni. CybeDefend dà ai cinque agenti le stesse regole, comprese le tue regole di business, servite prima della modifica invece che riviste dopo, e tiene un unico registro di ciò che ogni agente ha ricevuto, di ciò che è stato bloccato e di ciò che è stato corretto.