Data Boundary & Compliance

EntryLayer is closer to an operational layer inside Snowflake than a conventional SaaS application that first pulls data into a vendor-hosted database. Source records remain in customer-owned Snowflake objects, while EntryLayer state is stored in Snowflake Hybrid Tables inside the installed Native App namespace.

When this matters

Use this page when a security, governance, procurement, or data platform team asks:

where source records live
where EntryLayer stores application state
whether the package requires provider-owned network egress
how Snowflake row access and masking policies continue to apply
what telemetry or billing data can leave the account

What does not leave the account

Data class	Normal product posture
Source row values	Stay in customer-owned Snowflake objects unless a documented user workflow opens or materializes a row inside the app.
App-managed submissions	Stored in Snowflake Hybrid Tables in the customer Snowflake account.
Project metadata and form design	Stored in Hybrid Tables in the installed app namespace.
Workflow and audit history	Stored in Hybrid Tables in the installed app namespace.
Source discovery results	Metadata-only results used for project setup and form design.

What can leave the account

Surface	Boundary
Marketplace billing events	Seat-oriented billing events; no usernames, emails, table names, row values, or business payloads.
Optional Snowflake event sharing	Optional, not mandatory, and not required for normal app use.
Customer support artifacts	Only what the customer intentionally shares with support.

EntryLayer does not depend on shipping customer records to vendor-hosted analytics systems for normal product use.

Package guardrails

Guardrail	Current posture
Provider-owned external access	The current package does not request an `EXTERNAL_ACCESS_INTEGRATION` or provider-owned `NETWORK_RULE`.
App state storage	Stored in Snowflake Hybrid Tables in the customer Snowflake account.
External database tier	No PostgreSQL sidecar is part of the current package.
Event sharing	Optional rather than mandatory.
Billing telemetry	Scoped to seat-oriented billing classes.
AI path	Uses Snowflake Cortex for supported AI-assisted features.

Privilege minimization

The application requests only the privileges it needs to run:

Privilege or role	Purpose
`CREATE COMPUTE POOL`	Run the Snowpark Container Services containers.
`CREATE WAREHOUSE`	Support Cortex-backed features and app-managed warehouse work.
`BIND SERVICE ENDPOINT`	Expose the web endpoint for the installed Native App.
`SNOWFLAKE.CORTEX_USER` database role	Enable Snowflake Cortex features for the installed application.

Customer source access is not automatic. The customer grants caller rights on the specific source databases and schemas EntryLayer should describe or use.

Caller Rights enforcement

When EntryLayer uses Restricted Caller Rights, Snowflake continues enforcing access in the context of the signed-in user.

Snowflake control	Effect in source-connected EntryLayer workflows
Object grants	Determine which databases, schemas, tables, views, or semantic views the app can use.
Row access policies	Restrict which source rows a user can see.
Masking policies	Restrict which source values are visible.
Imported/shared database posture	Some shared or imported sources can be unavailable depending on caller-rights support and grants.

What this means

This design does mean:

EntryLayer avoids routine vendor-side data hosting for app use.
Snowflake remains the main control plane for source-data governance.
Application state remains in the customer’s Snowflake account.
AI-assisted features use Snowflake Cortex rather than a provider-owned external LLM endpoint in the current package.

It does not mean:

the app has no privileges
every user can browse every source object
an admin seat automatically grants record visibility
every Snowflake source type behaves identically under Restricted Caller Rights