On May 27, 2026, Snowflake announced its intent to acquire Natoma. This validates both Natoma and the enterprise Model Context Protocol governance category. Still, the acquisition prompts engineering leaders, AI platform teams, and security buyers to reassess their multi-user agent infrastructure.

When evaluating MCP runtime alternatives, you’re facing a real architectural decision of whether to stay tethered to an ecosystem-native gateway or adopt an independent or vendor-neutral MCP runtime.

Key takeaways

  • Choose Arcade.dev if you need an independent MCP runtime with secure agent authorization via On-Behalf-Of (OBO), agent-optimized tools, agent lifecycle governance, and flexible deployment (cloud, VPC, and air-gapped).
  • Choose AWS AgentCore if you’re all-in on AWS/Bedrock and accept AWS-only constraints.
  • Choose WorkOS if your main gap is enterprise SSO/directory sync (identity), not agent execution.
  • Choose Merge if your main need is normalized integrations and bulk data sync, not multi-step agent workflows.
PlatformKey differentiatorDeployment flexibility
ArcadeUnified auth, tools, and governance runtimeCloud, VPC, Air-gapped
AWS AgentCoreNative AWS IAM and Bedrock integrationAWS-only
WorkOSDeveloper-first human identity auth APIsCloud
MergeUnified API data normalizationCloud

What the Snowflake acquisition means for Natoma users

Snowflake’s acquisition of Natoma signals that strict AI governance is now a core enterprise requirement. Natoma is a fully managed enterprise MCP gateway that enforces Cedar-based attribute access control (ABAC), shadow-AI discovery, SSO and SCIM, and SIEM/EDR integrations.

Enterprises currently discover an average of 225 unmanaged shadow AI instances per organization. That makes centralized governance an immediate security priority. But this acquisition shifts the product roadmap toward native Snowflake Intelligence and Cortex ecosystems.

Under the agreement, Snowflake will build Natoma into its governance and identity layer for AI agents and MCP tool access, using it as the centralized gateway enforcing identity, policy, and audit at the tool-call level.

This raises real questions for current and prospective Natoma users. Will Natoma remain available and supported as a standalone product, or be folded into Snowflake’s stack? Will the roadmap orient toward Snowflake Intelligence, Cortex, and the broader Snowflake ecosystem?

When Natoma still makes sense after the acquisition

Natoma makes sense for enterprises already embedded in the Snowflake ecosystem, with internal role-based access control (RBAC) as their primary governance layer. It also suits platform teams that prioritize native integration with Cortex tools such as search and analyst services.

Enterprise buyers who prefer their agent governance bundled with their core data warehouse procurement will find the combined offering a natural fit.

How to evaluate Natoma alternatives in 2026

An enterprise agent setup rests on three core pillars: agent authorization, agent-optimized tool reliability, and agent lifecycle governance. Any production runtime must solve all three simultaneously, plus deployment flexibility as a cross-cutting requirement.

A detailed architectural diagram illustrating the workflow and components of an MCP Runtime system within a B2B SaaS environment. A Client Application sends a Tool Request to the central MCP Runtime hub, which orchestrates three branches: Identity Context and Authorization (to Per-User Delegated Authorization, then to an OAuth / Identity Provider for Policy Evaluation); Tool Catalog and Execution (to an Agent-Optimized Tool Catalog that Invokes actions, leading to execution on External Enterprise SaaS); and Governance and Auditing (to Lifecycle Governance and Audit Logs to Emit Telemetry). The diagram uses a hierarchical structure with rounded nodes and a navy, teal, and gray color scheme.

How agent authorization and OBO execution works

Teams either give agents their own identity with broad credentials, or they inherit the user’s full access. Both approaches create an excessive blast radius. Any failure, whether from misconfiguration, hallucinated tool calls, or adversarial input, propagates across every connected system.

The runtime must enforce the exact intersection of agent and user permissions for each action, evaluating both what the agent is allowed to do and what the user is allowed to do at execution time. This process requires managing the complete OAuth token lifecycle isolated from the language model itself.

Make sure the system supports pre- and post-call policy hooks to dynamically evaluate granular access requests at runtime.

How to evaluate agent-optimized tool reliability

Most MCP servers wrap APIs designed for structured inputs, such as recipient_user_id or file_id, not for natural language like “send this to Finance.” The root cause is that tool schemas are written for machine consumers rather than language models. Verbose schemas bloat the context window, and mismatched parameter names cause the model to hallucinate values.

Evaluate whether the runtime provides curated tools optimized for natural-language intent rather than rigid machine interfaces. The runtime execution layer must also support intelligent retries, automatic schema validation, and automated failover capabilities.

What agent lifecycle governance should include

Every tool execution requires immutable, OpenTelemetry-compatible audit logs tracing the agent action per user per connected service.

The runtime must enforce visibility filtering so that agents discover only the specific, approved tools permitted by the active human user session. It should also provide version control for safe upgrades and a shared registry with team-level access controls to prevent tool sprawl across projects.

How to assess deployment flexibility and vendor independence

