20+ herramientas, un solo servidor MCP. El agente lee, actualiza y comenta cada finding, hace aflorar issues similares y obtiene reglas específicas del proyecto desde Cybe antes de generar una sola línea de código.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILARLos findings de seguridad vivían en un dashboard que nadie abría.
Ahora el agente lo abre en cada prompt y actúa sobre lo que ve.
Cada CVE de tu roadmap está a un mensaje de chat de cerrarse.
El MCP no reemplaza tus escáneres: le da al agente la misma vista desde la que trabaja tu equipo de seguridad, más el acceso de escritura para actuar, más el contexto específico del proyecto para escribir código seguro desde el primer momento.
Listas paginadas con filtros ricos (severidad, estado, prioridad, lenguaje, rama, packageType) más el registro completo por finding: snippet, archivo, línea, árbol de paquetes, hint de remediación. Una forma consistente para cada escáner, así el agente lee lo que tu equipo de seguridad lee, en la misma llamada.
To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Actualiza prioridad, adjunta un comentario, encuentra un lote similar con una llamada y aplica el mismo estado al grupo. Cada acción aterriza en el audit trail firmada por el agente.
Antes de que el agente escriba un endpoint de pago o un flujo de auth, pide las reglas que aplica tu proyecto. Cybe rastrea el repo, construye un code knowledge graph y extrae scope de tenant, topes de reembolso, idempotency keys y convenciones de audit trail, devueltos como system prompt que el agente inserta antes de escribir el diff.
Cada llamada a una herramienta Cybe sigue el mismo camino de tres pasos. El agente no orquesta: pide, el MCP enruta, la respuesta aterriza en contexto.
El agente elige la herramienta adecuada de las 18 que exponemos, cada una con un schema tipado sobre el que su planner puede razonar. Filters y projectId toman su default del entorno para que los prompts queden escuetos.
Las llamadas de vulnerabilidad pegan a la API REST de la plataforma detrás de un intercambio PAT que se refresca. Las llamadas de lógica de negocio pegan a Cybe, que lanza un crawl incremental del knowledge graph limitado a la rama solicitada. El pinning de región (EU o US) se aplica en la frontera.
Los findings vuelven con los datos de localización que el agente necesita para parchear in situ. Las actualizaciones de estado devuelven la entrada de audit trail como eco. Las respuestas de lógica de negocio llegan como system prompt estructurado, listo para inlinear antes de la generación de código.
Dos vistas del mismo prompt, "añade un endpoint de pago". A la izquierda, lo que produce un asistente IA genérico sin contexto de proyecto. A la derecha, lo que el mismo agente produce tras una llamada a get_business_logic_context.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Handler Express boilerplate. Importe hardcodeado, sin idempotency key, sin audit log, sin scope de tenant. Pasa linters, pasa tests básicos, envía un cross-talk de tenant + double-charge a 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 devolvió tres reglas de proyecto: pone scope a cada pago por req.companyId, exige un header Idempotency-Key, registra el operador + importe + capture-id en la tabla de auditoría. El agente las inserta antes de escribir el handler: el primer borrador ya cumple la política.
Cada escáner expone una herramienta list_… para recorrer findings y una get_… para entrar a un registro. SCA suma list_sca_packages para el árbol de dependencias.
Cybe MCP es un wrapper fino sobre la superficie REST de CybeDefend: tu repo nunca se mueve, los pesos del modelo siguen congelados, y cada llamada lleva la identidad del agente al audit trail.
Elige la región tanto para el runtime MCP como para el backend de la plataforma con REGION o API_BASE. El default es pinning de una sola región; el tráfico cross-region solo ocurre cuando lo activas explícitamente. Los controles SOC 2 Type II se aplican en ambos lados.
Los pesos del modelo están congelados, solo para inferencia. No hacemos fine-tuning, ni RLHF, ni evaluación sobre tus repos: el contrato que firmas lo refleja y el audit log lo prueba. El knowledge graph de Cybe es por tenant y efímero.
El MCP en sí no almacena nada: cada llamada es una petición REST fina que devuelve la respuesta en streaming al agente. El intercambio PAT-a-Bearer ocurre inline; la identidad del agente y las marcas de tiempo aterrizan en el audit trail de la plataforma en cada lectura o escritura.
Leer cada finding en SAST · SCA · IaC · CI/CD · Secrets · Container con filtros completos (severidad, estado, prioridad, lenguaje, rama, packageType). Conducir el ciclo de vida de estado completo: To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Actualizar prioridad, dejar comentarios, encontrar findings similares, recorrer el árbol de dependencias, obtener un overview del proyecto. Y, por encima de eso, traer reglas de lógica de negocio específicas del proyecto desde Cybe antes de generar código nuevo. 20+ herramientas, todas tipadas, todas con schema descubierto, con más en camino según crece la plataforma.
Rastrea el repo, construye un code knowledge graph (rutas, servicios, owners, convenciones de framework, fronteras de data flow) y extrae las reglas que rigen cómo funciona realmente la base de código: scope de tenant, topes de reembolso, idempotency keys, completitud de audit trail, comprobaciones de rol. Hoy las reglas se minan y guardan por proyecto, limitadas a la rama solicitada. El refinamiento por cuenta (reglas a nivel de org que sobreviven entre proyectos) llega a continuación, con personalización aún más granular.
Cursor, Claude Desktop, VS Code Copilot Chat (vía .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed, más cualquier cliente que hable el protocolo MCP. El mismo servidor MCP (npx @cybedefend/mcp-server o una imagen Docker) se conecta a todos ellos: una instalación, todas las superficies.
No. El MCP en sí es un wrapper fino sobre la API REST de CybeDefend: cada llamada es una petición, la respuesta vuelve en streaming, nada persiste en local. Findings, estados e historial de auditoría viven en tu tenant CybeDefend. Los ficheros fuente los procesa Cybe en memoria cuando llamas a get_business_logic_context, sin que el MCP los persista en reposo.
Pon REGION="eu" o REGION="us" (o fija un API_BASE específico) y cada llamada aterriza en la región correspondiente. El tráfico cross-region solo ocurre si lo activas explícitamente. Ambas regiones están auditadas SOC 2 Type II y la región EU mantiene flujos de datos conformes con GDPR.
Sí, update_vulnerability permite al agente mover un finding por el ciclo de vida completo, fijar prioridad y adjuntar un comentario. Recomendamos emparejarlo con get_similar_vulnerabilities para que el agente proponga una acción por lote (marcar una clase de falsos positivos como not_exploitable de una vez, por ejemplo), con cada acción firmada con la identidad del agente para el audit trail.
Sin tarjeta. Sin llamada de configuración. Elige tu agente, pega el comando, y Cybe aplica tus reglas desde el siguiente prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP alojado, sin instalación. Solo registra la URL en tu agente.