Security & Privilege Disclosure
This document outlines the security model, privilege requirements, object creation behaviour, and data handling practices of the SPAN Identity Graph Snowflake Native App.
SPAN is designed to operate entirely inside the customer’s Snowflake account.
1. Security Model Overview
SPAN:
Runs fully inside Snowflake as a Native App
Does not export or transmit data externally
Does not require external network access
Operates under Snowflake RBAC
Uses the customer-selected warehouse for compute
Does not create background jobs unless explicitly configured
All processing, storage, and compute remain within the customer’s Snowflake account boundary.
2. Privileges Requested
During installation, SPAN requests only the minimum privileges required to:
Read from user-selected source tables
Create output tables in user-selected schemas
Execute identity resolution processing
Typical privileges include:
USAGE on selected warehouse
USAGE on selected database(s)
USAGE on selected schema(s)
SELECT on source tables
CREATE TABLE in output schema
SPAN does not request:
ACCOUNTADMIN
OWNERSHIP on user objects
Global read access to all databases
Network or external access privileges
Privileges are limited to only those objects explicitly selected by the user during setup.
3. Object Creation Behaviour
Upon installation, SPAN creates:
A dedicated application database
Application-managed schemas
Internal processing tables
When running the Identity Graph, SPAN creates:
A user-specified output table
Temporary processing tables (auto-managed and cleaned up)
SPAN does not:
Modify source tables
Drop or overwrite user-managed objects without explicit configuration
Create scheduled tasks or background compute jobs by default
All created objects are clearly namespaced within the SPAN application boundary or the user-selected output schema.
4. Data Handling
SPAN processes identity-related data entirely inside Snowflake.
Data Handling Characteristics:
No data leaves the Snowflake account
No external API calls are made
No persistent external storage is used
No telemetry contains customer data
Identity resolution is performed using in-database processing.
Output tables contain:
Original source columns
A generated profile_id column representing resolved entity identity
5. Compute & Resource Usage
SPAN uses only the warehouse selected by the user during execution.
Compute is consumed only while processing is running
No idle background compute occurs
No auto-scaling behaviour is introduced by SPAN
Performance depends on:
Input table size
Configured matching rules
Warehouse size
6. Network & External Access
SPAN does not require:
External network rules
External functions
Snowpark Container Services
Outbound API calls
All logic runs natively within Snowflake.
7. Role-Based Access Control (RBAC)
SPAN operates under Snowflake RBAC:
Users must have SELECT privileges on source tables
Users must have CREATE TABLE privileges in output schemas
All actions are governed by the invoking user’s role
SPAN does not elevate privileges beyond what the installing role grants.
8. Auditing & Observability
All SPAN operations are:
Executed within Snowflake
Logged in Snowflake query history
Auditable through standard Snowflake monitoring tools
No hidden operations occur outside Snowflake logging systems.
9. Uninstallation & Cleanup
Upon uninstallation:
Application-managed objects are removed
User-created output tables remain unless manually removed
No residual external dependencies remain
SPAN does not leave external artifacts.
10. Summary
SPAN Identity Graph is designed to be:
Minimal in privilege footprint
Transparent in object creation
Predictable in compute behaviour
Fully contained within the Snowflake security boundary
Identity resolution becomes a governed, in-warehouse data primitive without expanding the customer’s trust boundary.
Last updated