Skip to content
VeriSwarm
Acerca de
DocumentaciónPreciosHabilidad del agente
Iniciar sesiónRegistrarse
  1. Inicio
  2. /Learn
  3. /Scan mcp server
VeriSwarm
  • English
  • ✓ Español
  • Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Producto

  • Precios
  • Documentación
  • API
  • Habilidad del agente
  • Especificación OATS

Confianza

  • Centro de confianza
  • Seguridad
  • Cumplimiento
  • Estado
  • Registro de cambios

Empresa

  • Acerca de
  • Blog
  • Código abierto
  • Inversionistas
  • Prensa

Legal

  • Términos
  • Privacidad
  • SLA
  • DPA
  • Accesibilidad
Guard · Seguridad MCP

Cómo analizar la seguridad de un servidor MCP

Todos los servidores MCP a los que te conectas envían una respuesta tools/list — un documento JSON escrito por quien haya construido el servidor — directamente al contexto de tu modelo, sin revisar. Pega esa respuesta en el escáner de VeriSwarm y obtén 11 comprobaciones deterministas en segundos: envenenamiento de herramientas, typosquatting, manipulación de esquemas, patrones de rug-pull, inyección de prompts, permisos excesivos, enlace incorrecto de modelo, suplantación de contexto, canales encubiertos, referencias de memoria inseguras e inyección de cabeceras. Sin ningún LLM juzgando tus herramientas — análisis de patrones y estructura que devuelve el mismo veredicto siempre.

Por qué esto tiene que automatizarse, no revisarse a simple vista

Los metadatos de una herramienta MCP son estructurales. El modelo decide qué llamar y cómo basándose en el texto de la descripción — no en el código que hay detrás. Una descripción envenenada no necesita comprometer nada; el ataque ocurre por completo dentro del razonamiento del modelo. El benchmark MCPTox probó esto contra 45 servidores MCP reales y 353 herramientas reales, y midió tasas de éxito de ataque por encima del 60%, llegando hasta el 72%. Leer descripciones de herramientas a simple vista no escala más allá del primer servidor, y no sobrevive a un rug pull — un servidor que se comporta con normalidad durante tu revisión y envía algo distinto en la siguiente actualización de versión.

Las seis comprobaciones principales

Cubren las categorías de riesgo originales para las que se construyó el escáner — las que con más probabilidad aparecen en una definición de herramienta envenenada o descuidada.

Envenenamiento de herramientas

Instrucciones ocultas en descripciones y en el texto de los parámetros — «ignora las instrucciones anteriores», directivas de ocultación, secuestros de persona. El escáner recorre todo el árbol del esquema, incluidas las propiedades anidadas dentro de ramas oneOf/anyOf, así que una carga útil enterrada cuatro niveles por debajo sigue saliendo a la luz.

Typosquatting

Nombres de herramientas sospechosamente parecidos a herramientas conocidas — incluidas suplantaciones que solo cambian mayúsculas/minúsculas, como READ_FILE haciéndose pasar por read_file, algo que una comparación exacta e ingenua pasa por alto por completo.

Manipulación de esquemas

Esquemas de objeto vacíos que aceptan cualquier entrada, additionalProperties: true que deja colar campos ocultos, y esquemas anidados a más de 4 niveles de profundidad — un lugar habitual para esconder un parámetro malicioso.

Patrones de rug-pull

Lenguaje que solicita credenciales, tokens o acceso a archivos sensibles y endpoints de red internos que el propósito declarado de la herramienta no justifica — la preparación para una redefinición posterior una vez que la herramienta ya es de confianza.

Inyección de prompts

Bloques en Base64 que se decodifican en texto legible — contrabando de cargas útiles — y homoglifos Unicode, como una а cirílica que sustituye a tu a, usados para colar instrucciones más allá de una revisión visual.

Permisos excesivos

Una herramienta nombrada o descrita como de solo lectura que acepta parámetros command, script o sql está declarando una capacidad y entregando otra distinta.

Cinco más, alineadas con el OWASP MCP Top 10 v0.1-beta (2025)

