Mais de 20 ferramentas, um servidor MCP. O agente lê, atualiza e comenta cada finding, traz à superfície issues semelhantes e puxa regras específicas do projeto do Cybe antes de gerar uma única linha de código.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILAROs findings de segurança viviam num dashboard que ninguém abria.
Agora é o agente que o abre a cada prompt e age sobre o que vê.
Cada CVE do teu roadmap está a uma mensagem de chat de ser fechado.
O MCP não substitui os teus scanners, dá ao agente a mesma vista a partir da qual a tua equipa de segurança trabalha, mais o acesso de escrita para agir sobre ela, mais o contexto específico do projeto para escrever código seguro desde o início.
Listas paginadas com filtros ricos (severidade, status, prioridade, linguagem, branch, packageType) mais o registo completo por finding, snippet, ficheiro, linha, árvore de pacotes, dica de remediação. Uma forma consistente em todos os scanners, para o agente ler aquilo que a tua equipa de segurança lê, na mesma chamada.
To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Atualiza prioridade, anexa um comentário, encontra um lote semelhante com uma chamada e aplica o mesmo status ao conjunto todo. Cada ação aterra no audit trail assinado pelo agente.
Antes de o agente escrever um endpoint de pagamento ou um fluxo de auth, pede as regras que o teu projeto impõe. O Cybe percorre o repositório, constrói um code knowledge graph e extrai scope de tenant, tetos de reembolso, chaves de idempotency e convenções de audit trail, devolvidos como um system prompt que o agente coloca inline antes de escrever o diff.
Cada chamada a uma ferramenta Cybe segue o mesmo caminho de três passos. O agente não orquestra, pergunta, o MCP encaminha, a resposta aterra no contexto.
O agente escolhe a ferramenta certa entre as 18 que expomos, cada uma com um schema tipado sobre o qual o seu planner pode raciocinar. Filtros e projectId herdam valores por defeito do ambiente, para que os prompts fiquem concisos.
As chamadas de vulnerabilidades batem na API REST da plataforma atrás de uma troca de PAT que se renova. As chamadas de lógica de negócio batem no Cybe, que lança um crawl incremental do knowledge graph limitado à branch pedida. A fixação de região (UE ou EUA) é imposta na fronteira.
Os findings voltam com os dados de localização de que o agente precisa para corrigir no sítio. As atualizações de status devolvem em eco a entrada do audit trail. As respostas de lógica de negócio chegam como um system prompt estruturado, prontas a ser colocadas inline antes da geração de código.
Duas vistas do mesmo prompt, "add a payment endpoint". À esquerda, o que um assistente IA genérico produz sem contexto do projeto. À direita, o que o mesmo agente produz após uma chamada a get_business_logic_context.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Handler Express boilerplate. Valor hardcoded, sem chave de idempotency, sem audit log, sem scope de tenant. Passa o linter, passa testes básicos, leva para staging um bug de cross-talk entre tenants e cobrança em duplicado.
syntax: cleanasync function refund(orderId, amount, req) {
const key = req.headers['idempotency-key'];
if (!key) return res.status(400).end();
const order = await db.orders.findById(orderId, {
where: { companyId: req.companyId },
});
if (!order) return res.status(404).end();
const cap = await stripe.refunds.create({
payment_intent: order.intent,
amount,
});
await audit.log({
actor: req.user.id,
amount,
captureId: cap.id,
});
return res.json({ ok: true });
}O Cybe devolveu três regras de projeto: limita cada pagamento por req.companyId, exige um cabeçalho Idempotency-Key, regista o operador + valor + capture-id na tabela de auditoria. O agente coloca-as inline antes de escrever o handler, o primeiro rascunho já cumpre a política.
Cada scanner expõe uma ferramenta list_… para percorrer findings e uma ferramenta get_… para mergulhar num registo único. O SCA acrescenta list_sca_packages para a árvore de dependências.
O Cybe MCP é um wrapper fino sobre a superfície REST da CybeDefend, o teu repositório nunca se move, os pesos do modelo continuam congelados, e cada chamada leva a identidade do agente para o audit trail.
Escolhe a região tanto para o runtime do MCP como para o backend da plataforma com REGION ou API_BASE. O padrão é pinning numa única região, o tráfego cross-region só acontece quando optas explicitamente. Os controlos SOC 2 Type II são aplicados de ambos os lados.
Os pesos dos modelos estão congelados apenas para inferência. Não fazemos fine-tune, RLHF nem avaliação sobre os teus repositórios, o contrato que assinas reflete isso e o audit log prova-o. O knowledge graph do Cybe é por tenant e efémero.
O próprio MCP não guarda nada, cada chamada é um pedido REST fino que faz streaming da resposta de volta para o agente. A troca PAT-para-Bearer acontece inline, a identidade do agente e os timestamps aterram no audit trail da plataforma em cada leitura ou escrita.
Ler cada finding em SAST · SCA · IaC · CI/CD · Secrets · Container com filtros completos (severidade, status, prioridade, linguagem, branch, packageType). Conduzir o ciclo de vida completo do status: To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Atualizar prioridade, deixar comentários, encontrar findings semelhantes, percorrer a árvore de dependências, obter uma visão geral do projeto. E, em cima disso, ir buscar regras de lógica de negócio específicas do projeto ao Cybe antes de gerar código novo. Mais de 20 ferramentas, todas tipadas, todas descobertas via schema, com novas a serem lançadas à medida que a plataforma cresce.
Percorre o repositório, constrói um code knowledge graph (rotas, serviços, owners, convenções de framework, fronteiras de fluxo de dados) e extrai as regras que governam o funcionamento real da base de código, scope de tenant, tetos de reembolso, chaves de idempotency, integridade do audit trail, verificações de role. Hoje as regras são extraídas e guardadas por projeto, limitadas à branch pedida. O refinamento por conta (regras a nível de organização que sobrevivem entre projetos) está a ser lançado a seguir, com personalização ainda mais granular depois disso.
Cursor, Claude Desktop, VS Code Copilot Chat (via .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed, mais qualquer cliente que fale o protocolo MCP. O mesmo servidor MCP (npx @cybedefend/mcp-server ou uma imagem Docker) liga-se a todos eles, uma instalação, todas as superfícies.
Não. O próprio MCP é um wrapper fino sobre a API REST da CybeDefend, cada chamada é um pedido, a resposta volta em streaming, nada persiste localmente. Findings, statuses e histórico de auditoria vivem no teu tenant CybeDefend. Os ficheiros de código-fonte são processados em memória pelo Cybe quando chamas get_business_logic_context, e nunca são persistidos em repouso pelo MCP.
Define REGION="eu" ou REGION="us" (ou fixa um API_BASE específico) e cada chamada aterra na região correspondente. O tráfego cross-region só acontece se o ativares explicitamente. Ambas as regiões são auditadas SOC 2 Type II e a região UE mantém fluxos de dados em conformidade com o RGPD.
Sim, update_vulnerability permite ao agente mover um finding pelo ciclo de vida completo do status, definir prioridade e anexar um comentário. Recomendamos emparelhá-lo com get_similar_vulnerabilities para o agente propor uma ação em lote (marcar uma classe de falsos positivos como not_exploitable de uma só vez, por exemplo), com cada ação carimbada com a identidade do agente para o audit trail.
Sem cartão de crédito. Sem chamada de setup. Escolhe o agente, cola o comando e o Cybe aplica as tuas regras a partir do próximo prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP alojado, sem instalação. Basta registar o URL no teu agente.