Proxy MCP de StackJack: arquitectura, autenticación y verificación operativa

Alcance y la respuesta directa

StackJack se entiende mejor como un proxy MCP remoto en lugar de un conjunto de integraciones empaquetadas en un solo cliente de IA. Su cliente de IA —Claude, ChatGPT, Copilot, Cursor o cualquier agente compatible con MCP remoto— se configura con un único endpoint MCP. StackJack recibe cada solicitud, resuelve qué conector debe manejarla, adjunta las credenciales almacenadas del usuario autenticado, aplica la política de ese usuario y reenvía la llamada a la plataforma descendente, como un PSA, RMM o inquilino de Microsoft 365.

Este artículo cubre la arquitectura y el flujo de trabajo de verificación. No recomienda un plan específico, cantidad de conectores ni proveedor. Cuando necesite un endpoint concreto o una recomendación de red, utilice el RPC Assistant en lugar de tratar esta página como una lista de proveedores.

La consecuencia práctica del modelo de proxy es que la identidad se traslada a la capa del proxy. Cada miembro del equipo inicia sesión como sí mismo y el proxy decide qué herramientas puede invocar esa identidad. Ese es un límite de seguridad diferente al de una cuenta de servicio compartida incrustada en la configuración de un cliente.

• Un endpoint del lado del cliente, muchos conectores descendentes.
• Autenticación por usuario en lugar de una clave API compartida en el cliente.
• Filtrado de políticas y catálogo aplicado en el proxy, no en el cliente.
• Metadatos de auditoría capturados en el intermediario, idealmente sin retener cargas útiles de negocio.

Requisitos previos y suposiciones

Los procedimientos a continuación suponen que tiene un cliente compatible con MCP, una cuenta en el servicio de proxy y al menos un conector configurado con credenciales válidas. También suponen que puede leer la documentación del servicio para obtener su URL MCP exacta y los metadatos de descubrimiento de OAuth; los ejemplos utilizan marcadores de posición como MCP_URL y CONNECTOR_ID deliberadamente, porque codificar de forma fija una URL de proveedor en un runbook es una trampa de mantenimiento.

Debe tener curl y Node.js o Python disponibles para los scripts de diagnóstico. Para las comprobaciones de auditoría, necesita permiso para ver el registro de auditoría del espacio de trabajo. Para cualquier prueba de escritura, utilice un inquilino que no sea de producción o un conector de sandbox, porque las llamadas a herramientas que abren tickets o modifican dispositivos tienen efectos secundarios reales.

Modelo mental: cómo un proxy MCP remoto intermedia una llamada

Un proxy MCP remoto se sitúa entre el cliente de IA y N sistemas descendentes. El cliente realiza la inicialización MCP contra el proxy y recibe un catálogo de herramientas. Cuando el modelo selecciona una herramienta, el cliente envía una solicitud tools/call al proxy. El proxy asigna el nombre de la herramienta a un conector, recupera el material de credenciales del llamante de su bóveda, construye la solicitud de API descendente y devuelve un resultado normalizado.

Dos decisiones de diseño importan operativamente. Primero, la falta de estado: un proxy que mantiene el estado de la sesión en memoria perderá sesiones durante los despliegues; un endpoint sin estado que se reautentica por solicitud sobrevive a reinicios graduales. Segundo, la forma del catálogo: cada cliente de IA importante tiene un límite de cuántas herramientas puede mantener en contexto, y algunos clientes truncan alfabéticamente o dejan de cargar más allá de ese límite. Un proxy que expone miles de herramientas debe ofrecer modos de catálogo compactos o de búsqueda bajo demanda para que el cliente no se quede silenciosamente sin las herramientas que necesita.

Piense en el proxy como una puerta de enlace de API con tres responsabilidades superpuestas al enrutamiento: federación de identidades, custodia de credenciales y gobernanza del catálogo. Cada capa es comprobable de forma independiente, que es lo que aprovechan las secciones de diagnóstico a continuación.

Límite de autenticación: OAuth, PKCE y custodia de credenciales

En un modelo por usuario, la persona se autentica en el proxy mediante OAuth, idealmente con PKCE para clientes públicos. Luego, el proxy mantiene las credenciales descendentes —ya sea una clave API pegada en una bóveda o una concesión OAuth a la plataforma descendente— asociadas con ese usuario. Cuando el cliente de IA del usuario llama a una herramienta, el proxy utiliza la credencial de ese usuario, no una cuenta de servicio de todo el espacio de trabajo.

