20+ tool, un solo server MCP. L'agente legge, aggiorna e commenta ogni finding, fa emergere casi simili, e tira le regole specifiche del progetto da Cybe prima di generare una singola riga di codice.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILARI finding di sicurezza vivevano in una dashboard che nessuno apriva.
L'agente ora la apre a ogni prompt e agisce su ciò che vede.
Ogni CVE nella tua roadmap è a un messaggio di chat dall'essere chiuso.
L'MCP non sostituisce i tuoi scanner, dà all'agente la stessa vista da cui lavora il tuo team di sicurezza, più l'accesso in scrittura per agire, più il contesto specifico del progetto per scrivere codice sicuro fin dall'inizio.
Liste paginate con filtri ricchi (severity, status, priority, language, branch, packageType) più il record completo per finding, snippet, file, riga, albero dei package, hint di remediation. Una forma coerente su ogni scanner, così l'agente legge quello che legge il tuo team di sicurezza, nella stessa chiamata.
To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Aggiorna la priorità, allega un commento, trova un batch simile con una sola chiamata e applica lo stesso stato a tutto il lotto. Ogni azione finisce nell'audit trail firmato dall'agente.
Prima che l'agente scriva un endpoint di pagamento o un flusso di auth, chiede le regole che il tuo progetto applica. Cybe percorre il repo, costruisce un code knowledge graph ed estrae scope tenant, tetti di refund, idempotency key e convenzioni di audit-trail, restituiti come system prompt che l'agente inlinea prima di scrivere il diff.
Ogni chiamata di tool Cybe segue lo stesso percorso in tre fasi. L'agente non orchestra, chiede, l'MCP instrada, la risposta atterra nel contesto.
L'agente sceglie il tool giusto fra i 18 che esponiamo, ciascuno con uno schema tipizzato su cui il suo planner può ragionare. Filtri e projectId ereditano dall'environment per tenere i prompt brevi.
Le chiamate vulnerabilità colpiscono l'API REST della piattaforma dietro uno scambio PAT auto-rinnovato. Le chiamate di logica di business colpiscono Cybe, che avvia un crawl incrementale del knowledge graph scoped sul branch richiesto. Il region pinning (EU o US) è imposto al boundary.
I finding tornano con i dati di location di cui l'agente ha bisogno per patchare in place. Gli update di stato fanno eco alla voce di audit trail. Le risposte di logica di business arrivano come system prompt strutturato, pronto a essere inlinato prima della generazione del codice.
Due viste dello stesso prompt, "aggiungi un endpoint di pagamento". A sinistra, ciò che un assistente IA generico produce senza contesto progetto. A destra, ciò che lo stesso agente produce dopo una chiamata a get_business_logic_context.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Handler Express boilerplate. Amount hardcoded, niente idempotency key, niente audit log, niente scope tenant. Linta pulito, passa i test basilari, spedisce un bug di cross-talk fra tenant + double-charge in staging.
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 });
}Cybe ha restituito tre regole di progetto: scope di ogni pagamento per req.companyId, richiedi un header Idempotency-Key, logga operator + amount + capture-id nella tabella di audit. L'agente le inlinea prima di scrivere l'handler, il primo draft rispetta già la policy.
Ogni scanner espone un tool list_… per scorrere i finding e un tool get_… per scendere su un singolo record. SCA aggiunge list_sca_packages per l'albero delle dipendenze.
Cybe MCP è un wrapper sottile attorno alla superficie REST di CybeDefend, il tuo repo non si sposta, i pesi del modello restano congelati, e ogni chiamata porta l'identità dell'agente nell'audit trail.
Scegli la regione sia per il runtime MCP sia per il backend di piattaforma con REGION o API_BASE. Il default è il pinning single-region; il traffico cross-region accade solo se lo abiliti esplicitamente. I controlli SOC 2 Type II sono imposti da entrambi i lati.
I pesi del modello sono congelati per la sola inference. Non facciamo fine-tuning, RLHF o valutazione sui tuoi repo, il contratto che firmi lo riflette e l'audit log lo prova. Il knowledge graph di Cybe è per-tenant ed effimero.
L'MCP in sé non immagazzina nulla, ogni chiamata è una richiesta REST sottile che streama la risposta indietro all'agente. Lo scambio PAT-to-Bearer avviene inline; l'identità dell'agente e i timestamp atterrano nell'audit trail della piattaforma per ogni lettura o scrittura.
Leggere ogni finding su SAST · SCA · IaC · CI/CD · Secrets · Container con filtri completi (severity, status, priority, language, branch, packageType). Pilotare il ciclo di vita completo dello stato: To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Aggiornare la priorità, lasciare commenti, trovare finding simili, percorrere l'albero delle dipendenze, ottenere un overview di progetto. E sopra tutto questo, recuperare regole di logica di business specifiche del progetto da Cybe prima di generare nuovo codice. 20+ tool, tutti tipizzati, tutti scoperti via schema, e nuovi in rilascio mentre la piattaforma cresce.
Percorre il repo, costruisce un code knowledge graph (route, servizi, owner, convenzioni di framework, frontiere di data-flow) ed estrae le regole che governano come la codebase funziona davvero: scope tenant, tetti di refund, idempotency key, completezza dell'audit-trail, check di ruolo. Oggi le regole sono estratte e archiviate per progetto, scoped al branch richiesto. La rifinitura per-account (regole org-wide che sopravvivono tra progetti) è in arrivo nel rilascio successivo, con personalizzazione ancora più granulare a seguire.
Cursor, Claude Desktop, VS Code Copilot Chat (via .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed, più qualsiasi client che parli il protocollo MCP. Lo stesso server MCP (npx @cybedefend/mcp-server o un'immagine Docker) si connette a tutti, una installazione, ogni superficie.
No. L'MCP in sé è un wrapper sottile attorno alla REST API CybeDefend, ogni chiamata è una richiesta, la risposta streama indietro, niente persiste in locale. Finding, status e storia di audit vivono nel tuo tenant CybeDefend. I file sorgente vengono elaborati in memoria da Cybe quando chiami get_business_logic_context, mai persistiti at rest dall'MCP.
Imposta REGION="eu" o REGION="us" (o pinna uno specifico API_BASE) e ogni chiamata atterra nella regione corrispondente. Il traffico cross-region accade solo se lo abiliti esplicitamente. Entrambe le regioni sono auditate SOC 2 Type II e la regione EU mantiene flussi di dati GDPR-compliant.
Sì, update_vulnerability permette all'agente di muovere un finding lungo l'intero ciclo di vita dello stato, impostare la priority e allegare un commento. Consigliamo di abbinarlo a get_similar_vulnerabilities così l'agente può proporre un'azione batch (marcare una classe di falsi positivi come not_exploitable in un colpo solo, ad esempio), con ciascuna azione timbrata sull'identità dell'agente per l'audit trail.
Senza carta di credito. Senza call di setup. Scegli il tuo agente, incolla il comando, e Cybe applica le tue regole dal prossimo prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP hosted, nessuna installazione. Registra solo l'URL nel tuo agente.