Saltar al contenido principal
Un “rug pull” es el modo de fallo de MCP donde un servidor se comporta mientras lo vigilas y se vuelve hostil una vez que es de confianza: una herramienta que aprobaste en tiempo de conexión empieza a colar argumentos extra, un servidor comunitario que listaste añade silenciosamente una nueva capacidad, o una skill que un agente autoinstaló pasa de benigna a peligrosa en producción. El peligro es que nadie vuelve a revisar una conexión después de que está en vivo — la decisión de confianza se tomó una vez, en el handshake, y nunca se revisitó. OrcaRouter no confía en el handshake. Defiende en tres frentes. El gateway MCP del Firewall evalúa cada tools/call en tiempo de despacho contra tu política en vivo. El conjunto de herramientas anunciado de cada servidor registrado se toma como línea base en el primer sondeo y se re-verifica en busca de deriva — si el esquema de herramienta cambia respecto a la línea base aprobada, el servidor falla cerrado hasta que un admin lo re-aprueba o lo pone en cuarentena. Y la capa de Skills asigna a cada capacidad instalada una banda de riesgo y un modo de cumplimiento — poniendo en cuarentena cualquier cosa arriesgada o sin revisar hasta que un humano dé el visto bueno. Un servidor no puede ganarse un pase libre comportándose durante las primeras cien llamadas.

​
1. Por qué la protección contra rug pull de MCP necesita evaluación por llamada

Una revisión en tiempo de conexión responde una pregunta una vez: ¿es seguro listar este servidor? No puede responder la pregunta que realmente importa en tiempo de ejecución: ¿es esta llamada específica, con estos argumentos específicos, segura ahora mismo? OrcaRouter responde la segunda pregunta. Cada tools/call que cruza el gateway se evalúa en la superficie mcp antes de despacharse al servidor real, con el nombre de la herramienta y los argumentos en mano. El veredicto se computa fresco cada vez, así que en el momento en que una herramienta empieza a hacer algo que tu política prohíbe — exfiltrar un secreto en un argumento, alcanzar un host que está denegado, llamar a una capacidad que nunca aprobaste — la llamada se detiene, sin importar cómo se comportó la misma herramienta hace un minuto.
La evaluación por llamada gobierna el comportamiento de cada llamada — contenido de argumentos, destinos, el riesgo de la skill propietaria — así que atrapa un rug pull incluso cuando la herramienta mantiene una firma idéntica y solo su comportamiento se vuelve hostil. La detección de deriva de esquema (§ abajo) es la capa complementaria: atrapa el caso donde el propio conjunto de herramientas anunciado del servidor cambia. Ambas se ejecutan.
Los veredictos que el motor puede devolver en la superficie mcp:

allow / audit

Reenviado al servidor. audit registra la llamada; allow permanece en silencio.

sanitize

Reenviado con los argumentos de la llamada a herramienta redactados primero (nunca reescribe lo que el servidor devuelve).

deny

Devuelto al modelo como un error de herramienta (firewall deny: …) así el agente puede adaptarse en vez de fallar.

pending_approval

La llamada se retiene para que un humano la resuelva antes de poder ejecutarse.

​
2. Cuarentena por banda de riesgo de skill

La segunda mitad de la defensa contra rug-pull cubre la cadena de suministro: las skills, plugins y servidores MCP bring-your-own que un agente instala. Cada uno se registra como un registro con alcance de espacio de trabajo, se escanea por un motor de riesgo determinista, y se le asigna una banda de riesgo (low / medium / high / critical) más un modo de cumplimiento:
ModoEfecto en tiempo de ejecución
allowDeciden los veredictos de regla; la skill no añade nada.
quarantineCualquier cosa por debajo de un deny se escala a pending_approval — las herramientas se ejecutan solo después de que un humano aprueba.
blockLas herramientas de la skill se deniegan de plano.
Aquí es donde se contiene un rug pull. Una capacidad que un agente autoinstala es auto_detected y se pone en cuarentena hasta su revisión — incluso si escaneó limpia, no se ejecuta por su propia autoridad. Y el modo de una skill solo se aprieta más en un re-escaneo: un block o quarantine que estableces nunca se relaja silenciosamente cuando se vuelve a presentar un manifiesto.
La cuarentena se aplica independientemente del modo sombra. Una skill establecida en quarantine o block sigue retenida incluso mientras la política circundante está en despliegue sombra — así una capacidad arriesgada no puede colarse durante un despliegue por etapas.
Ver Firewall: Skills para el escáner completo, los pesos de puntuación y las señales de confianza.

​
3. Detección de deriva de esquema de herramienta

El rug pull clásico es un servidor registrado que cambia lo que anuncia — añade una herramienta, altera el esquema de entrada de una herramienta, intercambia una descripción. OrcaRouter toma como línea base el conjunto de herramientas anunciado de cada servidor registrado en un sondeo exitoso y lo vigila en busca de deriva.

Línea base en el primer sondeo

El primer sondeo exitoso registra un hash canónico de las herramientas del servidor (trust-on-first-use bajo una postura de descubrimiento; bajo una postura enforcing un servidor sin línea base se retiene como pending hasta que un admin apruebe su conjunto de herramientas inicial).

La deriva falla cerrada

En un sondeo posterior, si el conjunto de herramientas canónico ya no coincide con la línea base aprobada, el servidor se marca changed y deja de servirse — el gateway no despachará sus herramientas hasta que decidas.

