The runtime stays in the customer account
EntryLayer runs as a Snowflake Native App on Snowpark Container Services, so the application runtime is installed in the customer account.
Security and trust
Security works best when the app stays close to the data.
EntryLayer is designed for security reviewers who need concrete answers: where the app runs, where state lives, how source reads are authorized, and what leaves the account. It is not a second warehouse or a vendor-hosted source-data store. It is an operator-facing app installed inside Snowflake.
Security facts
The boundary should be easy to inspect.
Before a platform team reads every architecture detail, they need quick answers about runtime, storage, source access, telemetry, and what the provider can see.
- Runs where?
- Customer Snowflake account as a Native App on Snowpark Container Services.
- Provider stores source data?
- No provider-hosted source-data copy is required for normal product use.
- External analytics?
- No external analytics dependency for product behavior.
- Source reads?
- Caller-backed reads for supported consumer-owned sources.
- App state?
- Snowflake Hybrid Tables in the customer account.
- Telemetry?
- Optional event sharing and billing events scoped away from business payloads.
Review packet
Five things to verify before installation.
The page below is organized around the questions a Snowflake security or platform reviewer will usually ask first. Use the links as a short evaluation path, then go deeper in the docs.
Architecture diagram
Public reviewer URL for the Native App security questionnaire.
Incident response SLAs
Published response targets, intake, escalation, and notification practices.
Vendor security program
Secure development, vulnerability management, release review, and vendor controls.
1. Runtime and storage
Where the app runs and where application state lives.
2. Source data access
How caller-backed reads preserve Snowflake policy where supported.
3. Workflow audit trail
What EntryLayer records when people edit, review, approve, or access work.
4. Telemetry and billing
What can leave the account, and what should not be part of event payloads.
5. Admin visibility
How admins inspect setup, member roles, and access diagnostics.
Runtime boundary
The product is built to stay in the customer's Snowflake account.
EntryLayer is not positioned as a disconnected data-entry SaaS that pulls source data into a provider-hosted system. The Native App deployment keeps the interface runtime, workflow state, and admin surfaces aligned to the Snowflake boundary.
- Application state is stored in Snowflake Hybrid Tables.
- Normal product use does not require a vendor-hosted application database.
- The runtime story is concrete enough for security teams to inspect and challenge.
Organization settings and diagnostics
Virtual submissions from Snowflake
Inherited access controls
The signed-in user's Snowflake access remains the source-read path where supported.
EntryLayer is designed around caller-rights access for consumer-owned Snowflake sources. When a user opens source-connected records, the product should not bypass Snowflake policy with a broad shared credential.
- Masking policies continue to shape source values rendered to the user.
- Row access policies continue to determine which source rows appear.
- Shared and imported databases are documented separately because caller grants do not behave the same way there.
Auditable workflow state
Workflow and submission history are customer-inspectable records.
Security is not just about who can read a value. It is also about whether the team can reconstruct what happened. EntryLayer records approvals, edits, access activity, and workflow transitions so operational work can be reviewed like the rest of the platform.
- Submission history captures how a record changed over time.
- Workflow actions show who submitted, approved, rejected, or reopened work.
- Access logs make record-level activity visible instead of invisible.
Submission workflow and audit context
What the security story actually is
Security reviewers should be able to get concrete answers quickly.
The strongest part of the EntryLayer posture is that the trust model is legible. A reviewer should be able to inspect where it runs, how it reads data, what gets logged, what billing can include, and what admins can diagnose without relying on broad assurances.
Source reads use the signed-in user where supported
For supported consumer-owned sources, caller-backed reads keep row access, masking, and object grants with Snowflake.
Project and review state stays in Hybrid Tables
Projects, submissions, memberships, review actions, and access activity live in Snowflake Hybrid Tables.
Admins can inspect setup without vendor logs
Workspace admins can see access diagnostics, member roles, and Snowflake setup guidance directly in the product.
Zero-access posture
Normal product use should not create a provider-side copy of customer data.
EntryLayer's current trust posture is built around Snowflake-owned runtime, Snowflake-owned storage, optional event sharing, and limited billing events that do not need business payloads.
Runs inside the customer account
The Native App runs on Snowpark Container Services, with app state in Snowflake Hybrid Tables.
Caller-rights source reads
For supported consumer-owned data, source reads use the signed-in user context so Snowflake policies remain in force.
No external analytics dependency
Normal product use does not require shipping customer records to vendor analytics or a hosted application database.
Optional event sharing
The product posture is designed so telemetry and billing do not become a side channel for business data.
Evaluation checklist
Questions a security team should be able to answer.
- Where does the interface runtime live relative to customer data?
- Which data is stored in Hybrid Tables, and which data remains in source objects?
- Where are caller-rights reads supported, and where do shared or imported databases differ?
- Which telemetry and billing events can leave the customer account?
- How can admins inspect access state without relying on vendor logs?
Admin visibility
Admins can see setup and access state inside the product.
The product includes guided Snowflake setup, member-role management, and live access diagnostics so teams do not have to treat operational security as a hidden backend concern. That makes rollout easier and makes support conversations more concrete.
Live diagnostics
Check session, warehouse, and source access directly from the admin UI.
Guided setup
Use in-product guidance and copyable SQL to complete Snowflake access setup.
Technical review
Read the architecture and data-boundary docs before you decide.
The documentation covers runtime architecture, permissions, virtual submissions, and the zero-egress posture so your security and platform teams can evaluate the product directly.