El Model Context Protocol (MCP) resuelve un problema muy concreto: darle a un agente de IA una forma estandarizada de hablar con herramientas externas —un escáner, una base de datos, una API interna— sin tener que programar una integración distinta para cada una. Para el mundo del pentesting, eso significa poder conectar un agente a Burp Suite, Nmap, un CMS de gestión de hallazgos o un repositorio de exploits, todo bajo el mismo protocolo.

Cómo encaja en un flujo de pentesting

En la práctica, un servidor MCP expone “herramientas” (funciones) que un agente puede invocar de forma controlada: lanzar un escaneo, consultar el estado de un hallazgo, correlacionar un CVE con la versión de un servicio detectado. El agente decide qué hacer según el contexto de la conversación; el servidor MCP decide qué puede realmente ejecutar.

Agente de IA  →  Servidor MCP (nmap)     →  Ejecuta escaneo controlado
              →  Servidor MCP (cve-db)   →  Consulta vulnerabilidades conocidas
              →  Servidor MCP (reportes) →  Registra el hallazgo validado

Esa separación es la clave de un uso responsable: el servidor MCP actúa como una capa de permisos y auditoría, no como una llave maestra. Un buen diseño de MCP para pentesting limita el alcance de cada herramienta (targets permitidos, rate limits, modo solo-lectura por defecto) de la misma forma en que limitaríamos el alcance de cualquier herramienta ofensiva en un engagement autorizado.

El pentester sigue definiendo qué es vulnerable

Aquí vale repetir la idea central: un agente conectado vía MCP a diez herramientas distintas no toma decisiones de negocio por sí mismo. Puede encadenar un escaneo de puertos con una consulta de CVEs y proponer una ruta de explotación — pero la validación de que esa ruta es real, relevante y prioritaria sigue siendo un criterio humano. El MCP estandariza el cómo se conecta un agente a las herramientas; no reemplaza el por qué decidimos que algo es o no un riesgo.

Riesgos que trae esta integración

Conectar agentes a herramientas reales introduce una superficie de ataque nueva, y como profesionales de seguridad no podemos ignorarla:

  • Inyección de prompts vía datos de la herramienta: si un agente interpreta la salida de un escaneo (por ejemplo, un banner HTTP manipulado) como instrucciones, un objetivo malicioso podría intentar manipular al propio agente.
  • Exceso de permisos: un servidor MCP mal configurado puede darle a un agente más capacidad de la necesaria (por ejemplo, escritura en producción cuando solo debería tener lectura).
  • Confianza en servidores MCP de terceros: igual que con cualquier dependencia, hay que auditar qué hace realmente un servidor MCP antes de conectarlo a herramientas sensibles.

Conclusión

MCP es, en esencia, plomería: estandariza cómo un agente accede a herramientas. El valor —y el riesgo— sigue estando en cómo diseñamos esos permisos y en el criterio que aplicamos para convertir la salida de un agente en un hallazgo real. Como orquestadores, nuestro trabajo es tanto aprovechar esa velocidad como ponerle límites claros.