Your data stays in your warehouse.
dvt is built so the sensitive parts of your data never have to live in our infrastructure. We push queries down to your warehouse, return only the rows needed to render a chart, and store dashboard specs — never your data rows or values.
How data flows
A dashboard is a JSON spec. To render it, dvt compiles SQL and sends it to your warehouse — the query runs there, on your compute, and only the result rows come back.
Your warehouse's data rows and values never land in dvt's metadata database.
What we store — and what we don't
What dvt stores
- Dashboard specs (the JSON definition of your charts and layout)
- Account metadata — users, organizations, roles, audit logs
- Warehouse connection settings, with credentials encrypted
- Trial CSV uploads — stored as Parquet in encrypted, organization-scoped object storage so your trial dashboards keep working
- Warehouse catalog structure — object and column names, kinds, data types, nullability, and comments read from your warehouse, plus a column ordering dvt assigns itself, only for a connection an org admin has explicitly opted into catalog sync (off by default)
What dvt does not store
- Your warehouse's data rows, cell values, or query results — queries run in place; only the result rows dvt needs pass through memory per request, then are discarded
- CSV uploads on a paid plan — durable upload storage is available only during a trial, not on paid workspaces
- Warehouse credentials in plaintext — we only ever hold ciphertext
To be precise: query results pass through dvt's systems in memory to render your charts and are not persisted to our database. Three things can land durably in our infrastructure, and each is bounded and disclosed here rather than glossed over. First, if you upload a CSV during a trial, dvt stores it as Parquet in encrypted object storage (Cloudflare R2) so your trial dashboards keep working — every object is scoped to your organization by key, sits in a private bucket with no public access, and is reachable only through a short-lived, server-minted signed URL; one organization can never read another's objects, and an automated retention job deletes them after your trial ends. This capability exists only during a trial — on a paid plan, durable upload storage isn't available, and your data stays in your own warehouse. Second, an image export (PNG or PDF) is stored encrypted, scoped to your organization, and automatically deleted within 30 days. A data export (CSV or XLSX) is streamed to you on request and audited, but never stored by dvt. Third, for a connection where an org admin has opted into catalog sync — off by default, per connection — dvt stores names/types/comments only, never data rows or values: the object and column names, kinds, data types, nullability, and comments read from your warehouse's own catalog, plus a column ordering dvt assigns itself (not read from the warehouse — the engine's response has no warehouse-native ordinal). Comments are stored as written: a warehouse column comment is free text your team wrote, so it's stored verbatim, not extracted or summarized. Catalog sync never includes data rows, sample values, statistics, DDL text (DEFAULT, constraint, or view definitions), or query results. The synced structure is scoped to your organization — visible to any org member with catalog access, which can be broader than what a finer-grained per-user warehouse grant would show them live — and turning sync back off deletes it immediately, not on a delayed cleanup cycle. We'd rather tell you exactly where your data goes than make a claim we can't stand behind.
Retention: we don't keep personal data indefinitely. When a user or organization leaves, a daily job scrubs their personal details — email, name, avatar — within 90 days, keeping only de-identified records so historical usage stays intact. Image exports are deleted within 30 days. Trial CSV uploads are deleted by an automated retention job after your trial ends. Warehouse catalog structure is deleted immediately when catalog sync is turned off for a connection, or when the connection itself is deleted — not held on any separate retention schedule.
Encryption
In transit
All connections to the dvt app and API use TLS 1.2 or higher. dvt connects to your warehouse over an encrypted channel; every major managed warehouse requires TLS by default.
At rest
Our database provider encrypts all metadata at rest with AES-256. Warehouse credentials get a second layer we control: each is sealed with its own data key (envelope encryption), and our database stores only the ciphertext.
Credential isolation
The root key that unwraps credentials lives only in the query engine — never in the API tier and never in the database. A single component can decrypt, for one query, and the plaintext is discarded.
Access & tenant isolation
Role-based access
Capability-based roles (viewer, editor, admin, owner) gate every action. API keys carry their own scopes, narrowed to the minimum a workload needs. See the full roles & permissions matrix.
Organization scoping
Every record is scoped to an organization and checked on every read and write. One organization cannot see another's specs, connections, or data.
Audit logging
Sensitive actions — including every credential decryption — are recorded to an append-only audit log with the actor, action, and resource.
Managed authentication
Sign-in is handled by WorkOS. Sessions use sealed, http-only cookies; the session token is never exposed to JavaScript. API keys are shown once at creation and aren't recoverable afterward.
Continuous security testing
Security isn't a once-a-year checkbox for us. Every change to dvt runs through a battery of automated security tests in CI, and each run leaves a timestamped, retained artifact — the evidence trail behind our readiness posture.
Static analysis (SAST)
Static analyzers — gosec, bandit, and Semgrep — scan our Go, Python, and TypeScript on every pull request to catch code-level vulnerabilities before they merge.
Dependency scanning (SCA)
Dependencies are continuously scanned for known CVEs, with automated upgrade PRs, and CI actions are pinned to commit SHAs to harden the supply chain.
Secret scanning
Secrets are blocked before they can be pushed and scanned across our full history, with platform push protection enforced.
Dynamic testing (DAST)
A layered pyramid runs against the live app: contract fuzzing against our OpenAPI schema, passive and active web-app scanning, and live-surface vulnerability templates.
Tenant-isolation tests
Automated checks assert one organization cannot reach another's objects, and server-side request forgery is blocked by an enforced denylist.
Change control
Every change is peer-reviewed against a required gate before merge, and database migrations are applied through CI — never by hand.
The honest limit: automated testing is broad and continuous, but it doesn't replace a third-party penetration test. We don't have one under contract yet, and we'll commission one when an enterprise engagement calls for it. We'd rather name the gap than imply coverage we don't have.
AI authoring & your data
dvt is AI-native: humans and AI agents author the same dashboard spec, over the same API and MCP surface. That raises a fair question — what does the AI see?
- The AI is your agent, not ours. dvt exposes a scoped, audited MCP and REST surface that an AI agent you run connects to. dvt does not send your data to a model provider — there is no dvt-operated model that ingests your prompts or warehouse data.
- AI agents author specs — the JSON definition of a dashboard. They operate over the same scoped, audited API a person uses, with API keys scoped to the minimum the workload needs — an agent cannot exceed the capabilities of the user who authorized it.
- Agent actions are recorded in the audit log, attributed as agent activity.
- The same data-flow rules apply: rendering an AI-authored dashboard pushes SQL to your warehouse like any other.
Reporting a vulnerability
If you believe you've found a security issue, we want to hear from you. Email [email protected] with the details and steps to reproduce. We'll acknowledge your report and keep you updated as we investigate.
We support good-faith research: if you make a genuine effort to avoid privacy violations, data destruction, and service disruption while investigating, we will not pursue legal action over it. Please give us a reasonable chance to fix an issue before disclosing it publicly. Our machine-readable policy is published at /.well-known/security.txt.
Compliance & SOC 2 posture
We're an early-stage company, and we'd rather be straight with you than imply a badge we don't hold. Our stance is continuous readiness now, formal audit when a deal calls for it.
- dvt is not yet SOC 2 audited. We hold continuous, evidence-backed readiness: our controls map to the SOC 2 Common Criteria, and the timestamped artifacts our CI produces form the evidence trail an audit is built from. We'll pursue a formal Type II audit when an enterprise engagement calls for it.
- Architecture is our strongest control. Because your data rows and values stay in your warehouse, the scope of what we hold is small by design — the most direct answer to the hardest question on any security questionnaire.
- We keep a current subprocessor list and a trust center with the artifacts a security review needs.
Running a security review or need a DPA? Email [email protected] and we'll help.