Riesgos específicos del protocolo que las seis originales no cubren. Entre las once comprobaciones, el escáner cubre 9 de los 10 riesgos del OWASP MCP Top 10 v0.1-beta (2025). El décimo — MCP08, Falta de Auditoría y Telemetría — no es algo que una definición de herramienta estática pueda mostrar; es una carencia de registro en tiempo de ejecución, no de esquema.

Enlace incorrecto de modelo

Herramientas ancladas a un modelo concreto — «solo funciona con GPT-4» o un requisito de acoplamiento al system prompt. Genera una dependencia de enrutado y una superficie de explotación específica de ese modelo.

Suplantación de contexto

Una herramienta que afirma poder reescribir el historial de la conversación, inyectar turnos falsos o suplantar al usuario o al asistente — capacidades que pueden anular a la vez los filtros de seguridad y los registros de auditoría.

Canales encubiertos

Claves de nivel superior no estándar, campos de esquema de extensión de proveedor (x-) y bloques largos en base64 incrustados en descripciones — lugares donde un revisor que busca prosa no va a mirar.

Referencias de memoria inseguras

Lenguaje que reclama acceso a estado global, compartido o entre sesiones, o un parámetro session_id con un comodín por defecto — el patrón detrás de una ruptura del aislamiento entre tenants.

Inyección de cabeceras

Un parámetro con forma de nombre de cabecera — incluyendo authorization, cookie o host — o uno conectado a una solicitud saliente a través de la extensión x-mcp-header de la especificación MCP. Ambos pueden sobrescribir una cabecera de frontera de confianza que quien llama nunca ve.

Cómo ejecutarlo: API, SDK o el propio servidor MCP

Las mismas 11 comprobaciones, el mismo formato de informe, tres formas de hacerlo:

  • Llamada directa a la API. POST /v1/suite/guard/scan-mcp con las definiciones de herramientas en el cuerpo. Devuelve un veredicto (pass / warn / fail), una puntuación de riesgo de 0–1 y un array de hallazgos — cada hallazgo incluye el nombre de la herramienta, la comprobación que se disparó, la severidad, la evidencia y una recomendación.
  • SDK. scanMcpTools() en el SDK de Node, scan_mcp_tools() en el SDK de Python — ambos envuelven el mismo endpoint con formas de solicitud/respuesta tipadas.
  • El servidor MCP alojado de VeriSwarm. Si tu agente ya habla MCP, la herramienta scan_mcp_tools del propio servidor MCP de VeriSwarm le permite escanear las herramientas de otro servidor antes de llamarlas — sin necesidad de un cliente HTTP aparte.

Los hallazgos con severidad crítica o alta se guardan como hallazgos de escaneo de Guard en tu tenant, así que un resultado de escaneo no es una impresión de consola de un solo uso — es un registro que puedes revisar, priorizar y cerrar con el tiempo.

Escanear una vez no es suficiente

Una definición de herramienta que hoy pasa el escaneo limpia puede enviar algo distinto mañana — la propiedad que define un rug pull es precisamente que la versión que auditaste no es la versión que ejecutarás la semana que viene. Ejecuta el escaneo en cada actualización de versión del servidor MCP, o según un calendario, no solo en la primera conexión. El escáner es la mitad previa al despliegue de la historia; la mitad en tiempo de ejecución — filtrando las llamadas a herramientas en vivo a medida que ocurren, después de que el servidor ya haya pasado un escaneo — es Guard Proxy. Ninguno sustituye al otro: el escáner detecta lo que una herramienta declara, Guard Proxy detecta lo que hace.

El envenenamiento de herramientas es la comprobación que más merece la pena entender en profundidad — es aquella en la que el ataque ocurre por completo dentro del razonamiento del modelo, sin nada que detectar en la capa de red. El mecanismo del ataque, las tasas reales de éxito y cómo lo detecta el escáner se desglosan en Envenenamiento de herramientas MCP: cómo funciona el ataque y cómo detectarlo.

Preguntas frecuentes

¿Cómo escaneo un servidor MCP en busca de problemas de seguridad?

