Webinar en inglésWebinar con Jason Lee, mié, 14 octYour newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkInscríbete

La seguridad de tus agentes, en un solo comando.

Reglas cumplidas, acciones peligrosas bloqueadas, código corregido antes del commit y cada agente visible para tu equipo.

npx -y @cybedefend/vibedefend@latest install

Reserva una demo5/5 en

Región UE o EE. UU., elegida al instalar. El guard decide en tu máquina.

Un comando. Cinco agentes. El instalador conecta Claude Code, Cursor, Windsurf, GitHub Copilot y OpenAI Codex en el equipo del desarrollador, de una vez.

8 veces menos reglas incumplidas.

Reglas incumplidas por ticket, mismo agente, mismas tareas.
  • Sin herramienta2,28
  • Un archivo de reglas mantenido a mano2,27
  • VibeDefend0,28

Estudio controlado, 24 de agosto de 2026. Leer el estudio
Un archivo de reglas frente a VibeDefend

  1. Tus reglas, servidas antes de cada edición.

    Reglas de negocio aprendidas de tu código y reglas de seguridad para tu stack, elegidas para el archivo que edita.

    Claude Code está escribiendobilling/refund.ts

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

    Los reembolsos de más de 500 € necesitan un segundo aprobador.

    Aprobada una vez por Sofia M.

    Escrito con tu regla, antes de que se aplique el cambio.

  2. Los comandos peligrosos nunca se ejecutan.

    Borrados de esquema, sudo, lecturas de secretos y push forzados se rechazan; el agente sabe por qué y busca otro camino.

    OpenAI Codex quiere ejecutar

    rm -rf ./storage/uploads

    1. Leído
    2. Comprobado con tus salvaguardas
    3. Rechazado
    4. Ejecutado

    Bloqueado: ruta protegida, archivos de los usuarios

  3. Corregido antes del commit.

    Cuando el agente termina, sus cambios se escanean y corrige cada hallazgo. Los hallazgos de tu proyecto están en su sesión.

    Inyección SQL alcanzable

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

    Corregido por el agente antes del commit

  4. Después, probado, no supuesto.

    Tras el commit, BLSA comprueba su lógica de negocio y demuestra cada veredicto: la regla, el camino, la línea.

    1. Los reembolsos de más de 500 € necesitan un segundo aprobador.

      BLSA, modo prueba

    2. POST /refunds

      Punto de entrada

    3. approvals.second(order)

      El control de la regla

    4. payments.refund(order)

      Se ejecuta tras el control

    Se cumple: aprobado antes de pagarse

  5. Todo lo que hace, en un solo mapa.

    Cada regla servida, cada rechazo y cada corrección, vinculados a su agente y a su desarrollador en el Brain.

    Cursor

    1. src/billing/cart-checkout.ts

      3 reglas servidas

    2. DROP TABLE invoices;

      Bloqueada

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

      Hallazgo corregido

    Vinculado a Sofia M., en el Brain

Pensado para todo el equipo.

Nadie avisó a tu agente. Ahora lo sabe.

Un comando. Todos tus agentes. Sin tarjeta.

npx -y @cybedefend/vibedefend@latest install

En detalle

Después, probado, no supuesto.

Tras el commit, BLSA (Business Logic Security Analysis, desarrollado con el CNRS y el laboratorio CRIStAL) comprueba la lógica de negocio del cambio, y su modo prueba muestra por qué cada veredicto se cumple o falla: la regla, el camino en el código, la línea. Hoy BLSA está abierto a nuestros design partners.

Los ocho fallos de lógica de negocio que evita
43 %

de las vulnerabilidades de API explotan la lógica de negocio, no una CVE conocida.

Wallarm, API ThreatStats 2026

Fuga multi-tenanttenant scoping en las consultasCWE-639

Consulta por id sin filtro de tenant: cualquier cliente autenticado puede leer este pedido.

antes

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

despué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);

Regla: tenant scoping en las consultas

Reembolso sin controltecho de autorización en los reembolsosCWE-840

Reembolso creado sin comprobar rol ni techo: sale cualquier importe hacia cualquier intent.

antes

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

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

Regla: techo de autorización en los reembolsos

Idempotencia ausenteclave de idempotencia en los webhooksCWE-837

Sin clave de idempotencia: el mismo evento de Stripe reenviado abona el pedido dos veces.

antes

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

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

Regla: clave de idempotencia en los webhooks

PII en los logspolítica de PII en los logsCWE-532

El req.body entero va a los logs: email y contraseña en claro en tu proveedor de logs.

antes

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

después

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

Regla: política de PII en los logs

Middleware de auth omitidomiddleware de auth obligatorio en las rutasCWE-306

Ruta montada sin el middleware de auth: se llega a /admin/users sin sesión.

antes

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

después

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

Regla: middleware de auth obligatorio en las rutas

Despliegue de feature flagvalores por defecto seguros en los feature flagsCWE-1188

Flag ausente = true por defecto: la exportación se activa sola en producción.

antes

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

después

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

Regla: valores por defecto seguros en los feature flags

Sin rate limitrate limiting en el loginCWE-307

Sin límite de intentos en /login: fuerza bruta sin freno.

antes

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

después

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

Regla: rate limiting en el login

Exportación entre tenantstenant scoping en las exportaciones adminCWE-285

findMany sin filtro de tenant: el CSV devuelve los usuarios de todos los clientes.

antes

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

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

Regla: tenant scoping en las exportaciones admin

Cuatro capas, una instalación.

Reglas servidas

Las reglas de negocio extraídas de tu código y tus reglas de seguridad, servidas antes de cada edición.

