dvt, completely sealed inside your Snowflake account.
dvt ships as a Snowflake Native App. You install it from a listing into your own account, where it runs on Snowpark Container Services, on your compute, behind Snowflake's own authentication. It queries your data as the person using it, keeps its dashboards inside the app, and has no route back to us.
We set it up with you directly. If you would rather look before talking to anyone, the browser builder needs no signup.
- Deployment
- Native App on Snowpark Container Services, in your account
- Compute
- Your warehouses
- Agent access
- Claude and Cortex, over MCP
- Data it can reach on its own
- None
- Egress from your account
- None
- External access integrations
- None
Your data never leaves your account.
This is the reason the app exists in this shape. There is no connection to configure, no credential to hand over, no external access integration to approve, and no egress to audit, because nothing leaves your account. Your rows are queried and drawn where they already sit, and dvt operates no service that could receive them.
Nothing leaves
As shipped, nothing is sent to dvt. The app declares no telemetry events, so no usage data and no error reports reach us. Account-level event sharing is a switch you own, off unless you turn it on.
It holds no data grants
The app requests no grants on your data. Dashboard queries run with the caller's rights, under the role of the person who asked. Optional features you switch on, like Sheet writeback, ask for their own grant.
Visible in your query history
Dashboard queries land in your own query history attributed to the person who ran them, not to a shared service account. You see what ran, by whom, on which warehouse.
Uninstall is the off switch
Uninstall removes the app and the objects it owns. If you turned on Sheet writeback, clear its tables first, and Snowflake keeps one final volume snapshot on the way out. There is no account on our side to close and no data of yours to ask back.
Most of your security questionnaire does not apply.
A vendor security review is mostly a set of questions about what happens to your data once it leaves. Install the tool into your own account and those questions have no subject. Here is the standard list, and what it collapses to.
Where does the vendor store and process our data?
NowhereWhich subprocessors will our data pass through?
NoneWhat credentials or service accounts must we issue, and how are they rotated?
No dvt credentialWhat can the vendor see if the vendor is breached?
Nothing of yoursWhat outbound egress must we allow for it to work?
NoneWhich external access integrations does it ask us to approve?
NoneWhich of our data does the application itself hold access to?
No data grantsHow do we revoke access, and how quickly does it take effect?
Uninstall itWhat remains is the review any Snowflake Native App gets: which privileges it requests, and which warehouse it may use. Your admin reads both in Snowsight before accepting, and every query the app runs shows up in your own account usage views afterward. You do not have to take our word for any of it, which is the point.
What is in the container, and who checked it.
The other half of a container review is the software itself. We do not claim the images carry no vulnerabilities, because nobody can. We claim that nothing with an available fix ships unnamed: either the gate blocks it, or it is listed by CVE with the reason no stable release carries the fix yet. Scan the published image yourself and check.
The app runs three images in your account: the interface and API, the query engine, and its own metadata store. No third-party service sits in the path.
Every release is built from base images pulled immediately beforehand, because staleness at scan time is what actually determines whether a known fix is already in the image.
Trivy and Grype both gate the release, because each is blind to things the other catches. Trivy fails the build on any fixable finding; Grype fails on fixable high, critical and unrated ones, and reports the rest. The exceptions are a short per-CVE allowlist in the repo, for findings whose only published fix is an unreleased interpreter beta. A malware scan gates it too. Snowflake then runs its own scan when we publish and rejects fixable high and critical CVEs, so the version that reaches you passed a check we do not control.
Because the app has no route out, it cannot fetch code or packages once it is running. What was scanned at publish is what executes in your account.
What actually lands in your account.
A native app is not a black box you have to trust. It is a set of objects in your account that you can list, inspect, and drop. Here is the shape of it, and SHOW OBJECTS OWNED BY APPLICATION gives you the full inventory.
Installed from the listing you were granted. It carries a version, and you can see which one you are on at any time.
The app creates one to run its own containers. That plus binding its own endpoint are the only two account privileges it asks for. It also requests the Snowflake CORTEX_USER role, which powers the in-account authoring agent and which you can decline. None of the three grant access to your data.
A single ingress your team opens in the browser, reached at a snowflakecomputing.app address and protected by Snowflake's own authentication. Nothing else is exposed.
Registered in your account at install, so in-account agents can attach to dvt without hunting for a URL. Cortex Agents reach it from inside Snowflake, and your team can point Claude Code at it from their own machines with a Snowflake credential. Agents authenticate as Snowflake identities, so there is no dvt API key to issue or rotate. Note the direction: an agent connects inward, through Snowflake's authentication. The app still calls nothing out.
Dashboard specs, versions, comments, and org knowledge live inside the app, in your account. Even the metadata about your dashboards stays put.
The app points at the account it is installed in from first boot. There is no host, credential, or connection string for anyone to configure.
The same dvt, with Snowflake-native substitutions.
The native app is a deployment shape, not a reduced tier. Access control is Snowflake roles and grants rather than dvt's own user management, and image export and scheduled delivery are not in-account yet. The rest is the product, which rests on one decision: a dvt dashboard is a versioned JSON spec, not a pile of saved clicks.
Bring your own agent, Claude included
Create, edit, and audit are first-class operations over MCP, so an agent builds a dashboard from a sentence. Use Cortex Agents in the account, or connect Claude Code and work on your dashboards the way your engineers already work on code. Any write can be previewed and validated before it persists.
Versioned, with real diffs
Every change to a dashboard, page, or single element gets an append-only revision. Roll back to any version; elements keep their identity so later edits stay correct.
Reviewed like code
Leave a threaded comment pinned to a panel. An agent reads the open threads, makes the edits, replies, and resolves. Reviewers do not need edit rights.
Taught your conventions
Skills are versioned, org-scoped authoring docs: your metric definitions, your warehouse semantics, how your team builds charts. Agents read them before authoring.
Attributed, always
Every edit records whether a human, an agent, or the system made it, and which key an agent acted through. Nothing an AI does is anonymous.
Yours to style
No locked styles. Every visual property, down to the gap between an axis and its title, is an exposed parameter. Set your own product name, accent, and logo.
The spec format and client SDKs are Apache-2.0. There is a fuller tour of the product atdvt.dev/product.
The parts we would ask about.
Zero egress cuts both ways. Because the app cannot call out, there is no in-app feedback or bug reporting, and no error report ever reaches us on its own. When something breaks you tell us out of band. We treat that as the cost of the posture, not a gap to close.
It runs on your credits. The app's containers and every query it issues consume your Snowflake compute. There is no dvt-hosted tier absorbing that cost in this deployment.
We drive the upgrades, and they fail safe. New versions reach your install when we publish them, the way any native app works. If a version's migration fails, the upgrade aborts and the version you are already running keeps serving.
Put dvt inside your account.
Tell us where it should go and we will get it there. Nothing has to leave your account for any of it, including the evaluation.