Envenenamiento de herramientas MCP y rug-pulls

Un servidor MCP de terceros o skill instalada es una dependencia de la cadena de suministro. Dos modos de fallo destacan:

• Envenenamiento — el servidor era malicioso desde el primer día. Su manifiesto parecía benigno; el comportamiento peligroso estaba en la implementación de la herramienta, no en los alcances declarados.
• Rug-pull — confiaste en él, luego cambió. Apareció una nueva herramienta que el operador del servidor añadió silenciosamente, o una entrada del registro de la comunidad fue secuestrada y actualizada para llamar a casa.

Ambas amenazas comparten una causa raíz: después de que dijiste “confío en este servidor”, tus agentes siguen llamando a sus herramientas — incluso las nuevas o modificadas — sin ninguna revisión adicional.

​

1. Cómo el envenenamiento de herramientas MCP llega a tus agentes

Cada tools/call que emite tu agente viaja a través del conjunto de herramientas declarado del servidor MCP. Un servidor envenenado o con rug-pull explota esa confianza de varias formas:

​

2. Las defensas de OrcaRouter

​

2.1 Cada tools/call se evalúa en el firewall antes de ejecutarse

Los servidores MCP se conectan a tus agentes a través del gateway MCP del Firewall en /api/v1/firewall/mcp. El gateway no reenvía una llamada a herramienta hasta que el motor del firewall la haya evaluado contra tu política. Eso significa que tu lista de permitidos es la fuente de verdad — no el manifiesto de herramientas del servidor. Si un rug-pull añade shell.exec y tu política no tiene ninguna regla que lo permita, el veredicto es deny y la llamada nunca sale del gateway. El modelo recibe un error de herramienta (firewall deny: …) y puede reaccionar; la herramienta añadida por el atacante llega muerta. Veredictos que puede devolver el motor:

​

2.2 Las capacidades auto-detectadas se ponen en cuarentena hasta ser revisadas

Cuando un agente auto-instala una capacidad — o un rug-pull añade nuevas herramientas que no estaban presentes cuando registraste el servidor — el Firewall auto-detecta la nueva capacidad fuera de la ruta caliente, sintetiza un manifiesto, lo escanea y asigna una banda de riesgo y un modo de aplicación. Crucialmente, las capacidades auto-detectadas siempre se ponen en cuarentena independientemente del resultado del escaneo: se retienen en pending_approval hasta que un humano las revise. Así es como se contienen los rug-pulls. Un operador no puede añadir silenciosamente una nueva herramienta y hacer que tus agentes empiecen a usarla — esas llamadas se retienen hasta que inspeccionas y apruebas la nueva capacidad.

​

2.3 El escaneo de skills asigna una banda de riesgo y un modo de aplicación

Cada capacidad instalable — ya sea que la registraste tú o el Firewall la auto-detectó — se pasa por el escáner de skills. El escáner ejecuta pasadas deterministas sobre el manifiesto y los alcances declarados:

• prompt_injection — texto del manifiesto que intenta secuestrar instrucciones.
• tool_creep — herramientas que el manifiesto usa pero nunca declaró.
• network_egress — hosts HTTP(S) fuera de los alcances de red aprobados.
• fs_write_unsafe — acceso al sistema de archivos en modo escritura fuera de /tmp.

Los hallazgos se acumulan en una banda de riesgo (low / medium / high / critical) y un modo de aplicación: Una skill de banda high se pone en cuarentena automáticamente; critical se bloquea. Un solo hallazgo error (p. ej. tool_creep para un shell.exec no declarado) es suficiente para bloquear una skill aunque su puntuación numérica parezca baja. El modo solo se endurecee — aprobar una skill nunca relaja un bloqueo establecido por un escaneo reciente.

​

2.4 Las credenciales se almacenan cifradas

Los secretos de autenticación del servidor se cifran en reposo con una clave de secretos del espacio de trabajo y los inyecta el gateway en el momento del despacho. Nunca llegan al modelo, al agente ni a los argumentos de la llamada. Un servidor comprometido no puede exfiltrar tus claves API leyendo su propio auth_json.

​

3. Qué hacer después de un rug-pull sospechoso

1. Deshabilita el servidor inmediatamente — un servidor deshabilitado se elimina del registro en tiempo de ejecución y sus credenciales nunca se descifran. Usa PUT /api/workspace/firewall/mcp_servers con "enabled": false.
2. Sondea de nuevo para detectar cambios — POST /api/workspace/firewall/mcp_servers/:id/probe ejecuta tools/list y devuelve cualquier nueva herramienta que apareciera desde tu último sondeo.
3. Vuelve a escanear el registro de skill — POST /api/workspace/firewall/skills/:id/rescan re-ejecuta el escáner contra el manifiesto actualizado. Si el veredicto se degrada a flagged o blocked, el Firewall emite un evento en tu feed.
4. Revisa la cola pending_approval — cualquier llamada retenida desde el rug-pull está en la cola. Inspeccínalas y denégalas en vez de aprobarlas en masa.
5. Audita el log de llamadas — comprueba el rastro de eventos del Firewall en busca de llamadas que pasaron antes de que detectaras el cambio.

​

4. Combinar el escaneo de skills con las reglas del firewall

El escaneo de skills y las reglas del firewall son complementarios y se componen:

• Una regla con tool_name_glob: community.* establecida a pending_approval asegura que revises cada llamada de un servidor procedente de la comunidad, independientemente de la banda de riesgo.
• Una skill en cuarentena anula una regla allow — incluso si tu política permite http.fetch ampliamente, una skill en cuarentena que la posee sigue reteniendo la llamada.
• Usa skill_name_glob en una regla para limitar políticas más estrictas a servidores no confiables sin afectar tus integraciones de primera parte.

Ver Firewall: Servidores MCP para el modelo completo del gateway y Firewall: Skills para la referencia del escáner y el modo de aplicación.

​

5. Amenazas relacionadas

• Llamadas a herramienta peligrosas — reglas para bloquear acciones de herramienta destructivas o irreversibles independientemente de la fuente.
• Exfiltración de datos — reglas de egress que restringen a dónde pueden enviar datos las llamadas a herramienta.
• Modelo de amenazas — la superficie de ataque completa que OrcaRouter está diseñado para defender.