Security
How we handle your data
MortarIQ connects to your data warehouse with read-only access. Here is exactly what we access, what we store, and how we protect it.
Don't want to connect anything yet?
Run the same scan locally with the CLI: credentials and the connection never leave your machine, it works with the read-only role you already have, and --html writes a shareable report. Nothing is sent anywhere unless you say so.
npm install -g @mortariq/cli mortariq scan --platform snowflake ... --html report.html
Full instructions in the CLI guide.
What we access
We query
- INFORMATION_SCHEMA tables, columns, and constraints
- Table/column descriptions and comments
- Policy tags and classification labels
- Partitioning and clustering configuration
- Table modification timestamps
- Tag references and governance metadata
We never access
- Row-level data (we never SELECT from your tables)
- Query results or execution history
- Your actual data values or records
- Other credentials stored in your warehouse
- Billing or account management APIs
See every query we run, exactly →: the complete read-only SQL, generated from our connector source.
Credentials
Storage
Saved connections are encrypted at rest (AES-256-GCM) with the encryption key managed outside the database, so a database compromise alone cannot reveal them. If you don't save a connection, credentials are used only for that assessment and never stored. They are never logged or exposed to our team.
Scope
We require only metadata-reading permissions. BigQuery: metadataViewer + jobUser. Snowflake: OBJECT_VIEWER + GOVERNANCE_VIEWER. Databricks: USE CATALOG + BROWSE. PostgreSQL/Redshift: a read-only user (USAGE; SELECT on Redshift for catalog visibility; we still never read rows). Fabric: a workspace Viewer service principal.
Deletion
Delete your connection from Settings at any time. Credentials are permanently removed, not soft-deleted.
Impact on your warehouse
Light by design
An assessment runs a small number of read-only INFORMATION_SCHEMA queries, sequentially and never in parallel, so we never flood your warehouse with concurrent load. There are no automatic retries, so a transient error can't amplify into repeated work.
Identifiable
Every query we run is tagged so your DBA can recognize it in your query history: a Snowflake QUERY_TAG, a BigQuery job label, a Databricks SQL comment, a PostgreSQL/Redshift application_name, or a Fabric session app name, each carrying a per-scan id you can trace back to a specific assessment.
Bounded
Each statement carries a server-side timeout (and we cancel one we've given up on), so a query can never run away and consume your compute after we've stopped waiting for it.
Warehouse wake
If your warehouse is suspended/auto-stopped, connecting will briefly resume it, which your provider bills as usual (e.g. a Snowflake minimum, a Databricks cold-start). We keep that work minimal and never hold the warehouse open beyond the queries.
Where your metadata goes
We treat your metadata as sensitive in its own right. Table names, column names, and a PII inventory are confidential under most data-loss-prevention policies, so here is the complete path they travel:
1. Your warehouse to MortarIQ
Read-only catalog queries over TLS (the exact SQL is published below). Results are processed and stored on our infrastructure in the United States (application on Railway, database on Supabase, US East). Nothing else touches your warehouse.
2. MortarIQ to our AI provider (Anthropic)
To generate the fix plan we send assessment results: scores, requirement outcomes, and the metadata-derived diagnostics they cite, which can include database, schema, table, and column names. That specificity is what makes recommendations actionable. We never send data values or credentials. Anthropic does not train on API inputs and retains them only briefly for abuse monitoring.
3. Nowhere else
No data brokers, no advertising systems, no model training. The full subprocessor list (hosting, auth, billing, monitoring, email) with what each one sees is in our privacy policy, and our DPA covers transfers with Standard Contractual Clauses where required.
Retention follows your plan (details in the privacy policy); deleting a connection permanently removes its credentials, and account deletion purges your data within 30 days.
Data handling
Tenant isolation
Every query for your data is scoped to your organization through a single set of access functions, and automated tests fail the build if any of them stops enforcing that scope. We're moving this enforcement into the database itself (Postgres row-level security) as defense-in-depth.
No training
Your metadata, assessment results, and credentials are never used to train models, generate benchmarks, or improve the product for other customers.
Questions?
Email support@intellibricks.app for security assessments or compliance documentation.