Gig’MCP

The security-first MCP gateway. Run anyone's MCP server in a kernel-enforced sandbox. Your API keys never go in with it.

Get started Read the docs

Open source · AGPL-3.0 · Self-hosted

Every MCP server you install holds your raw API keys

Today an MCP server is a process you run with your credentials in its environment and unrestricted network and filesystem access. One malicious dependency, one compromised update, one prompt-injected tool call, and your Slack token, GitHub PAT, or cloud keys walk out the door. The ecosystem is built on "just trust the author."

Raw keys in the environment

Servers read API_KEY from env. Anything the process, or its dependency tree, does with that key is invisible to you.

Unrestricted egress

Nothing stops a server from POSTing your credentials to an attacker-controlled domain alongside its legitimate traffic.

Config sprawl

Per-client JSON files, duplicated tokens, no audit trail. Managing a dozen servers across clients is its own liability.

Trust the kernel, not the author

Gig'MCP makes trust unnecessary. Untrusted server code is boxed in by the kernel; credentials live on the trusted side and only ever meet the request at the network boundary.

1

Sandbox

Each server runs in a bubblewrap sandbox: private user, PID, mount, and network namespaces, seccomp filtering, no host filesystem, cleared environment. The process runs as nobody with zero capabilities.

2

Egress proxy

The sandbox's only network route is the gateway's built-in MITM proxy. It identifies the tenant by source IP, unforgeable because each sandbox sits in its own /30, and enforces the server's declared domain allowlist.

3

Vault

The server only ever sees a placeholder token. On an HTTPS call to an allowlisted domain, the proxy swaps it for the real key from the envelope-encrypted vault. The key never enters the sandbox.

Security as architecture, not policy

Kernel-enforced sandboxes

Every community MCP server runs inside bubblewrap with user, PID, mount, and network namespaces, plus a seccomp-BPF filter that closes namespace-escape and privilege-escalation paths. The server process runs as uid 65534 with zero capabilities.

Credentials stay outside

API keys live in an envelope-encrypted vault (XChaCha20-Poly1305, per-secret DEKs wrapped by a master key). The egress proxy injects them only on HTTPS calls to allowlisted domains. The key never enters the sandbox.

Signed registry

Servers ship as digest-pinned OCI images with PR-gated entitlement manifests. CI compiles manifests into an ed25519-signed index.json; the gateway verifies the signature before anything runs.

One MCP endpoint per profile

Aggregate every server behind a single streamable-HTTP endpoint per profile, each with its own bearer token. Manage users with OIDC and audit every outbound call.

Egress allowlists

Each server declares exactly which domains it may reach. Route isolation, not environment variables, is the enforcement: the sandbox's only route is the proxy, and identity is bound to the source IP.

Self-hosted & open source

AGPL-3.0 gateway, Apache-2.0 manifest schema. Run the whole stack on a homelab or VPS with a single docker compose up. Your keys never leave your hardware.

221 servers cataloged and counting

The companion registry curates manifests for 221 MCP servers: Slack, GitHub, Notion, Linear, Stripe, and more. Each declares an egress allowlist, credential schema, and security tier, lint-enforced in CI. Entries are planned manifests today; images are built and digest-pinned as servers come online ahead of launch.

Browse the 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, auditable

The gateway, sandbox runtime, egress proxy, and vault are a single Go binary under AGPL-3.0. The manifest schema is Apache-2.0. Read the threat model, audit the seccomp filter, run the whole stack on your own hardware. The security claims are in the code, not the marketing.

gigmcp/gigmcp Documentation

Be first through the gateway

Create an account, sandbox your first MCP server, and keep your keys out of it. Free and open source.

Get started