Gig'MCP vs Composio: self-hosted security vs hosted convenience
If you’re wiring AI agents up to real services like Slack, GitHub, Notion, or your CRM, you have a tool-access problem and a credential problem at the same time. Two projects attack this from opposite directions: Composio, a polished hosted platform, and Gig’MCP, an open-source, self-hosted MCP gateway (currently pre-launch; this post describes our design and working implementation, not a shipped product).
We think Composio is genuinely good at what it does. This post is an honest comparison of two different security philosophies, not a takedown.
What Composio actually is
It’s worth being precise here, because “MCP platform” hides a crucial architectural fact: Composio does not run third-party code.
Composio’s catalog is built from first-party, declarative connectors. A “tool” in their world is a schema that maps to an HTTP call. When your agent invokes a tool, Composio’s shared backend executes that HTTP call itself, injecting your OAuth token from their managed credential store. Their MCP product exposes dashboard-configured tool subsets per endpoint; their Rube product layers a universal meta-tool router on top.
This design has real advantages:
- It’s safe by construction. Since no untrusted code executes, there’s nothing to sandbox. Isolation is logical, not physical, and that’s defensible precisely because every connector was written by Composio.
- It’s cheap to operate. Executing a schema-described HTTP call costs almost nothing compared to running a process per tool.
- Managed OAuth is genuinely hard to replicate. Composio maintains hundreds of verified OAuth apps with the underlying providers. That’s a bureaucratic moat (months of app-review processes with Google, Slack, Microsoft, and the rest), and it makes their onboarding excellent: click, consent, done.
Where the model has limits
The same design choices create boundaries you should understand before betting on them.
The catalog is the ceiling. Because every connector is first-party, you can only use tools Composio has chosen to build and maintain. The MCP ecosystem’s energy, though, is in the long tail: community servers for niche SaaS products, homelab gear, internal APIs. A declarative HTTP-mapping model can’t absorb arbitrary community MCP servers, because community servers are code, and Composio’s security story depends on never executing third-party code.
Your credentials live in their cloud. Composio’s managed credential store is the convenience. It’s also a concentration of risk and a compliance question: your Slack admin token and GitHub access live in a third party’s multi-tenant store, and every tool call routes through their infrastructure. For many startups this trade is fine. For security-sensitive teams, homelabbers, and anyone with data-residency constraints, it’s disqualifying.
The security model is “trust us.” That’s not a slur; it’s an accurate summary, and Composio earns the trust by writing all the connectors themselves. But it means the guarantees are organizational (their code review, their ops) rather than structural (something you can verify).
Gig’MCP’s answer: make trust unnecessary
Gig’MCP starts from the opposite premise: assume the MCP server is malicious, and design so that it doesn’t matter.
The gateway runs anyone’s MCP server (community code, your code, code you’ve never read) inside a kernel-enforced sandbox, and keeps credentials structurally out of reach:
- Kernel-enforced sandboxes. Each server runs under bubblewrap with private user, PID, mount, and network namespaces. There’s no host filesystem, the environment is cleared, and after a trusted bootstrap configures networking it drops every capability and execs the server as uid 65534 (
nobody). A seccomp-BPF filter kills namespace-escape attempts (unshare,setns,clone(CLONE_NEWUSER)), the mount family,ptrace, and other escalation vectors. - Credentials never enter the sandbox. The server only ever sees a placeholder token in its environment. Real keys live in an envelope-encrypted vault (XChaCha20-Poly1305, per-secret data keys wrapped by a master key that never touches the database). When the server makes an HTTPS call to a domain on its declared allowlist, the gateway’s built-in egress proxy swaps the placeholder for the real key at the network boundary. We wrote up the full mechanism in how Gig’MCP keeps API keys out of MCP servers.
- Egress is enforced by routing, not configuration. Each sandbox’s only network route is the proxy. The proxy identifies the tenant by the connection’s source IP (unforgeable, because each sandbox can only source addresses from its own /30) and rejects any domain not on the server’s manifest allowlist. Setting
HTTPS_PROXYis a convenience; route isolation is the enforcement. - A signed, digest-pinned registry. Community servers are packaged as OCI images built by registry CI from the author’s tagged source and pinned by digest, so what was approved is what runs. Entitlement manifests (egress allowlist, credential schema, tool subset) are PR-gated, lint CI blocks wildcards and known exfiltration domains, and the gateway only trusts an ed25519-signed index.
The consequence: where Composio’s breadth is bounded by what they can write, Gig’MCP’s breadth is bounded by what the community writes, because the sandbox and proxy make the author’s trustworthiness irrelevant to your credential safety.
The self-hosting difference
Gig’MCP is AGPL-3.0 and runs as a single Go binary in a Docker container. SQLite by default, Postgres if you want it, docker compose up and you’re live on a homelab box or a $5 VPS. Your API keys exist only on hardware you control, encrypted at rest with a master key only you hold.
Composio structurally cannot offer this. Their product is the hosted credential store and execution backend. (Gig’MCP’s design anticipates an optional hosted control plane later, but self-hosting is the foundation, not an enterprise upsell.)
The flip side, stated plainly: self-hosting means you operate it. Composio’s hosted onboarding is smoother today, their managed OAuth means you never create an OAuth app yourself, and their catalog is live in production while Gig’MCP is pre-launch. With Gig’MCP you currently bring your own keys and your own OAuth app credentials, with per-provider setup guides; a managed OAuth broker is on the roadmap but doesn’t exist yet.
Honest scorecard
| Composio | Gig’MCP | |
|---|---|---|
| Security model | First-party connectors, logical isolation, “trust us” | Kernel sandbox + egress proxy, “trust isn’t required” |
| Third-party / community servers | No, never executes external code | Yes, that’s the point |
| Where credentials live | Their managed cloud store | Your hardware, envelope-encrypted |
| Self-hostable | No | Yes, AGPL-3.0 |
| Managed OAuth | Yes, hundreds of verified apps | Not yet; BYO keys and OAuth apps |
| Operational effort | Near zero | You run a container |
| Maturity | In production | Pre-launch, open development |
Which should you pick?
If you want managed OAuth, zero ops, and first-party connectors cover your needs, Composio is a strong product and the convenience is real.
If you need community MCP servers, want your keys on your own hardware, need to audit the code enforcing your security boundary, or simply refuse to route your credentials through a third party, that’s the gap Gig’MCP exists to fill.
Gig’MCP is pre-launch. The gateway source and the registry are open today, the docs cover the architecture and security model in depth, and you can watch the repo to hear when the first release ships.