What just happened
Snowflake announced intent to acquire Natoma. If you have not been tracking the MCP-gateway category, here is the one-paragraph version: Natoma was founded in 2024 by Pratyus Patnaik (who previously sold atSpoke to Okta in 2021 and spent two-plus years there as a senior director). They raised $7M in May 2025 from Index and Greylock, hired twenty-seven people, and built a managed gateway that sits between enterprise AI agents and the Model Context Protocol servers those agents call. Their lead feature was a catalog of 100-plus verified MCP servers with managed authentication, role-based profiles, and audit logging into your SIEM.
For a Snowflake shop, that acquisition is excellent news. For everyone else: Databricks customers, BigQuery customers, multi-cloud estates, on-prem regulated industries, sovereign-cloud buyers, anyone whose data plane is intentionally heterogeneous - it is a structural problem they did not ask for. Their governance layer is now coupled to a vendor they may or may not run, on a roadmap they do not control, with pricing they did not sign up for.
The category is real
We are not going to spend this post arguing that the agentic-control -plane category does not exist. It does. The Cloud Security Alliance named it on 2026-03-23 in their working group Securing the Agentic Control Plane, backed by Cloudflare, Cisco, and Ballistic Ventures. ServiceNow and NVIDIA announced their take a month later. Natoma was already shipping a focused product against the same shape. The premise is uncontroversial at this point: AI agents are taking actions on enterprise infrastructure, and the layer that decides which actions get through is its own category, distinct from the IAM stack and from the model itself.
What we are arguing is that the right shape for that layer is open: open protocol, multi-vendor, self-hostable, and not bundled with any particular data plane or ITSM platform. The three closed shapes that have emerged in the last two months (ServiceNow + NVIDIA, Natoma + Snowflake, and the various single-vendor “agent IAM” products that follow them) each pick a winner-take-all home and ask every customer to live inside it.
The bundling problem
There is a useful exercise here. Substitute another piece of infrastructure for “agentic control plane” and ask whether the bundling makes sense.
Imagine if your endpoint-protection vendor only worked when your database was Postgres. Imagine if your identity provider only worked when your queue was Kafka. Imagine if your build system only worked when your CDN was Akamai. Each of those would be a category mistake, because the value of the security/identity/build layer is precisely that it sits across heterogeneous infrastructure. You do not want it coupled to one cloud vendor's data plane.
The agentic control plane is the same shape. Its job is to govern actions across the LLMs your stack uses, the tools your agents call, the runtimes your code executes on, and the data systems your queries hit. Coupling it to any one of those is a category error. A managed MCP gateway bundled into a data warehouse is, structurally, CrowdStrike that only protects Postgres tables.
None of this is a criticism of Snowflake. Snowflake is buying a company that fits their thesis of becoming an end-to-end agentic data platform. That is a coherent strategy for Snowflake. The problem is what happens to enterprises that are not Snowflake-standardised. Yesterday, those enterprises had a vendor in their category. Today, they have to decide whether the price of governance is a data-warehouse migration.
The open-spec alternative
The substrate underneath SynOI is open specification. Three protocols under CC0: SRAID-Core (Self-Routing Addressable Identity Data: canonical bytes, content-addressing, Ed25519 + ML-DSA-65 hybrid signatures, canonical JSON wire format), the OID Resolver (the public attestation surface at oid.synoi.systems), and GAP (the Governed Action Protocol: capability declarations, grants, invocations, multi-stage HITL workflows). Anyone can reimplement any of them. The reference Gateway is free to self-host. Receipts verify offline against any Ed25519 library in any language.
That openness is not a marketing line. It is the answer to the bundling problem. If the protocol layer is open, then the gateway that implements it is a commodity surface; if SynOI gets bought tomorrow, every customer can keep operating without our cooperation, because the substrate they depend on does not require us to be in business. Try that with a closed product owned by a data warehouse.
We also keep our governance receipts honest by making them independently verifiable. Every Decision Receipt SynOI emits is a hybrid-signed (Ed25519 + ML-DSA-65) canonical JSON document. We anchor receipt roots to sigstore Rekor on a public cadence. An auditor with no access to SynOI infrastructure can verify a receipt against the public verifier at verify.synoi.systems, or against any Ed25519 implementation they trust, anywhere. There is no “vendor product required to interpret the audit log.”
Who this matters to right now
Five buyer profiles need to re-examine their evaluation today:
- Multi-cloud estates. If you run AWS, GCP, and Azure deliberately, bundling governance into a fourth-party data warehouse defeats the point.
- Databricks and BigQuery shops. You compete with Snowflake at the data-plane layer. Adopting a Snowflake-owned governance product is an awkward dependency.
- Regulated industries. Healthcare, finance, defense, sovereign-cloud customers. You need a governance audit you can hand to a regulator without saying “trust the vendor’s log shape.”
- On-prem and air-gapped operations. Managed-cloud governance does not work if the prod estate cannot call out. SynOI's Edge tier runs offline with deferred receipt-syncing on reconnection.
- Consumer and developer tools. Single operators using OpenClaw, Claude Code, or Cursor are not Snowflake customers and will not become Snowflake customers to get a governance layer.
What we honestly cede
Natoma has product traction we do not. They have shipped, sold to enterprises, and reached an acquisition exit in eighteen months. They have built a verified catalog of more than 100 MCP servers with managed authentication. They have SOC 2. They have brand recognition in the MCP-gateway conversation.
We will earn those over the next year: SOC 2 is on the path, the verified-MCP catalog is in build (we have an internal MCP_CATALOG_AUDIT.mdtracking 108 servers across three categorisation buckets), and the brand work is exactly what posts like this one are for. What we will not do is ship the substrate as a feature of someone else's product. That is the line.
What we ask of you
Two things. If you were evaluating Natoma before yesterday, take twenty minutes and run the same proof on SynOI: install the Gateway (one environment variable), make a call, paste the resulting Decision Receipt into the public verifier, and decide whether what you see is what you wanted. Free, self-host, no account required.
If you are an engineer, designer, or operator who reads this and wants to argue with us, do. The full axis-by-axis comparison lives at /vs/natoma; the protocol specs are at /protocol; the source for the reference Gateway, the public verifier, the OID Resolver, and the SCG package is on GitHub under synoi/. Every claim on this page can be checked against running code or open specification. We will publish a follow-up post in two weeks with whatever the community pushes back on.
Sources for the factual claims about the Snowflake-Natoma transaction: the official Snowflake announcement (2026-05-28), The Register's coverage, and Natoma's own product and pricing pages as captured on 2026-05-29. Catalog count derived from Natoma's public alphabetical catalog page on the same date. We will correct any factual errors on request via the contact form.