Webinar em inglêsWebinar com Jason Lee, quarta, 14/10Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkInscreva-se

A segurança dos teus agentes, num só comando.

Regras cumpridas, ações perigosas bloqueadas, código corrigido antes do commit e cada agente visível para a tua equipa.

npx -y @cybedefend/vibedefend@latest install

Marcar uma demo5/5 no

Região UE ou EUA, escolhida na instalação. O guard decide na tua máquina.

Um comando. Cinco agentes. O instalador liga o Claude Code, o Cursor, o Windsurf, o GitHub Copilot e o OpenAI Codex no computador do programador, de uma vez.

8 vezes menos regras violadas.

Regras violadas por ticket, o mesmo agente, as mesmas tarefas.
  • Sem ferramenta2,28
  • Um ficheiro de regras mantido à mão2,27
  • VibeDefend0,28

Estudo controlado, 24 de agosto de 2026. Ler o estudo
Um ficheiro de regras face ao VibeDefend

  1. As tuas regras, servidas antes de cada edição.

    Regras de negócio aprendidas no teu código e regras de segurança para a tua stack, escolhidas para o ficheiro editado.

    Claude Code está a escreverbilling/refund.ts

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

    Reembolsos acima de 500 € precisam de um segundo aprovador.

    Aprovada uma vez por Sofia M.

    Escrito com a tua regra, antes de a alteração entrar.

  2. Os comandos perigosos nunca correm.

    Remoções de esquema, sudo, leituras de segredos e push forçados são recusados; o agente sabe porquê e segue outro caminho.

    OpenAI Codex quer executar

    rm -rf ./storage/uploads

    1. Lido
    2. Verificado contra as tuas salvaguardas
    3. Recusado
    4. Executado

    Bloqueado: caminho protegido, ficheiros dos utilizadores

  3. Corrigido antes do commit.

    Quando o agente termina, as alterações são analisadas e ele corrige cada falha. As falhas do projeto estão na sua sessão.

    Injeção SQL alcançável

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

    Corrigida pelo agente antes do commit

  4. Depois, provado, não suposto.

    Depois do commit, o BLSA verifica a lógica de negócio e prova cada veredicto: a regra, o caminho, a linha.

    1. Reembolsos acima de 500 € precisam de um segundo aprovador.

      BLSA, modo prova

    2. POST /refunds

      Ponto de entrada

    3. approvals.second(order)

      O controlo da regra

    4. payments.refund(order)

      Corre depois do controlo

    Cumpre-se: aprovado antes de ser pago

  5. Tudo o que faz, num só mapa.

    Cada regra servida, cada recusa e cada correção, associadas ao seu agente e ao seu programador no Brain.

    Cursor

    1. src/billing/cart-checkout.ts

      3 regras servidas

    2. DROP TABLE invoices;

      Bloqueada

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

      Falha corrigida

    Associado a Sofia M., no Brain

Pensado para toda a equipa.

Ninguém avisou o teu agente. Agora já sabe.

Um comando. Todos os teus agentes. Sem cartão.

npx -y @cybedefend/vibedefend@latest install

Em detalhe

Depois, provado, não suposto.

Depois do commit, o BLSA (Business Logic Security Analysis, desenvolvido com o CNRS e o laboratório CRIStAL) verifica a lógica de negócio da alteração, e o seu modo prova mostra porque é que cada veredicto se cumpre ou falha: a regra, o caminho no código, a linha. Hoje o BLSA está aberto aos nossos design partners.

As oito falhas de lógica de negócio que evita
43%

das vulnerabilidades de API exploram a lógica de negócio, não uma CVE conhecida.

Wallarm, API ThreatStats 2026

Fuga multi-tenanttenant scoping nas queriesCWE-639

Consulta por id sem filtro de tenant: qualquer cliente autenticado consegue ler esta encomenda.

antes

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

depois

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

Regra: tenant scoping nas queries

Reembolso sem controloteto de autorização nos reembolsosCWE-840

Reembolso criado sem verificar a função nem o teto: sai qualquer valor para qualquer 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 });
});

depois

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

Regra: teto de autorização nos reembolsos

Idempotência em faltachave de idempotência nos webhooksCWE-837

Sem chave de idempotência: o mesmo evento Stripe repetido credita a encomenda duas vezes.

antes

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

depois

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

Regra: chave de idempotência nos webhooks

PII nos logspolítica de PII nos logsCWE-532

O req.body inteiro vai para os logs: email e palavra-passe em claro no teu fornecedor de logs.

antes

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

depois

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

Regra: política de PII nos logs

Middleware de auth ignoradomiddleware de auth obrigatório nas rotasCWE-306

Rota montada sem o middleware de auth: chega-se a /admin/users sem sessão.

antes

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

depois

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

Regra: middleware de auth obrigatório nas rotas

Rollout de feature flagdefaults seguros nas feature flagsCWE-1188

Flag ausente = true por omissão: a exportação liga-se sozinha em produção.

antes

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

depois

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

Regra: defaults seguros nas feature flags

Rate limit ausenterate limiting no loginCWE-307

Sem limite de tentativas em /login: força bruta sem travão.

antes

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

depois

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

Regra: rate limiting no login

Exportação entre tenantstenant scoping nas exportações adminCWE-285

findMany sem filtro de tenant: o CSV devolve os utilizadores de todos os clientes.

antes

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

depois

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

Regra: tenant scoping nas exportações admin

Quatro camadas, uma instalação.

Regras servidas

As regras de negócio extraídas do teu código e as tuas regras de segurança, servidas antes de cada edição.