Llama a su método tools/list para obtener las definiciones de herramientas y envía ese array al escáner de VeriSwarm — POST /v1/suite/guard/scan-mcp, el scanMcpTools() del SDK de Node, el scan_mcp_tools() del SDK de Python, o la herramienta scan_mcp_tools del servidor MCP alojado. Los cuatro llaman al mismo motor de 11 comprobaciones y devuelven el mismo informe estructurado: un veredicto (pass/warn/fail), una puntuación de riesgo de 0-1 y, por cada hallazgo, severidad, evidencia y una recomendación.

¿Qué comprueba realmente el escáner?

Once comprobaciones deterministas: envenenamiento de herramientas, typosquatting, manipulación de esquemas, patrones de rug-pull, inyección de prompts y permisos excesivos cubren las seis categorías de riesgo originales; enlace incorrecto de modelo, suplantación de contexto, canales encubiertos, referencias de memoria inseguras e inyección de cabeceras alinean el escáner con 9 de los 10 riesgos del OWASP MCP Top 10 v0.1-beta (2025) — todos los riesgos salvo MCP08 (Falta de Auditoría y Telemetría), que no es algo que una definición de herramienta estática pueda mostrarte; necesita registro en tiempo de ejecución, no un escaneo de esquema. Cada comprobación se basa en patrones y estructura — sin ningún LLM en el bucle, así que una definición de herramienta dada produce los mismos hallazgos cada vez que la escaneas.

¿Usa el escáner un LLM para juzgar las herramientas?

No. Es un analizador estático — patrones de expresiones regulares, recorridos del árbol del esquema y normalización Unicode, no una llamada a un modelo. Es una decisión deliberada: los jueces probabilísticos son la razón por la que al menos una auditoría independiente de un escáner de MCP basado en YARA reportó una tasa de falsos positivos de en torno al 78%. Las comprobaciones deterministas sacrifican algo de recall a cambio de algo que una pipeline de CI realmente puede usar como puerta de calidad — la misma entrada produce el mismo veredicto dos veces.

¿Puedo ejecutar esto en CI, o solo contra un servidor en vivo?

Ambas cosas. En CI, guarda la respuesta tools/list de un servidor en un archivo y escanéala como un paso de la pipeline — un hallazgo crítico es un build que falla, no un hilo de Slack después de los hechos. En producción, llama al endpoint de la API según un calendario o en cada actualización de versión del servidor MCP, porque una herramienta que salió limpia una vez solo se conoce como buena una vez. Volver a escanear es cómo se detecta un rug-pull — un servidor que se comporta bien durante la revisión y se vuelve malicioso después — en lugar de pasarlo por alto.

¿Cuál es la diferencia entre escanear y Guard Proxy?

El escáner es la mitad previa al despliegue: lee las definiciones de herramientas declaradas antes de que tu agente llegue a llamar al servidor. Guard Proxy es la mitad en tiempo de ejecución: se sitúa entre tu agente y sus herramientas, filtrando cada llamada en vivo a medida que ocurre. Ninguno sustituye al otro. El escáner detecta lo que una herramienta dice que hace; Guard Proxy detecta lo que realmente hace en el momento de la llamada.

¿Es el envenenamiento de herramientas un riesgo realmente serio, o más bien teórico?

Está medido, no es teórico. El benchmark MCPTox probó el envenenamiento de herramientas contra 45 servidores MCP reales y 353 herramientas reales, y encontró tasas de éxito de ataque por encima del 60%, llegando al 72% en el pico — con los modelos más capaces obedeciendo con más frecuencia, porque seguir mejor las instrucciones también significa cumplir mejor una instrucción maliciosa. Un desglose completo de la mecánica del ataque y de cómo lo detecta la comprobación tool_poisoning del escáner está en el explicativo dedicado.

Escanea tu primer servidor con una sola llamada a la API

Envía una respuesta tools/list a Guard y descubre qué han estado leyendo tus agentes. El nivel gratuito de Gate te da primero el pipeline de puntuación de confianza y eventos; el escáner de Guard funciona encima de él.

Probar la demoEmpezar gratis