Gig’MCP

La passerelle MCP axée sur la sécurité. Exécutez le serveur MCP de n'importe qui dans une sandbox imposée par le noyau. Vos clés API n'y entrent jamais.

Commencer Lire la documentation

Open source · AGPL-3.0 · Auto-hébergé

Chaque serveur MCP installé détient vos clés API en clair

Aujourd'hui, un serveur MCP est un processus que vous exécutez avec vos identifiants dans son environnement et un accès illimité au réseau et au système de fichiers. Une dépendance malveillante, une mise à jour compromise, un appel d'outil injecté par prompt, et votre jeton Slack, votre PAT GitHub ou vos clés cloud disparaissent. L'écosystème repose sur « faites confiance à l'auteur ».

Clés en clair dans l'environnement

Les serveurs lisent API_KEY depuis l'environnement. Ce que le processus, ou son arbre de dépendances, fait de cette clé vous est invisible.

Egress sans restriction

Rien n'empêche un serveur d'envoyer vos identifiants vers un domaine contrôlé par un attaquant, au milieu de son trafic légitime.

Configuration éparpillée

Des fichiers JSON par client, des jetons dupliqués, aucune piste d'audit. Gérer une douzaine de serveurs entre plusieurs clients est un risque en soi.

Faites confiance au noyau, pas à l'auteur

Gig'MCP rend la confiance inutile. Le code serveur non fiable est enfermé par le noyau ; les identifiants vivent du côté fiable et ne rencontrent la requête qu'à la frontière réseau.

1

Sandbox

Chaque serveur tourne dans une sandbox bubblewrap : namespaces privés utilisateur, PID, montage et réseau, filtrage seccomp, aucun système de fichiers hôte, environnement vidé. Le processus tourne en tant que nobody, sans aucune capability.

2

Proxy d'egress

La seule route réseau de la sandbox est le proxy MITM intégré de la passerelle. Il identifie le locataire par IP source, infalsifiable puisque chaque sandbox occupe son propre /30, et applique l'allowlist de domaines déclarée du serveur.

3

Coffre

Le serveur ne voit jamais qu'un jeton factice. Lors d'un appel HTTPS vers un domaine autorisé, le proxy l'échange contre la vraie clé du coffre chiffré par enveloppe. La clé n'entre jamais dans la sandbox.

La sécurité comme architecture, pas comme politique

Sandbox imposées par le noyau

Chaque serveur MCP communautaire tourne dans bubblewrap avec des namespaces utilisateur, PID, montage et réseau, plus un filtre seccomp-BPF qui ferme les voies d'évasion de namespace et d'escalade de privilèges. Le processus serveur tourne en uid 65534 sans aucune capability.

Les identifiants restent dehors

Les clés API vivent dans un coffre chiffré par enveloppe (XChaCha20-Poly1305, DEK par secret, enveloppées par une clé maîtresse). Le proxy d'egress ne les injecte que sur des appels HTTPS vers des domaines autorisés. La clé n'entre jamais dans la sandbox.

Registry signé

Les serveurs sont livrés comme images OCI épinglées par digest avec des manifestes d'autorisations validés par PR. La CI compile les manifestes en un index.json signé en ed25519 ; la passerelle vérifie la signature avant toute exécution.

Un endpoint MCP par profil

Agrégez tous les serveurs derrière un seul endpoint streamable-HTTP par profil, chacun avec son propre jeton bearer. Gérez les utilisateurs avec OIDC et auditez chaque appel sortant.

Allowlists d'egress

Chaque serveur déclare exactement les domaines qu'il peut atteindre. C'est l'isolation des routes, et non les variables d'environnement, qui fait respecter la règle : la seule route de la sandbox est le proxy, et l'identité est liée à l'IP source.

Auto-hébergé et open source

Passerelle AGPL-3.0, schéma de manifestes Apache-2.0. Faites tourner toute la pile sur un homelab ou un VPS avec un simple docker compose up. Vos clés ne quittent jamais votre matériel.

221 serveurs catalogués, et ce n'est pas fini

Le registry compagnon organise des manifestes pour 221 serveurs MCP : Slack, GitHub, Notion, Linear, Stripe et plus. Chacun déclare une allowlist d'egress, un schéma d'identifiants et un niveau de sécurité, vérifiés par lint en CI. Ce sont aujourd'hui des manifestes planifiés ; les images sont construites et épinglées par digest à mesure que les serveurs arrivent avant le lancement.

Parcourir le 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, auto-hébergé, auditable

La passerelle, le runtime de sandbox, le proxy d'egress et le coffre forment un seul binaire Go sous AGPL-3.0. Le schéma de manifestes est en Apache-2.0. Lisez le modèle de menace, auditez le filtre seccomp, faites tourner toute la pile sur votre propre matériel. Les garanties de sécurité sont dans le code, pas dans le marketing.

gigmcp/gigmcp Documentation

Passez la passerelle en premier

Créez un compte, isolez votre premier serveur MCP et gardez vos clés à l'écart. Gratuit et open source.

Commencer