Saltar al contenido principal
Cada servidor MCP que registras, cada skill que un agente instala, y cada host que una herramienta alcanza es una dependencia que no escribiste. La cadena de suministro de un agente es dinámica — crece en tiempo de ejecución, a menudo sin un humano en el ciclo — así que el modelo clásico de “revisa el lockfile en tiempo de build” no se sostiene. Una skill de la comunidad puede ser secuestrada después de que confías en ella; un servidor MCP remoto puede añadir silenciosamente una herramienta; una herramienta de fetch puede ser dirigida a un host controlado por el atacante. La respuesta de OrcaRouter es gobernar la cadena de suministro donde actúa — en el gateway, en el primer uso — en vez de tratar de validar cada dependencia en tiempo de instalación. Esta página es el aterrizaje de caso de uso para seguridad de la cadena de suministro de IA; las referencias de Firewall y Skills llevan la mecánica completa.

​
1. Seguridad de la cadena de suministro de IA para agentes, en el gateway

El punto de estrangulamiento es la ruta de relay. Ya sea que una capacidad fuera registrada a mano, auto-instalada por el agente, o extraída de un registro de la comunidad, su primera llamada a herramienta cruza api.orcarouter.ai — y ahí es donde el Firewall la evalúa. Cuatro controles se componen en una única postura:

Gateway MCP, eval por llamada

Cada tools/call se evalúa contra tu política antes del despacho — el manifiesto nunca es la fuente de verdad.

Bandas de riesgo y cuarentena de skills

Las capacidades instaladas se escanean, puntúan y retienen para revisión hasta que un humano las aprueba.

Credenciales MCP cifradas

Los secretos de auth de servidor se cifran en reposo y se inyectan en el despacho — nunca expuestos al modelo, al agente o a los argumentos de llamada.

Listas de permitidos de egress

Fija dónde pueden enviar datos las llamadas a herramienta, para que una dependencia comprometida no pueda exfiltrar a un host que nunca aprobaste.
La detección es en el gateway, en el primer uso — no en tu gestor de paquetes o sistema de archivos. Eso es deliberado: es la única ruta que ve cada agente y cada llamada a herramienta sin importar cómo llegó ahí la capacidad.

​
2. La amenaza: una dependencia que crece después de que confías en ella

VectorQué ocurre
Rug-pullUn servidor MCP registrado añade una herramienta (shell.exec, un nuevo fetch) que nunca aprobaste.
Skill creepUna skill instalada usa herramientas o hosts que su manifiesto nunca declaró.
Robo de credencialesLa implementación de herramienta de un servidor comprometido lee su propio secreto de auth para llamar a casa.
Exfiltración de egressUna cadena recuperar→enviar envía tus datos a un host controlado por el atacante.
La causa raíz común: “confío en este servidor” se trata como permanente, y el agente sigue llamando a herramientas nuevas o modificadas sin más revisión.

​
3. Un ejemplo concreto — registrar y fijar un servidor MCP