Claude Code está escribiendosrc/billing/cart-checkout.ts

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

Los importes usan Decimal128, nunca Number.

Extraída de src/billing.ts:14

Toda consulta que mezcla datos del usuario va parametrizada.

OWASP Top 10

Servidas antes de la edición

Protección de secretos

Las lecturas directas de secretos se rechazan; el agente recibe la referencia gestionada.

Cursorwebhooks.ts

  1. cat .env | grep STRIPE

    Bloqueado: lectura directa de un secreto

  2. En su lugarprocess.env.STRIPE_WEBHOOK_SECRET

  3. npm test -- webhooks

    Los tests pasan

Registrado para el equipo

Control de acciones

Comandos destructivos, borrados de esquema y rutas protegidas se detienen antes de ejecutarse.

OpenAI Codex

  1. rm -rf dist/

    Permitido: salida del build

  2. rm -rf .cache/

    Permitido: caché

  3. rm -rf ./storage/uploads

    Bloqueado: ruta protegida, archivos de los usuarios

Registrado para el equipo

Hallazgos en vivo

Los hallazgos de SAST, SCA, secretos, IaC y CI/CD, en vivo en la sesión para que el agente los corrija.

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

En el contexto del agente, en vivo

Tus marcos de cumplimiento, servidos como reglas.

Las reglas de seguridad que recibe el agente siguen los marcos que revisan tus auditores.

  • OWASP Top 10Inyección, control de acceso roto, secretos expuestos.
  • SOC 2Control de acceso, registro de auditoría, gestión de cambios.
  • RGPDDatos personales en los logs, conservación, minimización.
  • ISO 27001Desarrollo seguro y control de acceso.

Marcos a los que se ajustan tus reglas, no certificaciones de CybeDefend. Nuestra propia postura

Pruébalo gratis en tu propio código.

Sin tarjeta. Para ir más allá, hacemos un piloto con tu equipo y fijamos el precio contigo.

Crear una cuenta gratisCómo se fija el precio

Antes de instalar.

En el estudio controlado de CybeDefend del 24 de agosto de 2026, el mismo agente aplicó el 89 % de las reglas precisas con VibeDefend, frente al 12 % sin herramienta y el 13 % con un archivo de reglas mantenido a mano.

Leer la documentaciónEl estudio, en GitHub
¿Mi código sale de mi máquina?
Lo que envías a analizar sí sale, pero se queda en la región que elegiste al instalar: París para los clientes de la UE, sobre infraestructura cualificada SecNumCloud, e Iowa para los de EE. UU. Siempre en nuestros propios modelos autoalojados, nunca en una API de IA de terceros. El guardián decide en tu máquina, su telemetría solo lleva metadatos (ni contenido de prompts ni código en bruto), los hallazgos nunca cambian de región y tu código nunca se usa para entrenar un modelo.
¿Con qué agentes funciona?
El instalador conecta Claude Code, Cursor, Windsurf, GitHub Copilot y Codex. Cualquier otro agente compatible con MCP funciona con tu propia configuración, entre ellos Gemini CLI, Cline, Continue.dev y Zed.
¿Qué incluye el plan gratuito y qué pasa después?
Inicia sesión y lanza el comando de instalación: tus reglas llegan a Claude Code, Cursor, Windsurf, GitHub Copilot y Codex, y los guardrails funcionan en Claude Code, Cursor y Codex, sin tarjeta. Para ir más allá, hacemos un piloto con tu equipo y luego fijamos un precio contigo, según tu uso.
¿Es otro escáner que inunda al agente de alertas?
No. Los escáneres tradicionales se ejecutan en cada commit y te ahogan en falsos positivos. VibeDefend actúa en agent-time, sobre el diff que se está escribiendo, con reachability y conocimiento del framework, y le da al agente un único hallazgo sobre el que actuar, con su corrección.
¿Puedo leer el estudio antes de registrarme?
Sí, y te lo recomendamos. El informe de 36 páginas, las 90 transcripciones, las auditorías a ciegas y los seis casos en los que la capa no dio resultado están en el repositorio público enlazado en esta página.
¿Qué pasa cuando VibeDefend bloquea un comando?
El comando nunca se ejecuta. El agente recibe el motivo en su sesión, para tomar otro camino, y el rechazo queda registrado para el equipo en el Brain.
¿De dónde salen las reglas que sirve?
De dos fuentes: las reglas propuestas a partir de tu propio código, que una persona aprueba una vez, y los marcos que eliges, como el OWASP Top 10, SOC 2 o el RGPD, servidos como reglas. Antes de cada edición, VibeDefend da al agente las que se aplican al archivo que está cambiando.
¿Qué se verifica antes del commit?
Los cambios que el agente acaba de hacer. Al final de su respuesta, VibeDefend los revisa y le devuelve cada hallazgo con su corrección, para que reescriba la línea antes del commit. Los hallazgos de tus análisis SAST, SCA, secretos, IaC y CI/CD también están en la sesión, en directo.
¿Puede el equipo ver lo que hizo cada agente?
Sí. Cada regla servida, cada rechazo y cada hallazgo quedan ligados a su agente y a su desarrollador en el Brain, el mapa de tus agentes, para que un líder o un equipo de seguridad lo lea sin preguntar a nadie.
Mi agente ya revisa su propio código. ¿Por qué añadir CybeDefend?
Cada agente revisa su propio trabajo, con su propia configuración. CybeDefend da a los cinco agentes las mismas reglas, incluidas tus reglas de negocio, servidas antes de la edición en lugar de revisadas después, y guarda un único registro de lo que recibió cada agente, lo que se bloqueó y lo que se corrigió.