Enterprise architecture demands deployment versatility. Can the runtime operate as a vendor-neutral layer that runs across any major cloud provider? Can you self-host it on a private network or securely deploy it in air-gapped environments?

Systems tied to a broader data warehouse or cloud provider ecosystem will dictate your downstream infrastructure choices and limit cross-platform integrations.

In-depth reviews of the best Natoma alternatives

Alternative 1: Arcade (independent action runtime)

Best for

Enterprise engineering teams needing a complete, vendor-neutral action runtime for multi-user production agents. Security-conscious organizations requiring per-user delegated authorization and air-gapped deployments.

Overview

Arcade.dev is an independent action runtime that unifies agent authorization, agent-optimized tools, and continuous lifecycle governance into a single execution layer.

While standalone gateways or specialized registries often focus primarily on routing traffic, Arcade handles the direct, parallelized execution of a catalog of over 8,000 agent-optimized MCP tools. It enforces access controls at the intersection of agent and user permissions, ensuring secure downstream actions.

Key differentiators vs. Natoma

Arcade is a full actions runtime, not only a routing gateway. It directly executes and manages the runtime reliability of the tools, whereas Natoma routes requests to your existing deployed servers.

It maintains platform independence through cloud-agnostic, flexible deployment models and provides an extensive, curated catalog of agent-optimized tools built for language-model intent. This often reduces parameter-hallucination issues found in standard interface wrappers.

Arcade co-authored the MCP auth specification alongside Microsoft and Okta/Auth0, and authored the URL Elicitation specification with Anthropic. This standards-level involvement shapes how the protocol itself handles identity and consent.

Pros (what you gain)

You get a centralized control plane for authorization, reliable tool execution, and continuous governance without stitching together multiple fragmented point solutions.

Arcade enforces a permission-intersection model in which every action is authorized at the strict intersection of the agent’s permissions and the specific human user’s permissions. This two-identity approach isolates credentials from the language model, preventing privilege escalation.

The runtime acquires credentials only when an action is required, requesting minimum OAuth permissions scoped to that specific tool. For irreversible actions, out-of-band approvals enforce a mandatory human approval step. You also get detailed, OpenTelemetry-compatible audit logging for every agent action executed across the runtime. Arcade holds SOC 2 Type II certification, with coverage that extends from the underlying cloud infrastructure through to every tool call an agent executes.

Cons (what you give up)

You give up the likely future advantage of Natoma being built into Snowflake Intelligence, Cortex, and Snowflake-native governance workflows. Snowflake governance policies can still be applied to workflows running through Arcade, but not natively by default. You also lose the administrative convenience of bundled procurement and unified billing if your company already purchases significant Snowflake infrastructure.

Deployment and flexibility

Arcade provides maximum environmental adaptability. It supports cloud deployments, self-hosted deployments within your own virtual private cloud, and air-gapped environments designed for regulated industries. Arcade is also agnostic to models, agent frameworks, and clients, so your team can use any combination of LLM providers and orchestration tools without runtime constraints. Post-acquisition, Natoma will likely become more opinionated toward Snowflake-supported models and tooling.

Arcade brokers authorization protocols with your existing identity providers, including Okta and Microsoft Entra, enforcing existing policies rather than requiring duplication.

Alternative 2: WorkOS (enterprise identity and SSO)

Best for

SaaS application developers whose primary roadblock is managing human user identity synchronization rather than handling agent-specific tool execution.

Overview

WorkOS is a developer platform with APIs designed to make applications enterprise-ready. It offers AuthKit, single sign-on, automated directory synchronization, and standard role-based access control.

It is a foundational identity building block, not a full AI agent platform.

Key differentiators vs. Natoma

WorkOS maintains a pure focus on identity, providing robust infrastructure for human identity management.

It delivers a great developer experience through comprehensive documentation, software development kits, and integrated drop-in interface components that accelerate time-to-market for standard authentication flows.

Pros (what you gain)

You get the fastest available path to implementing enterprise single sign-on and automated directory synchronization. WorkOS provides an off-the-shelf administrative portal that empowers enterprise buyers to manage their own user provisioning.

Cons (what you give up)

WorkOS has no native understanding of AI agents, the Model Context Protocol (MCP), or tool-calling security primitives.

Your engineering team must build the agent authorization layer from scratch, mapping WorkOS identities to individual agent scope boundaries.

Alternative 3: AWS AgentCore (AWS-native agent platform)

Best for

Large enterprises committed to Amazon Web Services as their exclusive cloud provider, seeking to build native AI agents directly within Amazon Bedrock.

Overview

AgentCore is the dedicated agent platform layer within Amazon Bedrock. It connects foundation models to enterprise systems while enforcing access policies and tracing agent workflows.

It delivers a secure, scalable environment backed by existing Amazon identity and access management infrastructure and automated reasoning primitives.

Key differentiators vs. Natoma

AgentCore offers cloud-native integration with deep, structural ties to AWS-native serverless functions, isolated virtual private clouds, and existing identity infrastructure.

It also includes built-in evaluations, providing robust native tooling for experimenting with and evaluating agent behavior under high-volume production traffic.

Pros (what you gain)