Registras un servidor MCP de terceros desde la consola (Settings → Firewall → MCP servers; las escrituras necesitan Developer+). El secreto de auth del servidor se almacena cifrado — lo proporcionas una vez, el gateway lo inyecta en el despacho, y se enmascara en cada lectura después de eso. Un registro de servidor MCP lleva:
CampoValores
auth_modenone, bearer, oauth, basic
statusok, degraded, down (establecido por la sonda de salud)
credentialscifradas en reposo, nunca devueltas en texto plano
Tras registrar, sondéalo desde la consola para enumerar sus herramientas actuales. La sonda es una operación de sesión de espacio de trabajo (/api/workspace/firewall/*) que necesita Developer+, no una clave de relay — registrar, sondear y autorar reglas ocurren todos en el plano de gestión: 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
La sonda persiste la accesibilidad del servidor y toma una instantánea de un hash de línea base de su conjunto de herramientas anunciado (trust-on-first-use). Luego acota una regla del Firewall con tool_name_glob: <server>.* a pending_approval hasta que hayas visto un historial de llamadas limpio — cada llamada de ese servidor se retiene para un humano antes de ejecutarse. Una vez que confías en él, relaja la regla a audit o allow. A partir de ese punto el gateway MCP evalúa cada tools/call en la superficie mcp antes del despacho — así que si un rug-pull posterior añade una herramienta no declarada, tu política, no el manifiesto del servidor, decide si se ejecuta.
Re-sondea tras cualquier subida de versión upstream (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Si el conjunto de herramientas anunciado deriva de la línea base aprobada, el schema_status del servidor cambia a changed y el despacho falla cerrado hasta que un admin re-establece la línea base (approve_schema) o lo pone en cuarentena — el rug-pull no puede entrar en vivo silenciosamente.

​
4. Bandas de riesgo y cuarentena de skills

Cada capacidad instalable — ya sea que la registraste o el gateway la auto-detectó en tiempo de ejecución — se pasa por el escáner de skills. Los hallazgos se resumen en una banda de riesgo y un modo de aplicación:
low · medium · high · critical. La banda se deriva de pasadas deterministas del escáner sobre el manifiesto y los alcances declarados (uso de herramienta no declarado, egress de red fuera de los alcances aprobados, escrituras inseguras al sistema de archivos, texto de manifiesto con forma de inyección).
allow (deciden las reglas de tu política), quarantine (cualquier veredicto no-deny escala a pending_approval — un humano aprueba cada llamada), block (fuerza deny en todas las herramientas de esta skill sin importar las reglas). Una skill de banda high se pone en cuarentena automáticamente; critical se bloquea.
Una capacidad que un agente auto-instala, o una herramienta que un rug-pull añade, se retiene en pending_approval sin importar su puntuación de escaneo hasta que un humano la revisa. Un operador no puede añadir silenciosamente una herramienta y hacer que tus agentes empiecen a usarla.
El modo de aplicación solo se aprieta más — aprobar una skill nunca relaja un bloqueo que un nuevo escaneo estableció.

​
5. Listas de permitidos de egress — contén el “llamar a casa”

El resultado más dañino de la cadena de suministro es una dependencia comprometida que exfiltra. La superficie egress del Firewall evalúa el destino saliente (host / IP / CIDR) que una herramienta reporta, así que puedes fijar dónde se permite que vayan los datos. Autoras una regla de egress tú mismo: una lista de permitidos de host/CIDR con un predicado cidr_match deniega todo lo que esté fuera de la lista. Combínala con una regla de secuencia que rompa la cadena recuperar→egress, y una herramienta envenenada que intenta enviar un documento recuperado a un host desconocido se deniega en el gateway.
El nivel de autonomía tight entrega un preset de SSRF, pero deniega nombres de herramienta con forma de fetch (http_fetch, web_search, fetch_url, request) — no es una denylist de CIDR/metadatos-de-nube. Si necesitas bloqueo de egress de RFC-1918 / metadatos / CIDR específico, autora la regla deny de host/CIDR de egress tú mismo. Ver Firewall: Reglas para el operador cidr_match y el alcance de egress.

​
6. Credenciales cifradas — un servidor comprometido no puede leer tus claves

Los secretos de auth de servidor se cifran en reposo y se inyectan por el gateway en el momento del despacho. Nunca llegan al modelo, al agente, ni a los argumentos de las llamadas a herramienta — así que un servidor comprometido o malicioso no puede exfiltrar tus claves API leyendo su propio blob de credenciales. La consola siempre devuelve el secreto enmascarado — incluso a un Admin. El valor descifrado se entrega en exactamente una ruta: una solicitud que lleva un token con alcance de gateway de firewall (un tipo de token dedicado que un Admin acuña explícitamente para el gateway/proxy), así que una clave de relay filtrada ordinaria no puede enumerar tus credenciales de MCP.

​
7. Resumiéndolo para una auditoría

La gobernanza de cadena de suministro es también un artefacto de auditoría. OrcaRouter mapea al OWASP Top 10 para Aplicaciones de LLM — incluyendo el control LLM05 Supply Chain — como parte del motor de cumplimiento, junto a marcos como soc2, iso_27001, iso_42001, nist_ai_rmf y el eu_ai_act. Instalar un paquete de cumplimiento (POST /api/compliance/packs/:key/install, Admin de espacio de trabajo, plan de pago) materializa los guardrails y políticas de firewall coincidentes y empieza en una postura observe-first. Los reportes de cumplimiento incluyen una sección de evidencia de cadena-de-suministro de IA — los proveedores upstream a los que tu espacio de trabajo realmente enrutó, más una revisión de acceso privilegiado e higiene de claves — y están firmados con Ed25519 y son públicamente verificables. Navegar el catálogo y la preparación es gratis para cada Member; ver Cumplimiento para el ciclo de vida completo.
La gobernanza MCP son dos capas complementarias: evaluación de firewall por llamada en la superficie mcp (aplicación sobre lo que una dependencia hace), más una línea base de integridad de esquema de herramientas (hash trust-on-first-use del conjunto de herramientas anunciado, re-verificado en cada sonda — la deriva cambia el schema_status del servidor a changed y falla el despacho cerrado hasta que un admin re-establece la línea base o lo pone en cuarentena). Junto con las bandas de riesgo y cuarentena de skills, eso es aplicación tanto sobre lo que una dependencia hace como un registro verificable de lo que declaró.

​
8. Una línea base de cadena de suministro

Regístralo, sondea su conjunto de herramientas, y acota una regla <server>.* a pending_approval o audit. Lee los hallazgos del escaneo — cualquier hallazgo de herramienta-no-declarada o egress-externo es una razón para mantenerlo en cuarentena. Verifica quién controla la URL del endpoint.
Mantén una lista de permitidos de egress fijada para cualquier agente con herramientas de fetch/search/export. Observa la vista de Herramientas descubiertas para capacidades que aparecieron sin una regla, y el feed de anomalías para rutas de herramienta a herramienta novedosas.
Deshabilita el servidor (PUT .../mcp_servers, "enabled": false) — sus credenciales nunca se descifran mientras está deshabilitado. Re-sondea para mostrar nuevas herramientas, re-escanea la skill, y revisa la cola de pending_approval en vez de aprobar en masa.

​
9. Amenazas y conceptos relacionados

Firewall: Servidores MCP

Registra servidores MCP detrás del gateway, sondea sus herramientas, y aplica un veredicto por llamada antes de que cualquier llamada alcance el servidor real.

Firewall: Skills

Escanea y puntúa por riesgo cada capacidad instalable. Pon en cuarentena o bloquea skills riesgosas antes de que sus herramientas se ejecuten.