Esto cambia la respuesta a incidentes. Revocar la identidad de proxy de un empleado que se va debería eliminar inmediatamente su capacidad de invocar herramientas descendentes, incluso si la clave API descendente en sí no ha cambiado. Verifique esa suposición explícitamente en lugar de confiar en el diagrama de arquitectura: deshabilite un usuario de prueba y luego confirme que una llamada a herramienta realizada bajo esa identidad falla en el proxy antes de llegar al conector.

La custodia de credenciales también determina su radio de impacto. Si el proxy almacena claves descendentes, un compromiso del proxy es un compromiso descendente. Pregunte si las credenciales están cifradas en reposo, si alguna vez se devuelven al cliente y si el registro de auditoría registra solo metadatos o también cargas útiles. La postura más sólida es el registro solo de metadatos con retención cero de datos de negocio, pero debe confirmarlo a partir de la documentación del proveedor y de su propia inspección de registros, no de material de marketing.

Procedimiento de diagnóstico: alcanzabilidad y descubrimiento de OAuth

Comience confirmando que el endpoint es alcanzable y anuncia sus metadatos de autorización. Reemplace MCP_URL con el endpoint MCP de la configuración de su espacio de trabajo. Un endpoint MCP remoto saludable normalmente responde a una solicitud no autenticada con un 401 o 403 y, cuando es compatible, expone metadatos de recurso protegido que apuntan al servidor de autorización.

Registre el código de estado, el encabezado WWW-Authenticate y cualquier URL de documento de descubrimiento. Estos tres valores le indican si un fallo es un problema de red, un cliente mal configurado o un problema del servidor de autorización.

curl -sS -D - -o /dev/null "$MCP_URL" \
  -H 'Accept: application/json, text/event-stream'

# If the response advertises protected-resource metadata, fetch it:
curl -sS "$MCP_URL/.well-known/oauth-protected-resource" | jq .

Procedimiento de diagnóstico: enumerar el catálogo de herramientas

Una vez autenticado, enumere las herramientas que el proxy expone a su identidad. El recuento y los nombres son su línea base. Guarde la salida para poder compararla después de un cambio de modo de catálogo o una actualización de conector.

El script a continuación realiza un initialize MCP seguido de tools/list sobre HTTP transmitible. Utiliza MCP_TOKEN como marcador de posición para un token de portador obtenido a través del flujo OAuth de su cliente; muchos clientes manejan esto internamente, en cuyo caso use la vista de inspección de herramientas del propio cliente y compárela con esta línea base.

import json, os, urllib.request

MCP_URL = os.environ["MCP_URL"]
TOKEN = os.environ["MCP_TOKEN"]

def rpc(method, params=None, session=None):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params or {}}).encode()
    headers = {
        "Authorization": f"Bearer {TOKEN}",
        "Content-Type": "application/json",
        "Accept": "application/json, text/event-stream",
    }
    if session:
        headers["Mcp-Session-Id"] = session
    req = urllib.request.Request(MCP_URL, data=body, headers=headers, method="POST")
    with urllib.request.urlopen(req) as resp:
        return resp.headers.get("Mcp-Session-Id"), resp.read().decode()

session, _ = rpc("initialize", {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {"name": "catalog-baseline", "version": "0.1.0"},
})
_, listing = rpc("tools/list", {}, session)
print(listing[:2000])

Resultado de verificación esperado y la tabla de resultados

Una ejecución exitosa produce un 401 o 403 en la sonda no autenticada, un documento de descubrimiento que nombra un servidor de autorización y una respuesta tools/list cuyos nombres de herramientas se asignan limpiamente a los conectores que configuró. Si el catálogo está truncado en relación con el recuento de herramientas documentado del conector, cambie a un modo de catálogo compacto o de búsqueda bajo demanda y vuelva a ejecutar la enumeración.

Registre sus propias mediciones en lugar de confiar en cualquier cifra citada en material del proveedor. Utilice una tabla como la siguiente, completando cada celda a partir de su ejecución:

• | Comprobación | Comando o vista | Valor observado | Criterio de aprobación |
• | Estado de sonda no autenticada | curl -D - contra MCP_URL | registrar | 401 o 403 |
• | Documento de descubrimiento | /.well-known/oauth-protected-resource | registrar | Nombra un servidor de autorización |
• | Recuento de herramientas, catálogo predeterminado | tools/list | registrar | Coincide con los conectores configurados |
• | Recuento de herramientas, catálogo compacto | tools/list después del cambio de modo | registrar | Se ajusta al límite del cliente |
• | Entrada de auditoría para una llamada de prueba | Registro de auditoría del espacio de trabajo | registrar | Con marca de tiempo, solo metadatos |

