Built so your data never has to trust us

In your warehouse — that is the rule the product is built around. Profiling and detection compile to SQL that executes inside your database (Postgres, MySQL, SQL Server, Snowflake, or BigQuery). Your tables are never copied to our systems: the counting happens where the data already is, and only statistics come back.

What our database holds is the working set: schema metadata, profiling aggregates, quality rules and scores, the issues we flag, the fixes we propose, and the approval trail. We hold the findings — never a copy of your tables.

The one exception is a CSV you upload directly. That file lives in our storage, encrypted, and is deleted automatically when its report expires (see retention below).

Three tiers, from never to bounded:

• Never leaves: your tables. Bulk reads don’t exist as a code path — profiling is push-down SQL, and even writeback bookkeeping computes old values server-side so they never round-trip through us.
• Passes through, bounded: the specific values needed to find and fix problems — up to 50 top values per column, up to 20 sample rows per detected issue, and a handful of similar records as evidence for each proposed fix. Every one of those bounds is a constant in the code, not a policy.
• Stored: the flagged values and proposed fixes your stewards review, with rationale and provenance — encrypted at rest, retention-limited, and covered by the audit trail.

No — and not as a promise, as an architecture. When your stewards approve fixes, we record them into a _neosky area we create beside your data (a schema, database, or dataset depending on the engine): old value, new value, who approved it, when. Your tables are untouched.

Then we generate a plain SQL script that your team reviews and runs to apply the fixes. It is transactional, safe to re-run, and marks each fix as applied in the same transaction — the ledger and reality cannot disagree. The fixes table stays in your database as a permanent audit artifact your DBA can query without ever logging in to Data Stew.

The write access we ask for is scoped to that one _neosky area, and revocable.

Exactly two: Anthropic, under a Business Associate Agreement, and Mistral, under zero-data-retention terms. Cell-level values can reach no other provider — the allowlist is enforced by a compliance router in the code, which refuses to construct a non-compliant call. It is a type-level and runtime guard, not a policy document.

Your data is not used to train models. Every AI-generated suggestion records which model produced it and under which prompt version — provenance is a required field, not an option.

Columns you mark as sensitive are masked before any prompt is assembled — the value is replaced with REDACTED and the original never reaches a model. Masked columns are also blocked from AI fix tasks entirely: we won’t propose values for a column you’ve told us not to look at.

Pattern-based redaction (emails, phone numbers, and similar) applies to the evidence rows that accompany suggestions, so context records are scrubbed too.

Read-only, least-privilege, and written out as SQL you can inspect. The connect screen generates the exact GRANT statements for your engine — a role that can SELECT and nothing else. You can grant narrower (table by table) and the product works within whatever you granted.

Writeback is a separate, optional, second grant — scoped to the _neosky area only — so you can run the entire analysis before deciding whether we may record fixes in your systems at all. Revoking it later doesn’t disturb profiling.

Envelope-encrypted with AES-256-GCM: each credential is sealed with its own data key, which is itself sealed by a master key, bound to the owning record so a payload lifted from one row cannot be decrypted as another’s. There is deliberately no fallback key — if the master key is absent, the system fails closed rather than encrypting weakly.

Only the secret is encrypted; hostnames and usernames stay readable so the person maintaining a connection can see where it points. Credentials are decrypted per job, used, and never logged or returned to a browser. Snowflake supports key-pair authentication as the production path.

Uploaded files carry a TTL (30 days by default). A daily job enforces it: the file, its generated outputs, and the derived issues and suggestions in our database are all deleted together, and the deletion itself is written to the audit trail — retention that leaves no trace of having run is indistinguishable from retention that never ran.

Expired share links stop resolving. Warehouse-connected datasets hold no copy of your data to delete — disconnecting a source removes the metadata and findings derived from it.

Four roles — Owner, Admin, Steward, Viewer — enforced as capabilities on every route, not as page-hiding. Stewards can be scoped to domains, so the person who owns customer data reviews customer data and nothing else. Approving, applying, connecting sources, and managing billing are each separately gated.

Underneath, every tenant table carries the workspace id and our own database has row-level security enabled as defense-in-depth.

Append-only, by design and by schema: there is no code path that updates or deletes an audit event — including for us. Every profile, suggestion, approval, apply, export, and retention deletion is recorded with who, what, and when, and the whole trail exports to CSV in one click for your auditors.

Separately, applied fixes live in the _neosky tables in your own warehouse — an audit artifact you hold, not one you have to trust us to keep.

Straight answers, because this page is only useful if you can trust the rest of it:

• SOC 2: not yet certified. The controls this page describes are built; the formal audit is on the roadmap.
• SSO/SAML: enterprise roadmap. Today: email-based auth via Supabase.
• EU data residency and BYOK: designed for (the hooks exist in the architecture) and part of our enterprise plan — talk to us about timelines before relying on them.

If your security team has a questionnaire, send it — walking reviewers through the architecture is something we do gladly, including the code that enforces the claims above.