Gig’MCP

Il gateway MCP incentrato sulla sicurezza. Esegui il server MCP di chiunque in una sandbox imposta dal kernel. Le tue chiavi API non ci entrano mai.

Inizia Leggi la documentazione

Open source · AGPL-3.0 · Self-hosted

Ogni server MCP che installi detiene le tue chiavi API in chiaro

Oggi un server MCP è un processo che esegui con le tue credenziali nell'ambiente e accesso illimitato a rete e filesystem. Una dipendenza malevola, un aggiornamento compromesso, una chiamata iniettata via prompt, e il tuo token Slack, il PAT di GitHub o le chiavi cloud se ne vanno. L'ecosistema si regge su «fidati dell'autore».

Chiavi in chiaro nell'ambiente

I server leggono API_KEY dall'ambiente. Ciò che il processo, o il suo albero di dipendenze, fa con quella chiave ti è invisibile.

Egress senza limiti

Niente impedisce a un server di inviare le tue credenziali a un dominio controllato da un attaccante insieme al suo traffico legittimo.

Configurazioni sparse

File JSON per ogni client, token duplicati, nessun audit trail. Gestire una dozzina di server tra più client è un rischio a sé.

Fidati del kernel, non dell'autore

Gig'MCP rende la fiducia superflua. Il codice server non fidato è confinato dal kernel; le credenziali vivono sul lato fidato e incontrano la richiesta solo al confine di rete.

1

Sandbox

Ogni server gira in una sandbox bubblewrap: namespace privati utente, PID, mount e rete, filtro seccomp, nessun filesystem host, ambiente ripulito. Il processo gira come nobody senza alcuna capability.

2

Proxy di egress

L'unica rotta di rete della sandbox è il proxy MITM integrato del gateway. Identifica il tenant dall'IP sorgente, non falsificabile perché ogni sandbox vive nel proprio /30, e applica l'allowlist di domini dichiarata dal server.

3

Vault

Il server vede solo un token segnaposto. A ogni chiamata HTTPS verso un dominio consentito, il proxy lo sostituisce con la chiave reale dal vault cifrato a busta. La chiave non entra mai nella sandbox.

Sicurezza come architettura, non come policy

Sandbox imposte dal kernel

Ogni server MCP della community gira dentro bubblewrap con namespace utente, PID, mount e rete, più un filtro seccomp-BPF che chiude le vie di fuga dai namespace e di escalation dei privilegi. Il processo server gira come uid 65534 senza capability.

Le credenziali restano fuori

Le chiavi API vivono in un vault cifrato a busta (XChaCha20-Poly1305, DEK per segreto avvolte da una chiave master). Il proxy di egress le inietta solo su chiamate HTTPS verso domini consentiti. La chiave non entra mai nella sandbox.

Registry firmato

I server sono distribuiti come immagini OCI bloccate per digest con manifesti di permessi approvati via PR. La CI compila i manifesti in un index.json firmato ed25519; il gateway verifica la firma prima di eseguire qualsiasi cosa.

Un endpoint MCP per profilo

Aggrega tutti i server dietro un unico endpoint streamable-HTTP per profilo, ognuno con il proprio bearer token. Gestisci gli utenti con OIDC e audita ogni chiamata in uscita.

Allowlist di egress

Ogni server dichiara esattamente quali domini può raggiungere. È l'isolamento delle rotte, non le variabili d'ambiente, a far rispettare la regola: l'unica rotta della sandbox è il proxy, e l'identità è legata all'IP sorgente.

Self-hosted e open source

Gateway AGPL-3.0, schema dei manifesti Apache-2.0. Esegui l'intero stack su homelab o VPS con un solo docker compose up. Le tue chiavi non lasciano mai il tuo hardware.

221 server catalogati, e il numero cresce

Il registry complementare cura manifesti per 221 server MCP: Slack, GitHub, Notion, Linear, Stripe e altri. Ognuno dichiara un'allowlist di egress, uno schema di credenziali e un livello di sicurezza, verificati dal lint in CI. Oggi sono manifesti pianificati; le immagini vengono costruite e bloccate per digest man mano che i server arrivano prima del lancio.

Esplora il 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, self-hosted, verificabile

Gateway, runtime della sandbox, proxy di egress e vault sono un unico binario Go sotto AGPL-3.0. Lo schema dei manifesti è Apache-2.0. Leggi il threat model, verifica il filtro seccomp, esegui l'intero stack sul tuo hardware. Le garanzie di sicurezza stanno nel codice, non nel marketing.

gigmcp/gigmcp Documentazione

Passa per primo dal gateway

Crea un account, isola il tuo primo server MCP e tieni le tue chiavi al sicuro. Gratuito e open source.

Inizia