Security Controls

Metatate's security posture is built on three pillars: network isolation, container hardening, and data access minimization. Running entirely within Snowflake's infrastructure eliminates most of the attack surface associated with traditional SaaS applications.

Network Security

Ingress

• All user traffic enters through Snowflake's SPCS ingress endpoints
• SPCS ingress enforces HTTPS with TLS 1.2+ (managed by Snowflake, not the application)
• Only authenticated Snowflake users can reach the application endpoints
• The nginx router (port 8000) is the single entry point within the container service

Egress

• No outbound network access — the application has no External Access Integrations (EAIs)
• No connections to external APIs, services, or endpoints
• AI processing uses SNOWFLAKE.CORTEX.COMPLETE(), which is an internal Snowflake function
• No telemetry, analytics, or tracking data is sent externally

Network Diagram

Container Security

Non-Root Execution

All application containers run as non-root users. The container images are configured with:

• Non-privileged user for the application process
• Read-only filesystem where possible
• No sudo or privilege escalation tools installed

Minimal Images

Container images are built with minimal base images to reduce the attack surface:

• Only runtime dependencies are included (no build tools, compilers, or package managers in production images)
• Images are rebuilt from pinned base versions
• No unnecessary system packages

No Hardcoded Secrets

• No API keys, passwords, or tokens in container images or environment variables
• Database connections use the SPCS service-to-Snowflake connection mechanism (no credential management)
• Cortex AI access uses the application's granted privileges, not stored credentials
• Configuration is read from Snowflake tables (tenant_config), not from files or environment variables

Image Supply Chain

• Container images are stored in Snowflake image repositories
• Images are versioned and tagged to match application versions
• The consumer receives images through the Snowflake Native Application distribution mechanism

Data Security

Minimal Data Access

Principle	Implementation
SELECT only	The app can only read consumer tables, never write to them
Consumer-controlled scope	Only tables explicitly granted via DATABASE_CATALOG are accessible
No bulk data copy	The app reads metadata (column names, types); row data is not copied or cached
No data export	No mechanism to export consumer data outside the application

Tenant Isolation

Each application installation is isolated within its own Snowflake account:

• Application schemas are private to the installation
• Governance tables contain only data derived from the consumer's policies
• No cross-tenant data sharing or aggregation
• The provider cannot access the consumer's application data

AI Data Handling

• Cortex AI prompts contain metadata only (table names, column names, data types, policy text)
• No consumer row data is included in AI prompts
• AI responses are used for suggestions and analysis, not stored as governance state
• All AI processing occurs within the Snowflake infrastructure (no external AI providers)

See Privacy & Data Handling for a complete data inventory.

TLS and Encryption

Layer	Encryption	Managed By
User to SPCS ingress	TLS 1.2+ (HTTPS)	Snowflake
SPCS ingress to containers	Internal SPCS networking	Snowflake
Container to Snowflake DB	Internal connection	Snowflake
Data at rest	Snowflake's encryption at rest	Snowflake
Governance tables	Snowflake's encryption at rest	Snowflake

The application does not manage TLS certificates. Snowflake handles all encryption for data in transit and at rest.

Audit and Monitoring

Application-Level Logging

• activity_log table records user actions (policy edits, deployments, configuration changes)
• governance_decision_log records every authorization decision with full evidence chain
• governance_snapshots records point-in-time governance state after each materialization
• Container logs are available through SPCS standard log access

Snowflake-Level Auditing

Standard Snowflake auditing mechanisms apply:

• SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY captures all queries executed by the application
• SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY captures authentication events
• SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY captures data access patterns

The consumer has full access to these audit logs and can monitor the application's behavior using their existing Snowflake monitoring tools.

Summary of Security Properties

Property	Status
External network access	None (no EAIs)
Credential storage	None
Consumer data egress	None
Container privilege	Non-root
TLS termination	Managed by Snowflake
Data encryption at rest	Managed by Snowflake
Cross-tenant access	Not possible
Write access to consumer tables	Not possible (SELECT only)
Audit trail	Application logs + Snowflake native auditing