20+ Tools, ein MCP-Server. Der Agent liest, updated und kommentiert jedes Finding, hebt ähnliche Issues hervor und zieht projekt-spezifische Regeln von Cybe, bevor er eine einzige Code-Zeile generiert.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILARSecurity-Findings lebten früher in einem Dashboard, das niemand geöffnet hat.
Der Agent öffnet es jetzt bei jedem Prompt und handelt nach dem, was er sieht.
Jede CVE auf deiner Roadmap ist eine Chat-Nachricht davon entfernt, geschlossen zu werden.
Das MCP ersetzt deine Scanner nicht, es gibt dem Agent denselben Blick, mit dem dein Security-Team arbeitet, plus Schreibzugriff zum Handeln, plus den projekt-spezifischen Kontext, um von Anfang an sicheren Code zu schreiben.
Paginierte Listen mit reichen Filtern (Severity, Status, Priorität, Sprache, Branch, packageType) plus der vollständige Record pro Finding, Snippet, Datei, Zeile, Package-Tree, Remediation-Hinweis. Eine konsistente Form über alle Scanner hinweg, damit der Agent dasselbe liest wie dein Security-Team, im selben Call.
Zu prüfen → Bestätigt → Behoben · Nicht ausnutzbar · Vorgeschlagen nicht ausnutzbar · Ignoriert. Priorität updaten, Kommentar anhängen, einen ähnlichen Batch mit einem Call finden und denselben Status auf die ganze Gruppe anwenden. Jede Aktion landet im Audit-Trail, signiert vom Agent.
Bevor der Agent einen Payment-Endpoint oder Auth-Flow schreibt, fragt er nach den Regeln, die dein Projekt durchsetzt. Cybe crawlt das Repo, baut einen Code Knowledge Graph und extrahiert Tenant-Scope, Refund-Caps, Idempotency-Keys und Audit-Trail-Konventionen, zurückgeliefert als System-Prompt, den der Agent inlined, bevor er den Diff schreibt.
Jeder Cybe-Tool-Call folgt demselben Drei-Schritt-Pfad. Der Agent orchestriert nicht, er fragt, das MCP routet, die Antwort landet im Kontext.
Der Agent wählt das richtige Tool aus den 18, die wir exponieren, jedes mit typisiertem Schema, über das sein Planner reasonen kann. Filter und projectId defaulten aus dem Environment, damit Prompts knapp bleiben.
Vulnerability-Calls treffen die REST-API der Plattform hinter einem refreshenden PAT-Exchange. Business-Logik-Calls treffen Cybe, das einen inkrementellen Knowledge-Graph-Crawl auf den angefragten Branch scoped. Region-Pinning (EU oder US) wird an der Boundary durchgesetzt.
Findings kommen mit den Location-Daten, die der Agent zum In-Place-Patchen braucht. Status-Updates spiegeln den Audit-Trail-Eintrag zurück. Business-Logik-Antworten kommen als strukturierter System-Prompt an, bereit zum Inlinen vor der Code-Generierung.
Zwei Sichten desselben Prompts, "add a payment endpoint". Links das, was ein generischer KI-Assistent ohne Projekt-Kontext produziert. Rechts das, was derselbe Agent nach einem Call von get_business_logic_context produziert.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Boilerplate-Express-Handler. Hardcoded amount, keine Idempotency-Key, kein Audit-Log, kein Tenant-Scope. Linter sauber, Basis-Tests bestanden, shippt einen Tenant-Cross-Talk- und Double-Charge-Bug nach 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 gab drei Projekt-Regeln zurück: jede Payment-Operation per req.companyId scopen, einen Idempotency-Key-Header verlangen, Operator + Betrag + Capture-ID in die Audit-Tabelle loggen. Der Agent inlined sie vor dem Handler, der erste Draft erfüllt schon die Policy.
Jeder Scanner exponiert ein list_…-Tool, um durch Findings zu laufen, und ein get_…-Tool, um in einen einzelnen Record zu drillen. SCA fügt list_sca_packages für den Dependency-Tree hinzu.
Cybe MCP ist ein dünner Wrapper um die REST-Surface von CybeDefend, dein Repo bewegt sich nicht, deine Model-Weights bleiben eingefroren, und jeder Call trägt die Identität des Agents in den Audit-Trail.
Wähl die Region für MCP-Runtime und Plattform-Backend per REGION oder API_BASE. Default ist Single-Region-Pinning; Cross-Region-Traffic passiert nur, wenn du explizit zustimmst. SOC-2-Type-II-Kontrollen werden auf beiden Seiten durchgesetzt.
Model-Weights bleiben für reines Inferenz-Verhalten eingefroren. Wir fine-tunen, RLHF-en oder evaluieren nicht auf deinen Repos, der Vertrag, den du unterzeichnest, spiegelt das wider und der Audit-Log beweist es. Der Knowledge Graph von Cybe ist pro Tenant und ephemeral.
Das MCP selbst speichert nichts, jeder Call ist ein dünner REST-Request, der die Antwort an den Agent zurückstreamt. Der PAT-zu-Bearer-Exchange passiert inline; die Identität des Agents und Timestamps landen für jedes Read und Write im Audit-Trail der Plattform.
Jedes Finding über SAST · SCA · IaC · CI/CD · Secrets · Container mit vollen Filtern (Severity, Status, Priorität, Sprache, Branch, packageType) lesen. Den vollen Status-Lifecycle steuern: Zu prüfen → Bestätigt → Behoben · Nicht ausnutzbar · Vorgeschlagen nicht ausnutzbar · Ignoriert. Priorität updaten, Kommentare hinterlassen, ähnliche Findings finden, den Dependency-Tree ablaufen, einen Projekt-Überblick bekommen. Und obendrauf projekt-spezifische Business-Logik-Regeln von Cybe abrufen, bevor neuer Code generiert wird. 20+ Tools, alle typisiert, alle per Schema discoverable, mit neuen, die mit der Plattform mitwachsen.
Es crawlt das Repo, baut einen Code Knowledge Graph (Routen, Services, Owner, Framework-Konventionen, Data-Flow-Boundaries) und extrahiert die Regeln, die festlegen, wie die Codebase tatsächlich funktioniert: Tenant-Scope, Refund-Caps, Idempotency-Keys, Audit-Trail-Vollständigkeit, Role-Checks. Heute werden die Regeln pro Projekt geschürft und gespeichert, scoped auf den angefragten Branch. Pro-Account-Verfeinerung (org-weite Regeln, die Projekte überdauern) kommt als Nächstes, mit noch feinerer Personalisierung danach.
Cursor, Claude Desktop, VS Code Copilot Chat (über .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed plus jeder Client, der das MCP-Protokoll spricht. Derselbe MCP-Server (npx @cybedefend/mcp-server oder ein Docker-Image) verbindet sich mit allen, eine Installation, jede Surface.
Nein. Das MCP selbst ist ein dünner Wrapper um die REST-API von CybeDefend, jeder Call ist ein Request, die Antwort streamt zurück, lokal persistiert nichts. Findings, Status und Audit-History leben in deinem CybeDefend-Tenant. Source-Dateien werden von Cybe in-memory verarbeitet, wenn du get_business_logic_context aufrufst, und nie at-rest vom MCP persistiert.
Setze REGION="eu" oder REGION="us" (oder pinne eine spezifische API_BASE), und jeder Call landet in der jeweiligen Region. Cross-Region-Traffic passiert nur, wenn du es explizit aktivierst. Beide Regionen sind SOC-2-Type-II-auditiert, und die EU-Region erhält DSGVO-konforme Datenflüsse.
Ja, update_vulnerability lässt den Agent ein Finding durch den vollen Status-Lifecycle bewegen, Priorität setzen und einen Kommentar anhängen. Wir empfehlen, es mit get_similar_vulnerabilities zu paaren, damit der Agent eine Batch-Action vorschlagen kann (etwa eine Klasse von False-Positives in einem Rutsch als not_exploitable markieren), wobei jede Action mit der Identität des Agents im Audit-Trail gestempelt wird.
Keine Kreditkarte. Kein Setup-Call. Wähle deinen Agent, kopiere den Befehl, und Cybe setzt deine Regeln ab dem nächsten Prompt durch.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpGehostetes MCP, keine Installation. Einfach die URL bei deinem Agent registrieren.