20+ outils, un seul serveur MCP. L'agent lit, met à jour et commente chaque finding, fait remonter les cas similaires et tire les règles propres au projet via Cybe avant de générer la moindre ligne de code.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILARLes findings vivaient dans un dashboard que personne n'ouvrait.
L'agent l'ouvre maintenant à chaque prompt et agit sur ce qu'il voit.
Chaque CVE de votre roadmap n'est qu'à un message d'être close.
Le MCP ne remplace pas vos scanners, il donne à l'agent la même vue que votre équipe sécurité, plus le droit d'écriture pour agir dessus, plus le contexte projet pour écrire du code sécurisé dès la première ligne.
Listes paginées avec filtres riches (severity, status, priority, language, branch, packageType) plus le record complet par finding, snippet, fichier, ligne, arbre de packages, hint de remédiation. Une forme cohérente sur chaque scanner pour que l'agent lise ce que votre équipe sécurité lit, dans le même appel.
To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Change la priorité, attache un commentaire, trouve un lot similaire en un appel et applique le même statut à tout le groupe. Chaque action atterrit dans l'audit trail signé par l'agent.
Avant que l'agent n'écrive un endpoint paiement ou un flux d'auth, il demande les règles que votre projet impose. Cybe parcourt le repo, construit un code knowledge graph et extrait scope tenant, plafonds de refund, idempotency keys et conventions d'audit-trail, renvoyés comme system prompt que l'agent inline avant d'écrire le diff.
Chaque appel d'outil Cybe suit le même chemin en trois étapes. L'agent n'orchestre pas, il demande, le MCP route, la réponse atterrit dans le contexte.
L'agent choisit le bon outil parmi les 18 que nous exposons, chacun avec un schéma typé que son planner peut raisonner. Filtres et projectId héritent de l'environnement pour garder les prompts courts.
Les appels vulnérabilités frappent l'API REST de la plateforme via un échange PAT auto-rafraîchi. Les appels logique métier frappent Cybe, qui lance un crawl knowledge-graph incrémental scopé à la branche demandée. Le region pinning (EU ou US) est imposé à la frontière.
Les findings reviennent avec la donnée de localisation dont l'agent a besoin pour patcher sur place. Les updates de statut renvoient l'entrée d'audit trail. Les réponses logique métier arrivent comme un system prompt structuré, prêt à inliner avant la génération de code.
Deux vues du même prompt, « ajoute un endpoint de paiement ». À gauche, ce qu'un assistant IA générique produit sans contexte projet. À droite, ce que le même agent produit après un appel à get_business_logic_context.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Handler Express boilerplate. Montant en dur, pas d'idempotency key, pas d'audit log, pas de scope tenant. Lint clean, tests basiques OK, livre un bug de cross-tenant + double-charge en 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 a renvoyé trois règles projet : scope chaque paiement par req.companyId, exige un header Idempotency-Key, log operator + montant + capture-id en audit. L'agent les inline avant d'écrire le handler, le premier brouillon respecte déjà la politique.
Chaque scanner expose un outil list_… pour parcourir les findings et un outil get_… pour creuser un record précis. SCA ajoute list_sca_packages pour l'arbre de dépendances.
Cybe MCP est un wrapper fin autour de l'API REST CybeDefend, votre repo ne bouge pas, les poids modèles restent gelés, et chaque appel embarque l'identité de l'agent dans l'audit trail.
Choisissez la région pour le runtime MCP comme pour le backend plateforme via REGION ou API_BASE. Le défaut est l'épinglage single-région ; le trafic cross-région ne se déclenche que si vous l'activez. Les contrôles SOC 2 Type II sont imposés des deux côtés.
Les poids modèles sont gelés en inference-only. On ne fine-tune pas, on ne fait pas de RLHF, on n'évalue pas sur vos repos, le contrat le reflète et l'audit log le prouve. Le knowledge graph de Cybe est par-tenant et éphémère.
Le MCP lui-même ne stocke rien, chaque appel est une requête REST fine qui stream la réponse à l'agent. L'échange PAT-vers-Bearer se fait inline ; l'identité de l'agent et les horodatages atterrissent dans l'audit trail de la plateforme pour chaque lecture ou écriture.
Lire chaque finding sur SAST · SCA · IaC · CI/CD · Secrets · Container avec filtres complets (severity, status, priority, language, branch, packageType). Piloter le cycle de vie complet du statut : To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Changer la priorité, laisser des commentaires, trouver des findings similaires, parcourir l'arbre de dépendances, récupérer un overview projet. Et par-dessus tout ça, récupérer les règles de logique métier projet via Cybe avant de générer du code. 20+ outils, tous typés, tous découverts par schéma, et de nouveaux qui arrivent au fil de la plateforme.
Cybe parcourt le repo, construit un code knowledge graph (routes, services, owners, conventions framework, frontières de data-flow) et extrait les règles qui gouvernent le fonctionnement réel de la codebase : scope tenant, plafonds de refund, idempotency keys, complétude d'audit-trail, vérifications de rôle. Aujourd'hui les règles sont extraites et stockées par projet, scopées à la branche demandée. La personnalisation par compte (règles org-wide qui survivent à travers les projets) est en déploiement, avec une personnalisation encore plus fine derrière.
Cursor, Claude Desktop, VS Code Copilot Chat (via .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed, plus tout client qui parle le protocole MCP. Le même serveur MCP (npx @cybedefend/mcp-server ou une image Docker) se connecte à tous, une install, chaque surface.
Non. Le MCP lui-même est un wrapper fin autour de l'API REST CybeDefend, chaque appel est une requête, la réponse stream en retour, rien ne persiste localement. Findings, statuts et historique d'audit vivent dans votre tenant CybeDefend. Les fichiers source sont traités en mémoire par Cybe quand vous appelez get_business_logic_context, jamais persistés au repos par le MCP.
Mettez REGION="eu" ou REGION="us" (ou pinner un API_BASE spécifique) et chaque appel atterrit dans la région correspondante. Le trafic cross-région ne se déclenche que si vous l'activez explicitement. Les deux régions sont auditées SOC 2 Type II et la région EU maintient des flux GDPR-compliant.
Oui, update_vulnerability laisse l'agent déplacer un finding à travers le cycle de vie complet, changer la priorité et attacher un commentaire. On recommande de l'associer à get_similar_vulnerabilities pour que l'agent propose une action batch (marquer une classe de faux positifs comme not_exploitable d'un coup, par exemple), avec chaque action signée par l'identité de l'agent dans l'audit trail.
Sans carte bancaire. Sans appel de configuration. Choisissez votre agent, collez la commande, Cybe applique vos règles dès le prochain prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP hébergé, aucune install. Enregistrez juste l'URL dans votre agent.