Native App Security Model

The Snowflake Native App security model has several layers. EntryLayer uses those layers to separate app installation, SQL administration, source access, and project-level record permissions.

When this matters

Use this page when you need to understand:

why SQL procedures are in the API schema instead of exposing internal tables directly
why the SQL API is granted only to ENTRYLAYER_ADMIN
how Restricted Caller Rights differs from project access
which app-level privileges the Marketplace package asks customers to approve

Application roles

Application role	Purpose
`ENTRYLAYER_ADMIN`	Admin-only SQL API, app administration, seat management, project configuration, and inspection views.
`ENTRYLAYER_USER`	Runtime app access for ordinary app users where explicitly granted by the app package.

The customer grants application roles to their own Snowflake account roles:

GRANT APPLICATION ROLE ENTRYLAYER.ENTRYLAYER_ADMIN TO ROLE MY_ADMIN_ROLE;

Replace ENTRYLAYER with the installed app name if it is different.

SQL API rights model

Native App stored procedures that operate only on app-owned objects run with owner rights. Source-facing procedures run with Restricted Caller Rights so Snowflake can enforce the signed-in user’s source-object grants, then delegate app-owned state changes to owner-rights helpers.

Pattern	Why EntryLayer uses it
`API` schema procedures	Public, documented SQL interface for admins.
Owner-rights execution	Lets non-source procedures safely read and write app-owned state.
Restricted Caller Rights execution	Lets source metadata, grid, virtual-row, and materialization procedures use customer-approved caller grants.
Consistent response envelope	Lets Cortex and SQL clients check `status`, `data`, `message`, and `code`.
`APP_PUBLIC` views	Admin-readable inspection surfaces without exposing internal tables directly.

Restricted Caller Rights

Restricted Caller Rights let EntryLayer use customer-owned Snowflake objects with the signed-in user’s access context where supported. This matters for source-connected projects because the app should not silently bypass existing Snowflake governance.

Signed-in Snowflake user
  -> customer account role
  -> caller-rights grants to installed application
  -> EntryLayer source metadata/read path
  -> Snowflake row access and masking policies still apply

Restricted Caller Rights are separate from EntryLayer project permissions. A user can have project access but still be blocked by Snowflake source grants, row access policies, or masking policies.

Manifest privilege summary

The current Native App package requests only the account-level privileges needed to run the app:

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

The current package does not require a provider-owned external access integration or network rule for normal product use.

Admin-only SQL surface

EntryLayer keeps the SQL API intentionally narrow:

SQL API procedures are granted to ENTRYLAYER_ADMIN.
Private helper procedures and implementation objects stay out of public docs.
Source discovery procedures are metadata-first and documented with zero-access guardrails.
Submission mutation through SQL is available only where explicitly documented.