Verificación de auditoría: metadatos versus retención de cargas útiles

Los registros de auditoría son la capa de responsabilidad de un proxy. La afirmación a verificar es limitada: cada llamada a herramienta se registra con marca de tiempo, usuario, conector y nombre de herramienta, y el registro no contiene la carga útil de negocio que vio la IA. Pruébelo con una llamada a herramienta de solo lectura contra un conector de sandbox y luego inspeccione la entrada de auditoría correspondiente.

Si la entrada contiene cuerpos de tickets, inventarios de dispositivos o contenido de mensajes, la postura de retención es diferente de lo que promete un diseño de solo metadatos, y debe tratar el almacén de auditoría como datos de negocio sensibles con sus propios controles de acceso. Si la entrada falta por completo, el proxy no le está dando el rastro que necesita para la responsabilidad frente al cliente.

curl -sS "$PROXY_API_URL/audit/events?limit=5" \
  -H "Authorization: Bearer $PROXY_API_TOKEN" \
  | jq '.events[] | {ts, user, connector, tool, payload_retained}'

Solución de problemas de modos de fallo comunes

La mayoría de los fallos se agrupan en cuatro categorías: el cliente no puede alcanzar el endpoint, el flujo OAuth se completa pero faltan herramientas, una llamada a herramienta devuelve un error de autorización descendente o las sesiones se pierden durante los despliegues.

Para la alcanzabilidad, verifique las reglas de salida y si el cliente admite HTTP transmitible con eventos enviados por el servidor. Para herramientas faltantes, compare la línea base del catálogo con la lista de herramientas documentada del conector y compruebe si el cliente truncó el catálogo. Para errores de autorización descendente, confirme que la credencial del propio usuario es válida; un proxy que recurre silenciosamente a una credencial del espacio de trabajo enmascara fallos por usuario. Para sesiones perdidas, prefiera un endpoint sin estado y reinicialice al reconectar.

• 401 en cada llamada: token expirado o discrepancia de audiencia; vuelva a ejecutar el flujo OAuth.
• Herramientas presentes pero las llamadas fallan: credencial descendente inválida para ese usuario.
• Catálogo más pequeño de lo esperado: se alcanzó el límite del cliente; habilite el modo compacto.
• Desconexiones intermitentes: estado de sesión perdido en el despliegue; use un endpoint sin estado.
• Brechas de auditoría: registro deshabilitado para ese conector o ámbito de usuario.

Limitaciones y compensaciones del modelo de proxy

Un proxy concentra el riesgo. Es un único punto por el que fluye cada acción iniciada por IA, por lo que su disponibilidad, lógica de autorización e integridad de auditoría pasan a formar parte de su superficie operativa. Las credenciales por usuario mejoran la atribución pero multiplican el número de secretos que rotar. La forma del catálogo resuelve el límite del cliente pero agrega un paso de búsqueda que puede ocultar herramientas que el modelo habría seleccionado directamente.

También existe una compensación de gobernanza entre amplitud y control. Exponer cientos de conectores acelera los flujos de trabajo entre sistemas, pero cada conector es una API descendente independiente con sus propios límites de velocidad, semántica de errores y modelo de permisos. El proxy normaliza la interfaz, no el comportamiento subyacente. Presupueste pruebas por conector en lugar de asumir una fiabilidad uniforme.

Próximos pasos: de la verificación al uso en producción

Una vez que pasen las cuatro comprobaciones, promueva la configuración por etapas: primero un conector de solo lectura, luego un conector con capacidad de escritura en un inquilino de sandbox y después automatizaciones programadas. Mantenga la línea base del catálogo y la consulta de auditoría en su runbook para que las regresiones se detecten rápidamente.

Si sus flujos de trabajo de IA también tocan datos de blockchain, la misma disciplina se aplica a los endpoints RPC: verifique la alcanzabilidad, la autenticación y la consistencia de las respuestas antes de confiar en un proveedor. El RPC Assistant puede ayudarle a elegir un endpoint concreto, y la biblioteca Learn cubre la metodología circundante en guías como elegir endpoints RPC confiables, planificación de endpoints multicadena y alojamiento de nodos dedicados. Para el modelado de costos de la infraestructura que respalda estos flujos de trabajo, consulte precios de RPC y explore las redes compatibles antes de comprometerse con una topología.