Aprobar o poner en cuarentena

Re-aprueba para re-tomar como línea base el nuevo esquema, o pon el servidor en cuarentena. Un servidor en cuarentena también queda deshabilitado y solo una aprobación explícita restaura el servicio — una edición simple no puede rehabilitarlo.

Auditado

La primera detección de deriva respecto a una línea base aprobada escribe una entrada de auditoría de espacio de trabajo, así que el cambio queda registrado.
El schema_status de un servidor es uno de unknown (nunca con línea base), verified (coincide con la línea base), changed (derivado, retenido), pending (sin línea base bajo enforcing) o quarantined. Esta capa atrapa el rug pull que mueve el esquema; la evaluación por llamada (§1) atrapa el que mantiene una firma idéntica y solo cambia el comportamiento.

​
4. Un ejemplo concreto

Supón que un servidor MCP comunitario notes anuncia una herramienta inofensiva notes.search. La listas, la revisas, y funciona. Una semana después el servidor está comprometido y notes.search empieza a adjuntar un argumento de exfiltración que hace POST de tu contexto a un host atacante. Un gateway que solo evalúa en tiempo de conexión lo reenviaría — el nombre de la herramienta y el esquema parecen sin cambios. OrcaRouter evalúa la llamada: 
# Configura la regla de deny en la consola (Developer+), no vía la clave de relay.
# Regla: en la superficie mcp, deny notes.search siempre que lleve un
#        argumento con forma de exfiltración.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(Los operadores de args_match son eq, contains, regex, in, cidr_match, gt, lt; cidr_match prueba un argumento con valor de IP contra un CIDR. Para acotar dónde puede alcanzar una herramienta por host/CIDR, usa la lista de destino de egress en vez de una cláusula de argumento.) En el despacho el motor devuelve deny, y en vez de reenviar la llamada el gateway le entrega al agente un error de tool-result de MCP — un resultado normal marcado como un error, no un fallo de transporte — así el modelo puede adaptarse: 
firewall deny: <your rule's reason>
La misma llamada que tuvo éxito la semana pasada ahora está bloqueada — porque la decisión se toma sobre la llamada, no sobre la conexión.
sanitize redacta los argumentos que tu agente envía, nunca el contenido que una herramienta devuelve. Si necesitas restringir dónde puede alcanzar una herramienta, empareja una regla de deny con una lista de destino de egress — no confíes en sanitize para depurar respuestas.

​
5. Cómo encaja todo junto

La evaluación por llamada atrapa una herramienta de confianza volviéndose maliciosa — mismo nombre, nuevo comportamiento en los argumentos o el destino. La cuarentena de skill atrapa una capacidad nueva o sin revisar apareciendo siquiera — una instalación auto-detectada, un manifiesto re-escaneado que se degrada de nuevo. Un rug pull puede tomar cualquier forma, así que ambas se ejecutan: el modo de la skill cabalga encima del veredicto de regla por llamada.
Sí — ver §3. El conjunto de herramientas anunciado de cada servidor registrado se toma como línea base en el primer sondeo y se re-verifica en busca de deriva; un servidor derivado falla cerrado hasta que lo re-apruebas o lo pones en cuarentena. Eso es complementario a la evaluación por llamada, que también atrapa una herramienta que mantiene una firma idéntica y solo cambia su comportamiento.
Un veredicto pending_approval retiene la llamada para que un humano la resuelva en la consola (Developer+) o vía un callback de aprobación HMAC. Ver modos de cumplimiento para cómo se afloran las retenciones y aprobaciones a un agente.

​
6. Configurarlo

Cada paso de abajo es una acción de consola / gestión autenticada con tu token de sesión o acceso — no la clave de relay sk-orca-…. Solo el tráfico de relay /v1/* usa la clave de relay.
1

Registra tus servidores MCP detrás del gateway

Conecta cada servidor para que sus herramientas se anuncien bajo un único endpoint auditado. El registro es Developer+.
2

Establece un veredicto por defecto y reglas en la superficie mcp

Autora reglas con tool_name_glob y args_match para que las llamadas arriesgadas resuelvan a deny, sanitize o pending_approval. Ver la referencia de reglas del Firewall.
3

Revisa las skills en cuarentena

Cualquier cosa auto-detectada queda en quarantine hasta que un revisor (Developer+) la apruebe. Lee la banda y los hallazgos primero.
4

Despliega en sombra, luego aplica

Usa modos de cumplimiento para ejecutar nuevas reglas en sombra, vigila los eventos de auditoría, y cambia a enforcing una vez que los veredictos se vean correctos.
Las lecturas (configuraciones, políticas, herramientas descubiertas, anomalías) están abiertas a cualquier Member; cada escritura es Developer+. Leer el texto plano de una clave de gateway de firewall es Developer+.

​
Relacionado

Firewall: servidores MCP

La referencia completa del gateway MCP — registro, sondeo, despacho.

Firewall: Skills

Pasadas del escáner, puntuación de riesgo y la derivación de cuarentena.

Envenenamiento de herramientas MCP

El modelo de amenaza que la defensa contra rug-pull existe para contrarrestar.

Límites de egress

Autora reglas de deny de host/CIDR para acotar dónde pueden alcanzar las herramientas.

Lista de verificación de confianza

La lista de verificación de extremo a extremo para confiar en un servidor MCP.

Guardrails vs. Firewall

Cuándo aplica la política de contenido y cuándo lo hace el firewall.