Gig’MCP

El gateway MCP centrado en la seguridad. Ejecuta el servidor MCP de cualquiera en un sandbox impuesto por el kernel. Tus claves API nunca entran con él.

Empezar Lee la documentación

Código abierto · AGPL-3.0 · Autoalojado

Cada servidor MCP que instalas tiene tus claves API en crudo

Hoy un servidor MCP es un proceso que ejecutas con tus credenciales en su entorno y acceso ilimitado a la red y al sistema de archivos. Una dependencia maliciosa, una actualización comprometida, una llamada inyectada por prompt, y tu token de Slack, tu PAT de GitHub o tus claves de nube salen por la puerta. El ecosistema se basa en «confía en el autor».

Claves en crudo en el entorno

Los servidores leen API_KEY del entorno. Lo que el proceso, o su árbol de dependencias, haga con esa clave es invisible para ti.

Egreso sin restricciones

Nada impide que un servidor envíe tus credenciales a un dominio controlado por un atacante junto a su tráfico legítimo.

Configuración dispersa

Archivos JSON por cliente, tokens duplicados, sin registro de auditoría. Gestionar una docena de servidores entre clientes es un riesgo en sí mismo.

Confía en el kernel, no en el autor

Gig'MCP hace innecesaria la confianza. El código no confiable queda encerrado por el kernel; las credenciales viven en el lado confiable y solo se encuentran con la petición en el límite de red.

1

Sandbox

Cada servidor corre en un sandbox de bubblewrap: namespaces privados de usuario, PID, montaje y red, filtrado seccomp, sin sistema de archivos del host, entorno limpio. El proceso corre como nobody sin ninguna capability.

2

Proxy de egreso

La única ruta de red del sandbox es el proxy MITM integrado del gateway. Identifica al inquilino por IP de origen, infalsificable porque cada sandbox vive en su propio /30, e impone la allowlist de dominios declarada del servidor.

3

Bóveda

El servidor solo ve un token de relleno. En una llamada HTTPS a un dominio permitido, el proxy lo cambia por la clave real de la bóveda cifrada por sobres. La clave nunca entra al sandbox.

Seguridad como arquitectura, no como política

Sandboxes impuestos por el kernel

Cada servidor MCP de la comunidad corre dentro de bubblewrap con namespaces de usuario, PID, montaje y red, más un filtro seccomp-BPF que cierra las vías de escape de namespaces y de escalada de privilegios. El proceso corre como uid 65534 sin capabilities.

Las credenciales quedan fuera

Las claves API viven en una bóveda cifrada por sobres (XChaCha20-Poly1305, DEKs por secreto envueltas por una clave maestra). El proxy de egreso las inyecta solo en llamadas HTTPS a dominios permitidos. La clave nunca entra al sandbox.

Registry firmado

Los servidores se distribuyen como imágenes OCI fijadas por digest con manifiestos de permisos aprobados por PR. La CI compila los manifiestos en un index.json firmado con ed25519; el gateway verifica la firma antes de ejecutar nada.

Un endpoint MCP por perfil

Agrega todos los servidores tras un único endpoint streamable-HTTP por perfil, cada uno con su propio token bearer. Gestiona usuarios con OIDC y audita cada llamada saliente.

Allowlists de egreso

Cada servidor declara exactamente qué dominios puede alcanzar. El aislamiento de rutas, no las variables de entorno, es la imposición: la única ruta del sandbox es el proxy, y la identidad está ligada a la IP de origen.

Autoalojado y código abierto

Gateway AGPL-3.0, esquema de manifiestos Apache-2.0. Ejecuta todo el stack en tu homelab o VPS con un solo docker compose up. Tus claves nunca salen de tu hardware.

221 servidores catalogados y subiendo

El registry complementario cura manifiestos para 221 servidores MCP: Slack, GitHub, Notion, Linear, Stripe y más. Cada uno declara una allowlist de egreso, un esquema de credenciales y un nivel de seguridad, verificados por lint en CI. Hoy son manifiestos planificados; las imágenes se construyen y se fijan por digest a medida que los servidores llegan antes del lanzamiento.

Explora el registry 
name: slack-mcp
tier: sealed
entitlements:
  egress:
    - slack.com
    - "*.slack.com"
credentials:
  - id: slack_bot_token
    type: oauth2
    inject:
      header: Authorization
      format: "Bearer {token}"

AGPL-3.0, autoalojado, auditable

El gateway, el runtime del sandbox, el proxy de egreso y la bóveda son un único binario Go bajo AGPL-3.0. El esquema de manifiestos es Apache-2.0. Lee el modelo de amenazas, audita el filtro seccomp, ejecuta todo el stack en tu propio hardware. Las garantías de seguridad están en el código, no en el marketing.

gigmcp/gigmcp Documentación

Sé el primero en cruzar el gateway

Crea una cuenta, aísla tu primer servidor MCP y mantén tus claves fuera de él. Gratis y de código abierto.

Empezar