2026-07-31T06:47:52.141Z
Seguridad de puerta de enlace de MCP: demuestre que cada llamada a una herramienta cruza la puerta
Audite la propiedad de la ruta, la identidad de la persona que llama, la revisión de la política, el alcance de la herramienta, la aprobación y los efectos del destino antes de confiar en una decisión de permiso de puerta de enlace MCP.
La seguridad de la puerta de enlace MCP no se establece colocando un proxy en el diagrama de arquitectura. El valor predeterminado defendible es más estricto: demostrar que cada llamada a la herramienta de producción protegida cruzó la puerta de enlace prevista, utilizó la revisión de política esperada, llevó una identidad validada y un alcance de privilegios mínimos, produjo un recibo de auditoría y finalizó con un efecto verificado o un estado de espera explícito . Esa distinción es importante porque "puerta de entrada" describe una ubicación, no un resultado. Los resultados de búsqueda actuales en EE. UU. combinan productos de puerta de enlace, comparaciones, explicaciones de arquitectura y afirmaciones de seguridad. Su promesa común es un punto de control central entre los agentes y los servidores MCP. La cuestión operativa es si ese punto realmente poseía una determinada convocatoria. ElEspecificación de autorización MCPdefine la autorización para transportes HTTP, metadatos de recursos protegidos, descubrimiento y selección de alcance. el protocolomejores prácticas de seguridadRequerir que los implementadores consideren los riesgos de confusión del diputado, la validación de la audiencia simbólica, los peligros del traspaso de tokens, el consentimiento y la auditabilidad. Ninguno de los documentos convierte la mera presencia de un intermediario en prueba de que todas las rutas están controladas. Definir el contrato de pruebas antes de enrutar el tráfico. Comience con un manifiesto de ruta lo suficientemente pequeño como para enviarse junto a la configuración de la puerta de enlace: El manifiesto crea cinco afirmaciones comprobables: 1. la solicitud pasó a través de la puerta de enlace nombrada en lugar de una URL directa del servidor; 2. la puerta de enlace validó una carga de trabajo o una identidad de usuario no secreta; 3. la decisión surgió de la esperada y nueva revisión de la política; 4. el alcance otorgado cubrió la herramienta seleccionada sin ampliar silenciosamente el acceso; 5. la puerta de enlace emitió un recibo de auditoría que se puede unir al resultado posterior. La afirmación de la ruta no es teórica. La actualidad de CloudflareDocumentación de los portales del servidor MCPdescribe una ruta de puerta de enlace opcional para llamadas a herramientas, mientras que la sincronización en segundo plano se conecta directamente a los servidores ascendentes. También advierte que un usuario bloqueado aún puede usar la URL directa de un servidor ascendente a menos que se aplique la autenticación en ese servidor. Esos son comportamientos legítimos específicos de un producto, no reglas universales de MCP, pero demuestran por qué un inventario debe incluir todas las rutas en lugar de asumir que un portal o puerta de enlace ha eliminado las puertas laterales. Registre un sobre sin contenido por decisión. No necesita indicaciones, argumentos de herramientas, cuerpos de resultados, tokens de acceso ni secretos: Los identificadores opacos son suficientes para probar la propiedad de la ruta, el cumplimiento de la identidad, la actualidad de la política, la cobertura del alcance, el estado de aprobación y la continuidad de la recepción. Mantenga los valores secretos en su origen. Si un incidente requiere una inspección de contenido, trátelo como un flujo de trabajo independiente y explícitamente autorizado con su propio límite de retención. La autorización y la aplicación de políticas están relacionadas pero no son intercambiables. La especificación MCP dice que la autorización es opcional para una implementación; cuando se admite la autorización HTTP, el servidor protegido actúa como un servidor de recursos OAuth. Por lo tanto, una puerta de enlace no puede fabricar pruebas señalando que existía un token al portador. Debe validar el recurso y la identidad previstos, evaluar la política de herramientas relevante y preservar suficiente evidencia no secreta para explicar la decisión. La guía de seguridad de MCP identifica explícitamente el paso de tokens como un antipatrón porque puede eludir los controles y dañar la responsabilidad. Repetir ocho estados que ocultan "permitidos" El accesorio adjunto contiene ocho solicitudes sintéticas. Su clasificador aplica las puertas en orden operativo: Ejecútelo localmente: Cada veredicto exige una respuesta acotada diferente: Veredicto Lo que dice la evidencia Siguiente acción GATEWAY BYPASS La llamada protegida utilizó otra ruta o identidad de puerta de enlace. Cliente de inventario y puntos finales ascendentes; cerrar o gobernar por separado el camino directo IDENTITY NOT ENFORCED La ruta era central, pero el llamante no fue validado Rechace llamadas de producción anónimas y corrija la carga de trabajo o la identidad del usuario en el límite POLICY DRIFT La decisión utilizó una revisión antigua o evidencia obsoleta. Concilie la puerta de enlace en ejecución con el artefacto de política aprobado antes de volver a intentarlo AUTHORIZATION GAP La herramienta o su alcance requerido no coincidieron con la decisión. Denegar la llamada, reducir el alcance y agregar un caso de regresión a nivel de herramienta AUDIT GAP Es posible que se haya permitido la llamada, pero no existe ningún recibo de unión Reparar la ruta de registro/exportación; mantener el veredicto desconocido en lugar de verde EFFECT UNCERTAIN El transporte o la finalización de la herramienta no demostraron el destino. Lea el destino antes de volver a intentarlo, especialmente después de un tiempo de espera. WAITING Una acción protegida tiene una dependencia de aprobación con nombre Notificar al propietario y conservar el plazo; no etiquetar al agente atascado HEALTHY Acuerdo de ruta, identidad, política, alcance, auditoría, aprobación y efecto. Conservar los recibos a través de la ventana de revisión de incidentes. La precedencia evita que una espera de aprobación conveniente oculte una política de omisión o obsoleta. WAITING está disponible solo después de pasar las puertas de ruta, identidad, política, autorización y auditoría. Del mismo modo, un efecto descendente exitoso no excusa una llamada que pasó por alto la ruta de control. El experimento carece deliberadamente de contenido. Comprueba un contrato normalizado, no un producto de puerta de enlace en vivo. Asigne los campos de su puerta de enlace al dispositivo en lugar de copiar los nombres de los campos como si MCP los estandarizara. El protocolo define mensajes y comportamiento de autorización; Los identificadores de revisión de políticas de puerta de enlace, las formas de recibos de auditoría y los verificadores de destino siguen siendo opciones de implementación. Permiso separado del efecto resultante. Una decisión de permitir sólo prueba que una política permitió un intento. No prueba que la herramienta se ejecutó una vez, cambió el destino previsto o produjo el entregable solicitado. Para una mutación, junte el recibo de puerta de enlace con un recibo de destino: Esto es especialmente importante después de un tiempo muerto. Reintentar porque la puerta de enlace no recibió una respuesta puede duplicar un efecto que el sistema ascendente ya confirmó. EFFECT UNCERTAIN indica al operador que primero concilie el destino. Una puerta de enlace puede limitar la velocidad o autorizar un reintento, pero el destino suele ser la fuente más sólida para determinar si existe el efecto original. Para las herramientas de solo lectura, el resultado puede ser una verificación del esquema, una afirmación de actualización o una comparación determinista con los campos obligatorios de la tarea. Para las escrituras, prefiera una lectura de API, una versión de objeto inmutable, un ID de mensaje del proveedor, un hash de confirmación más comprobaciones u otro recibo propiedad del destino. El resultado exitoso de JSON RPC de una herramienta es más débil cuando el resultado prometido se encuentra en otra parte. Una implementación práctica puede ser limitada: 1. Elija un servidor MCP de producción y una herramienta de alto impacto. 2. Enumere cada punto final del cliente y la URL ascendente directa que pueda alcanzarlo. 3. Anclar una identidad de puerta de enlace y una revisión de política en la evidencia de implementación. 4. Envíe una sonda permitida y una sonda denegada con ID de solicitud opacos. 5. Verifique la identidad de la persona que llama, el alcance requerido, la decisión de la herramienta, la actualidad y un recibo de auditoría para ambos. 6. Pruebe la ruta directa documentada y demuestre que está bloqueada o regida explícitamente. 7. Ejercer una llamada que requiere aprobación y conservarla como WAITING hasta que un propietario designado decida. 8. Simule un tiempo de espera después del efecto ascendente y luego demuestre que el runbook lee el destino antes de volver a intentarlo. 9. Repita los sondeos después de los cambios en la puerta de enlace, el proveedor de identidad, la política, el cliente o el servidor MCP. Hay límites. Este dispositivo no prueba el analizador, el motor DLP, las defensas de inyección rápida ni el escáner de vulnerabilidades de un proveedor en particular. No prueba que una puerta de enlace central sea la arquitectura adecuada para cada servidor STDIO local. Un proceso local puede necesitar controles a nivel de host en lugar de una puerta de enlace de red. Tampoco convierte a Sidewisp en un modelo o puerta de enlace de herramientas requerido. La función prevista de Sidewisp es adyacente: incorporar evidencia de accesibilidad, progreso, herramientas, resultados, tiempo y presupuesto a una visión de salud del agente y preservar la autoridad humana en torno a la recuperación. Sidewisp se encuentra actualmente en versión preliminar privada. La experiencia en vivo es un sitio web de acceso temprano y una demostración interactiva; No se envían un adaptador de puerta de enlace MCP de producción, un motor de monitoreo en vivo ni un ejecutor de recuperación automatizado. Utilice el recibo de cumplimiento con su puerta de enlace actual y sus sistemas de destino en lugar de asumir que Sidewisp actualmente los monitorea o repara. La resolución es concreta: inventariar las rutas, fijar la puerta y la política, verificar la identidad y el alcance de privilegios mínimos, exigir un recibo de auditoría que se pueda unir, preservar la espera legítima y verificar el destino antes de declarar el éxito. La seguridad de la puerta de enlace MCP se convierte en evidencia operativa solo cuando la ruta de control y el efecto coinciden.