Skip to main content
Kumo is delivered as a Snowflake Native App running on Snowpark Container Services (SPCS). Kumo’s training jobs, model artifacts, and predictions all run as containers inside your Snowflake account, using Snowflake’s containerized compute. All data used for training, as well as the resulting model outputs, remain fully within your locked-down Snowflake environment. This page is for IT and security teams who want a concise view of how Kumo behaves from a data and security perspective.

​
1. Execution model and security boundary

Kumo runs as a set of SPCS services deployed into your Snowflake account:
  • Containers are scheduled, isolated, and monitored by Snowflake’s SPCS control plane, as described in the SPCS service documentation.
  • Data access occurs only over Snowflake’s native interfaces (SQL, Snowpark, and the SPCS service APIs documented in the SPCS specification reference).
From an IT perspective, Kumo behaves like another governed workload that runs within the Snowflake account boundary you already administer. There is no separate Kumo-managed compute environment processing your Snowflake data. High Level Architecture

​
2. Data access and isolation

With the Snowflake Native App deployment, there is a clear separation between Kumo (the company) and Kumo (the app running in your account):
  • Kumo (the company) never has direct access to your data. Training data, intermediate datasets, model artifacts, and prediction tables are stored only in your Snowflake account.
  • Kumo (the app) is a Snowflake application object that can process data only for the objects it is explicitly granted, using Snowflake’s standard role-based model as described in the Snowflake access control overview.
During a proof-of-concept, many customers choose to onboard a Kumo data scientist as a vendor/contractor user in their own Snowflake account to co-build. In that model, the Kumo data scientist works under a Snowflake user and role that you control, with access limited to the specific objects and environments you designate. All Kumo outputs—predictions, embeddings, and supporting tables—are written as Snowflake objects in your account and governed by your existing policies (for example, row access policies and column-level masking).

​
3. Data protection and limited service traffic

Kumo’s design is to keep customer data in Snowflake:
  • No training data or prediction results leave your Snowflake account. Model training and scoring happen inside SPCS containers, against data stored in your Snowflake databases.
  • A small amount of non-data service metadata (for example, workflow orchestration information) is sent to Temporal Cloud to coordinate long-running workflows. This metadata does not include the tables being trained on or the model outputs.
  • Container logs are written back into your Snowflake account (for example, into an event table or logging schema). If debugging is required, you can temporarily allow Snowflake or Kumo support personnel to see only those logs, rather than granting access to your underlying data.
The net effect is that customer data remains in Snowflake, while only minimal operational signals leave the environment, and even those are under your control.

​
4. App approval and security review

Kumo is distributed through Snowflake’s Native App framework and has undergone Snowflake’s security review for apps with containers: For your internal approval process, this means the Kumo app has already been carefully examined by Snowflake’s security team, and you can anchor your review on Snowflake’s documented controls plus your own data and access policies.

​
5. What your team configures

Most of the work for your IT and security teams is simply following the standard installation steps and choosing the right roles and objects:
  • Install the app from Snowflake Marketplace and accept the required terms (Snowflake Marketplace consumer terms, third-party Python package terms, etc.).
  • Run the provided setup script to create the databases, roles, and network rules used by Kumo in your account.
  • Start the Kumo app and sign in using Snowflake credentials, as described in the Kumo installation guide:
    Installing Kumo on SPCS.
After these steps, Kumo runs as a governed application inside your Snowflake environment, using the roles, policies, and logging setup you already rely on.