You achieve strong compliance and security inheritance if your critical workloads already operate within the Amazon ecosystem.

AgentCore provides secure connectivity to other AWS-hosted services, including storage buckets, relational databases, and internal private APIs, without routing sensitive traffic over the public internet.

Cons (what you give up)

You sacrifice vendor neutrality. AgentCore locks your agent architecture into the Amazon ecosystem and Bedrock execution paradigms.

This architecture is difficult to deploy across multi-cloud environments or hybrid on-premise setups outside the prescribed footprint. And requires a heavy engineering burden to manage the separate services.

Alternative 4: Merge (unified API for data sync)

Best for

Engineering teams building products requiring standardized data synchronization across common software categories rather than executing multi-step agent operations.

Overview

Merge is a unified API for normalized business data, providing a single integration point for hundreds of third-party tools. It’s the most narrowly scoped option in this list, but the right fit for data-heavy use cases. Their agent handler product allows large language models to query and push structured data through these normalized interfaces.

Key differentiators vs. Natoma

Merge excels at data normalization, translating disparate external interfaces into a unified data schema. It focuses on aggregating standard integration layers rather than managing protocol-level execution governance for custom-deployed servers.

Pros (what you gain)

You get access to hundreds of standard external platforms without having to read individual technical documentation. Merge also automatically handles authentication for end-user application integrations.

Cons (what you give up)

Merge offers less granular control over per-user delegated execution policies, which are required for enterprise protocol governance.

Its integrations optimize for bulk data synchronization rather than natural-language intent, increasing the risk of token bloat during complex reasoning loops.

Conclusion: Choosing the right Natoma alternative after the acquisition

The Snowflake acquisition of Natoma pushes engineering leaders to evaluate whether their agent infrastructure solves authorization, tool reliability, and governance together, while maintaining the deployment flexibility their architecture demands.

The best alternative depends on your architectural philosophy and whether you stay tethered to a Snowflake-native gateway, piece together governance tools, or adopt an independent runtime. These choices are not mutually exclusive. A two-layer approach keeps data-proximate agents operating natively inside Snowflake for internally governed analytics while deploying an external, vendor-neutral runtime such as Arcade to handle cross-cloud tool execution.

Prioritize platforms that solve agent authorization, agent-optimized tool reliability, and lifecycle governance simultaneously. Addressing only one or two of these pillars will create gaps that slow your production rollout.

Book a demo with the Arcade.dev team today to see the permission intersection model execute in a live production environment.

Frequently Asked Questions

What changed for Natoma users after the Snowflake acquisition?

Natoma’s roadmap will likely align more tightly with Snowflake’s ecosystem, which can reduce cross-cloud portability. Teams should reassess whether they want Snowflake-native governance or an independent runtime for multi-cloud agent execution.

Is Natoma still a good choice after the acquisition?

Yes, if your agents primarily run in Snowflake and you want governance tightly coupled to Snowflake RBAC and Cortex workflows. If you need multi-cloud execution or non-Snowflake toolchains, an independent layer may be a better fit.

Why choose Arcade as a Natoma alternative?

Arcade is a vendor-neutral action runtime that combines per-user delegated authorization, a catalog of over 8,000 agent-optimized tools, and lifecycle governance in a single layer. It supports cloud, VPC, and air-gapped deployments, and is agnostic to models, frameworks, and clients. For teams that need cross-cloud portability and production-grade agent infrastructure without ecosystem lock-in, Arcade covers authorization, execution, and audit without requiring additional point solutions.

What’s the difference between an MCP gateway and an action runtime?

A gateway routes requests and enforces access policies for tool calls. A runtime executes tools, enforces policy, and audits, handling reliability (retries, failover, validation), delegated auth flows, and telemetry during execution. For production multi-user deployments, a runtime is architecturally superior because it owns the full execution lifecycle rather than just the routing layer.

When should I choose an independent Natoma alternative instead of a Snowflake-native option?

Choose an independent option when you need multi-cloud portability, want to avoid data-cloud lock-in, or must support VPC, on-prem, and air-gapped deployments. An independent option also fits better when agents need to call many external SaaS tools outside Snowflake.

What is per-user delegated authorization and why does it matter for agents?

Per-user delegated authorization means each tool action is authorized using the intersection of the end user’s permissions and the agent’s allowed scope. This approach reduces the blast radius compared with shared service accounts and improves auditability for enterprise security reviews.

Which alternative is best if I already have an agent execution stack and only need governance?

A governance overlay fits best. Focus on registry, threat detection, and audit controls layered on top of your existing runtime rather than replacing execution.

Which option is best if my company is all-in on AWS?

If your agents run on Bedrock and you rely on AWS IAM and native AWS networking controls, an AWS-native agent platform is the most straightforward choice. Keep in mind that it comes with a trade-off on multi-cloud portability.

What should I look for in an enterprise action runtime evaluation?

Prioritize per-user delegated authorization, agent-optimized tool reliability, centralized audit and governance, and deployment flexibility (cloud, VPC, and air-gapped). These criteria directly determine whether your agent infrastructure can scale securely across users, tools, and environments.