Claude Code está a escreversrc/billing/cart-checkout.ts

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

Os montantes usam Decimal128, nunca Number.

Extraída de src/billing.ts:14

Qualquer consulta que misture dados do utilizador é parametrizada.

OWASP Top 10

Servidas antes da edição

Proteção de segredos

As leituras diretas de segredos são recusadas; o agente recebe a referência gerida.

Cursorwebhooks.ts

  1. cat .env | grep STRIPE

    Bloqueado: leitura direta de um segredo

  2. Em vez dissoprocess.env.STRIPE_WEBHOOK_SECRET

  3. npm test -- webhooks

    Os testes passam

Registado para a equipa

Controlo de ações

Comandos destrutivos, eliminações de esquema e caminhos protegidos são travados antes de correrem.

OpenAI Codex

  1. rm -rf dist/

    Permitido: saída do build

  2. rm -rf .cache/

    Permitido: cache

  3. rm -rf ./storage/uploads

    Bloqueado: caminho protegido, ficheiros dos utilizadores

Registado para a equipa

Descobertas em direto

As descobertas de SAST, SCA, segredos, IaC e CI/CD, em direto na sessão para o agente corrigir.

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

No contexto do agente, em direto

Os teus referenciais, servidos como regras.

As regras de segurança que o agente recebe seguem os referenciais que os teus auditores verificam.

  • OWASP Top 10Injeção, controlo de acesso falhado, segredos expostos.
  • SOC 2Controlo de acesso, registo de auditoria, gestão de alterações.
  • RGPDDados pessoais nos logs, conservação, minimização.
  • ISO 27001Desenvolvimento seguro e controlo de acesso.

Referenciais a que as tuas regras correspondem, não certificações da CybeDefend. A nossa própria postura

Experimenta grátis no teu próprio código.

Sem cartão. Para ires mais longe, fazemos um piloto com a tua equipa e definimos o preço contigo.

Criar uma conta gratuitaComo se define o preço

Antes de instalar.

No estudo controlado da CybeDefend de 24 de agosto de 2026, o mesmo agente aplicou 89 % das regras precisas com o VibeDefend, contra 12 % sem ferramenta e 13 % com um ficheiro de regras mantido à mão.

Ler a documentaçãoO estudo, no GitHub
O meu código sai da minha máquina?
O que envias para análise sai, sim, mas fica na região que escolheste na instalação: Paris para os clientes da UE, em infraestrutura qualificada SecNumCloud, e Iowa para os clientes dos EUA. Sempre nos nossos próprios modelos autoalojados, nunca numa API de IA de terceiros. O guarda decide na tua máquina, a telemetria só transporta metadados (nem conteúdo de prompts, nem código em bruto), as descobertas nunca mudam de região e o teu código nunca é usado para treinar um modelo.
Com que agentes funciona?
O instalador liga o Claude Code, o Cursor, o Windsurf, o GitHub Copilot e o Codex. Qualquer outro agente compatível com MCP funciona com a tua própria configuração, incluindo o Gemini CLI, o Cline, o Continue.dev e o Zed.
O que inclui o plano gratuito e o que acontece depois?
Inicia sessão e corre o comando de instalação: as tuas regras chegam ao Claude Code, Cursor, Windsurf, GitHub Copilot e Codex, e os guardrails funcionam no Claude Code, Cursor e Codex, sem cartão. Para ires mais longe, fazemos um piloto com a tua equipa e depois definimos contigo um preço à medida da tua utilização.
É mais um scanner que inunda o agente de alertas?
Não. Os scanners tradicionais correm a cada commit e afogam-te em falsos positivos. O VibeDefend atua em agent-time, sobre o diff que está a ser escrito, com reachability e conhecimento da framework, e dá ao agente uma única descoberta sobre a qual pode agir, com a correção.
Posso ler o estudo antes de me registar?
Sim, e recomendamos que o faças. O artigo de 36 páginas, as 90 transcrições, as auditorias cegas e os seis casos em que a camada não resultou estão no repositório público com link nesta página.
O que acontece quando o VibeDefend bloqueia um comando?
O comando nunca corre. O agente recebe o motivo na sua sessão, para seguir outro caminho, e a recusa fica registada para a equipa no Brain.
De onde vêm as regras que ele serve?
De duas fontes: as regras propostas a partir do teu próprio código, que uma pessoa aprova uma vez, e os referenciais que escolhes, como o OWASP Top 10, o SOC 2 ou o RGPD, servidos como regras. Antes de cada edição, o VibeDefend dá ao agente as que se aplicam ao ficheiro que ele está a alterar.
O que é verificado antes do commit?
As alterações que o agente acabou de fazer. No fim da sua resposta, o VibeDefend revê-as e devolve-lhe cada descoberta com a correção, para que reescreva a linha antes do commit. As descobertas das tuas análises SAST, SCA, segredos, IaC e CI/CD também estão na sessão, em direto.
A equipa consegue ver o que cada agente fez?
Sim. Cada regra servida, cada recusa e cada descoberta ficam ligadas ao seu agente e ao seu programador no Brain, o mapa dos teus agentes, para que um líder ou uma equipa de segurança o leia sem perguntar a ninguém.
O meu agente já verifica o próprio código. Porquê a CybeDefend?
Cada agente verifica o próprio trabalho, com as suas próprias definições. A CybeDefend dá aos cinco agentes as mesmas regras, incluindo as tuas regras de negócio, servidas antes da edição em vez de revistas depois, e guarda um único registo do que cada agente recebeu, do que foi bloqueado e do que foi corrigido.