MCP Gateway & Company Teardown
Verdict: The rare "secure/governed" MCP gateway where the substrate largely backs the marketing — real authenticated encryption, server-side grant-based RBAC, genuine OpenTelemetry observability, 616 test files. One material gap undercuts the headline promise: the "encrypted vault" fails unsafe by default — an unset key silently becomes a world-known constant, the CLI claims an auto-generation that does not exist, and the key is logged in plaintext at boot. Credible, not theater; fix the default posture before "encrypted vault" is a promise you can keep for a careless operator.
MCP Mesh is deco's open-source control plane that routes all of an organisation's Model Context Protocol traffic through one governed endpoint. Agents package context, tools, and policy and publish them to the org; connections give them access to backing systems (GitHub, Slack, Postgres, Sentry — anything that speaks MCP) with credentials held in an "encrypted vault," and access granted at tool level by organisation, role, or agent. The pitch: "Share MCP capabilities — not credentials." Multi-tenant with org scoping, "deploy anywhere" (Docker, Kubernetes, local), models interchangeable per agent.
Stated vs. structural: it is marketed as a "secure gateway," but structurally it is a full control plane and app platform — inherited from deco's e-commerce-builder origins — not a thin proxy. That is a genuine strength (Virtual MCPs, runtime strategies, a real runtime SDK) but it also widens the surface where a default-posture slip can hide, which is exactly where the one real finding lives.
A TypeScript monorepo (~40k LOC of app/runtime TS) on Bun + Hono, Postgres via Kysely, NATS for the event bus, ClickHouse for monitoring. Cleanly split into packages/ (runtime, sandbox, mesh-sdk, std, bindings, tunnel…) and apps/mesh (the Studio server, auth, vault, API). The credential design is the notable decision: workloads never hold long-lived secrets — the runtime leases a short-lived access token from the server-side vault and refresh tokens and OAuth client secrets stay inside Studio (packages/runtime/src/vault.ts). That is proper least-privilege.
| Decision | What they chose | Consequence |
|---|---|---|
| Credential custody | Runtime leases short-lived access tokens; refresh tokens & client secrets never leave the server (runtime/src/vault.ts) | Compromised workload can't exfiltrate durable credentials — a strong, deliberate boundary. |
| Encryption at rest | AES-256-GCM authenticated encryption, random IV per record (apps/mesh/src/encryption/credential-vault.ts) | Correct primitive, correctly used. Value depends entirely on key provisioning — see §3. |
| Authorization | Per-scope, grant-based checks enforced at the route + org middleware (Better Auth access-control) | "Grant by org/role/agent" is enforced server-side, not advisory. Holds up. |
| Observability | Dedicated monitoring/ package: OTel trace/log exporters + ClickHouse query engine | "Full OpenTelemetry observability" is real wiring, not a logo on a slide. |
Read: a coherent, professionally-built control plane — cattle, not a pet. The bones are good; the defect is a default, not a design.
Inspected against repo state 2026-07-16, focused on the three headline claims and the credential path. The engineering is strong and the two "governance" claims (RBAC, observability) are backed by code. The single material weakness is that the encrypted vault fails unsafe by default, and it fails quietly.
| Finding | Detail | Status |
|---|---|---|
| Vault encryption is real | AES-256-GCM, per-record random IV, auth tag stored and verified on decrypt (encryption/credential-vault.ts). Textbook authenticated encryption. | Solid |
| Unsafe-by-default key | resolve-config.ts sets encryptionKey: ENV.ENCRYPTION_KEY || "". An empty key isn't rejected — it flows into CredentialVault(""), which SHA-256-hashes the empty string to a publicly-known constant. A deployment that forgets the key encrypts every connection token, OAuth client secret, and downstream token under the same world-readable AES key. No boot guard refuses to start. | Unresolved |
| False "auto-generated" claim | CLI help states ENCRYPTION_KEY … auto-generated if not set. No such generation exists outside tests — generateKey() is called only in *.test.ts. The documented safety net is not in the product. | Present |
| Key logged in plaintext at boot | settings/pipeline.ts does console.log("[settings] ENCRYPTION_KEY = " + JSON.stringify(ek) …) on every startup — a correctly-set key lands verbatim in stdout / log aggregation. | Present |
| Weak key derivation for string keys | A non-base64 key is stretched with a single unsalted createHash("sha256") — no PBKDF2/scrypt/argon2. A low-entropy operator passphrase is cheaply brute-forced offline. | Partial |
| Non-standard GCM nonce length | 16-byte IV where GCM's standard nonce is 96 bits (12 bytes). Node accepts it and random IVs keep collision risk negligible at this scale; still off-spec. Minor. | Minor |
| RBAC enforced server-side | Vault route checks the workload subject is active (→401), then a per-scope hasGrant(org, subject, target, scope) lookup (→403) before returning a token; responses carry Cache-Control: no-store. Org middleware gates non-members with careful 401-vs-403 OAuth handling. | Solid |
| Tests, CI & hygiene | 616 test files incl. integration tests; CI covers e2e, Helm, multi-pod, Windows daemon. No committed live secrets found; .env and **/.env git-ignored. | Solid |
Read: the code backs the marketing everywhere except the default. The vault is encrypted — but "encrypted vault" as a promise assumes the operator set a real key, and nothing in the product makes them. A one-line boot guard (refuse empty/weak keys outside dev) and dropping the key from the log would close most of the gap.
Built by deco (deco.cx / decocms), a Rio de Janeiro startup that raised ~$2.2M seed in Jan 2024 as a TypeScript-first brand-website / e-commerce builder, and has since pivoted its "code + deploy-anywhere" DNA into an MCP control plane for AI agents. Same pivot shape as other 2026 governance-lane entrants: an existing TS platform re-narrated around agents.
| Signal | Value | Note |
|---|---|---|
| Backing | ~$2.2M seed (est.) | Jan 2024, e-commerce thesis. No later round surfaced; the AI pivot post-dates the raise. |
| Repo activity | Very active | ~6,700 commits, release v4.58.2 dated 2026-07-16 (day of review) — ships daily. |
| Adoption (OSS) | ~390 stars | Modest — early. Single snapshot; not a trend. |
| Maintainers | 10+ listed | MAINTAINERS.txt names a real team — healthy bus factor for an OSS project this size. |
The venture-math tension is the familiar one: a small seed raised for an e-commerce builder now funding a bet in the crowded agent-infra lane. The engineering depth (§3) says the team can build; the open question is distribution, not competence.
Co-founder Guilherme Rodrigues (LinkedIn "vibegui" / "guifromrio") is a public face of deco and, tellingly, appears in the repo's MAINTAINERS.txt (vibegui) alongside the engineering team — a founder personally in the commit surface, which signals both company size and where the strategic bet is placed (the same tell worth noting in any founder-led pivot). deco has a visible Brazilian engineering community presence (Deco Day at SP Tech Week, active Product Hunt launches) and a credible TypeScript pedigree from the e-commerce era.
Credibility & risk signal: nothing in the public record contradicts the product's security posture — unlike louder entrants, deco is not running a fear-led "sell the cure" narrative. The gap here is not rhetoric versus code; it is a default-configuration oversight in otherwise careful work. That is a materially more charitable picture than a marketing-versus-substrate contradiction.
MCP governance gateways are the crowded new lane of mid-2026 — every entrant sells "secure, governed enterprise agents." deco is squeezed on all sides but holds a defensible differentiator.
| Direction | Players | Pressure |
|---|---|---|
| Open-source peers | agentgateway, MCP Mesh peers, Docker/Microsoft MCP Gateways | Commodity "one governed endpoint" framing; deco must win on being a platform, not a proxy. |
| Commercial / funded | MintMCP, Webrix, Scalekit, Arcade, Trust3 AI | Enterprise sales motion and closed "guardrail" pitches; deco counters with fully-auditable MIT code. |
| Platform incumbents | Cloud vendors' native MCP/agent controls | Bundling risk if hyperscalers ship "good enough" governance. |
Read: deco's one genuine differentiator is that it is a fully open-source, TypeScript-first control plane / app platform — Virtual MCPs and a real runtime, not just an auth proxy — where the substrate is inspectable (as this teardown demonstrates). In a lane full of closed "trust us, it's secure" pitches, "here's the code, verify it" is a sharp wedge — provided the defaults earn the trust the code is capable of.
The GTM is coordinated and developer-credible: a dedicated MCP Mesh page, docs, an "Introducing MCP Mesh: a control plane for MCP in production" post, and repeated "tokens live in the encrypted vault / share capabilities, not credentials" messaging. The demand is real — MCP governance is a live enterprise anxiety in 2026 — and deco's framing is honest about being an OSS control plane rather than magic.
The notable point is absence of scrutiny: there is no independent Hacker News or Reddit technical teardown of MCP Mesh yet. Marketing and daily shipping are present; outside code review is not — this memo is, as far as public sources show, the first substantive look at the substrate. That silence is the same pattern seen across the whole young governance lane.
Read: charitable — a strong, honest, inspectable product with one fixable default-posture bug; uncharitable — "encrypted vault" is marketed as a settled guarantee while the shipped default can silently reduce it to a public key. The evidence sits closer to the charitable reading than most of its peers would: the flaw is an oversight in careful engineering, not a substrate that can't honour the pitch.
ENCRYPTION_KEY. The Helm values file comments instruct generating one with openssl rand -base64 32 — but defaults it to "" and does not enforce it.