Dora NodaOn May 27, 2026, Snowflake announced it would acquire Natoma, a two-year-old startup whose entire product is a centralized gateway that enforces identity, policy, and audit logging on every tool call an AI agent makes. Snowflake didn't disclose the price. Natoma had raised a $7 million seed round and employed 27 people.
The same job Snowflake just paid an undisclosed sum for has been sitting in a public GitHub repository since May 2025, licensed Apache 2.0, shipping a new release every two weeks: agentic-community/mcp-gateway-registry, built and maintained under AWS's open-source umbrella.
Why this became an acquisition target instead of a footnote
A year ago, "MCP governance" wasn't a category anyone was raising money to fill. Model Context Protocol's own SDKs have since crossed 97 million monthly downloads, and the ecosystem has gone from "one team, one hand-wired tool server" to production reports of 10,000+ concurrent connections against a single MCP deployment. Once an agent's tool calls are a production traffic pattern rather than a demo, the question every platform team eventually asks is the one Natoma was built to answer: when an agent does something to real infrastructure, who authorized it, and can you prove that after the fact?
For most companies, that question gets answered by buying software. For a platform whose own MCP server already holds deploy and rollback authority over tenant infrastructure — the exact surface bex exposes — the honest answer has to be closer to Pinterest's or the open-source gateway's model: the audit trail lives on infrastructure you control, not inside a vendor's acquisition target.
What Natoma sells vs. what you can already run
Strip away the acquisition-announcement language and Natoma's pitch is specific: a gateway that sits in front of every MCP server an enterprise's agents talk to, and for each tool call answers three questions — who requested this, what are they allowed to do, and did it happen within policy. That's the product.
Here's the same checklist against mcp-gateway-registry, feature for feature, based on the project's own documentation and AWS's open-source blog post announcing it:
| Capability | Natoma (per Snowflake's announcement) | mcp-gateway-registry (self-hosted, Apache 2.0) |
|---|---|---|
| Per-tool-call identity | Enforced at the gateway | Enforced at the gateway (OAuth2, short-lived tokens) |
| Policy enforcement | Centralized, per-action | Centralized, per-action via the registry API |
| Audit trail | Attributable, for compliance | Attributable, with credential masking, for compliance/incident review |
| Tool discovery | Verified library of MCP servers | Registry UI + API, plus federation with external registries |
| Identity provider integration | Not publicly detailed | Keycloak, Microsoft Entra, Okta, or any RFC 6749 OAuth2 token endpoint |
| Third-party SaaS token handling | Not publicly detailed | Vaults per-user OAuth tokens (3-legged OAuth) for GitHub/Slack/Atlassian-style servers, injects on egress |
| Deployment target | Snowflake's cloud, as a managed feature | Your own EKS cluster, ECS Fargate, or a single Docker Compose file |
| Who runs it | Snowflake | You |
The rows that matter for a self-hosted platform team are the last two. Natoma's governance model becomes something you rent as part of a Snowflake relationship. mcp-gateway-registry's governance model is something you deploy to infrastructure you already own, with no dependency on being a Snowflake customer, no data-warehouse platform you have to adopt to get the gateway, and no per-seat pricing negotiation.
How the gateway is actually built
The architecture splits into two planes, which is the detail that makes "self-host this" a realistic sentence rather than an aspiration.
The data plane is an nginx reverse proxy sitting in front of every registered MCP server. Every tool call an agent makes routes through nginx first — nginx doesn't make authorization decisions itself, it forwards to the auth server and only proxies the request onward once that check clears.
The control plane is a FastAPI registry API plus a web UI, backed by MongoDB Community Edition or Amazon DocumentDB (DocumentDB adds HNSW vector search in production, useful for semantic tool discovery across a large catalog). The identity provider — Keycloak, Entra, Okta, Cognito, or any OAuth2-compliant IdP — issues and validates the tokens the auth server checks on every request. OpenTelemetry instrumentation covers registrations, search latency, security scans, federation sync events, and every gateway tool invocation, so the observability story isn't an afterthought bolted onto a v2.
Two features stand out as the parts that took real engineering, not just OAuth plumbing:
- Federation. The registry implements the Anthropic MCP Registry's REST API specification in both directions — it can pull servers in from Anthropic's public registry, AWS's own Agent Registry, and peer registry instances, and it can be pulled from the same way. A team isn't stuck choosing between "use the public registry" and "run our own" — the two compose.
- Per-user third-party tokens. For MCP servers that wrap a third-party SaaS (GitHub, Slack, Atlassian), the gateway runs a 3-legged OAuth flow out of band, vaults each user's token server-side, and injects it on egress. The user's GitHub token never touches their laptop or the agent's context — only the gateway holds it.
Where you can actually run it
Three deployment paths ship in the repo, and they map cleanly onto how big the team standing this up actually is:
- Docker Compose on a single EC2 instance (or a laptop). This is the on-ramp — bring up the full stack, including the identity provider, in one
docker compose up. It's what you'd use to evaluate the project before committing infrastructure to it. - ECS Fargate via Terraform. A serverless production path with multi-AZ high availability and autoscaling, no cluster to manage. This is the fit for a team that wants production governance without also taking on Kubernetes operations.
- EKS via Helm charts. The Kubernetes-native path, also multi-AZ and autoscaling, for a team that's already running workloads on EKS and wants the gateway to live alongside them instead of as a separate operational surface.
For a platform built on Cluster API — where the fleet is already Kubernetes clusters you provision and manage yourselves — the EKS/Helm path is the one that fits without introducing a second infrastructure model. You'd register bex's own deploy/rollback/logs/scale MCP server behind the gateway the same way you'd register any other tool server, put an OAuth2 identity provider in front of it, and get a per-call audit trail — who deployed what, when, under whose identity — without writing that logging layer by hand inside the MCP server itself.
What "register the deploy tool" actually looks like
Concretely, putting a platform's own MCP server behind this gateway is a three-step operation, not a rewrite of the server itself:
- Register the server. Point the registry at bex's MCP server endpoint (its deploy, rollback, logs, and scale tools) and it appears in the catalog alongside any other registered server — discoverable by an agent client, but not yet reachable without a token.
- Wire the identity provider. Point the auth server at an existing IdP — Keycloak if the team already runs it, Entra or Okta if that's the company directory, or Cognito for an AWS-native setup — and issue OAuth2 client-credentials tokens scoped to the specific tools an agent identity is allowed to call.
- Read the audit log instead of writing one. Every call that reaches the deploy tool through the gateway is already logged with the caller's identity, the tool invoked, and the outcome, with credentials masked in the record. The question "which agent redeployed the payments service at 2 a.m., and under whose authorization" becomes a query against an existing log, not a forensic reconstruction from application logs never designed for that question.
None of that requires touching the deploy/rollback tool's own implementation. The gateway sits in front of it; the governance is additive.
The trade you're actually making
None of this means self-hosting is free of cost, just that the cost moves. Buying Natoma (or, once the acquisition closes, buying it as a Snowflake feature) gets a team a support contract, a vendor who's paged when the gateway itself breaks, and — implicitly — tighter integration with Snowflake Intelligence and Cortex Code if that's already the data stack in use. Running mcp-gateway-registry yourself means your team owns patching, scaling, and tracking a project that ships a new release every two weeks; there's no vendor SLA if the auth server has a bad day at 3 a.m.
That trade isn't hypothetical — production evidence that the self-run version scales past a side project already exists. Pinterest published a detailed account of its internal MCP ecosystem in March 2026: every MCP server tied to an owning team, registered centrally, and required to clear security and privacy review before going to production, with runtime calls governed by two auth layers (end-user JWTs plus service-mesh identity). By their own numbers, that registry-plus-gateway pattern was handling 66,000 monthly tool invocations across 844 users and had saved an estimated 7,000 engineering hours — a company operating the "governance you run yourself" model at real scale, not a demo.
For a self-hosted PaaS whose whole pitch is owning the infrastructure instead of renting someone else's control plane, that's the more consistent answer even before the cost math: the deploy/rollback authority an MCP server holds over tenant infrastructure is exactly the kind of thing you don't want gated behind a third party's acquisition roadmap.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
