dvt as a Snowflake Native App: the security review that runs out of questions
If you run the data platform at a Snowflake shop, you already know how this conversation goes. A BI vendor asks for a service account with a role on your warehouse, an allowlisted path for their SaaS backend, and an external access integration so their app can call out for updates or telemetry. Your security team reads that list and the tool never makes it past the first review.
That review has a subject: a vendor’s servers, somewhere outside your account, that your data has to reach to be useful. dvt as a Snowflake Native App removes the subject. There is no service user to provision, no egress to allow, and no external access integration to approve, because there is nowhere outside your account for anything to reach.
How dvt runs inside your Snowflake account
dvt installs from a Marketplace listing into your own account and runs on Snowpark Container Services, on your own compute, behind Snowflake’s own authentication. It ships as four containers: the interface and API, the query engine, a headless renderer that draws chart images for emailed reports, and its own metadata store. No third-party service sits in that path.
The install creates a small, inspectable set of objects. A compute pool to run the app’s own containers, and binding its own endpoint, are the only two account privileges it asks for; it can also request the Snowflake CORTEX_USER role to power an in-account authoring agent, and you can decline that one. None of the three grant it access to your data. You get one web endpoint, a single ingress reached at a snowflakecomputing.app address, with nothing else exposed. An MCP server registers in your account at install, so agents can attach to dvt without hunting for a URL. Dashboard specs, versions, comments, and org knowledge live in the app’s own storage, inside your account, not in ours.
What changes for your Snowflake security review
Run the standard vendor questionnaire against that shape and most of it stops having anything to ask. Where does the vendor store and process our data: nowhere, it stays in your account. Which subprocessors will our data pass through: none. What credentials or service accounts must we issue, and how are they rotated: none, agents authenticate as Snowflake identities, so there is no dvt API key to issue or rotate in the first place. What can the vendor see if the vendor is breached: nothing of yours, because dvt operates no service outside your account that could receive it. What outbound egress must we allow for it to work: none. Which external access integrations does it ask us to approve: none. Which of our data does the application itself hold access to: none, dvt requests no grants on your data. How do we revoke access, and how quickly does it take effect: uninstall it.
What is left is the review any Snowflake Native App gets: which privileges it requests, and which warehouse it may run on. Your admin reads both in Snowsight before accepting, and every query the app issues afterward shows up in your own account’s query history, attributed to the person who ran it, not to a shared service account. You do not have to take a vendor’s word for any of this; it is the same posture every Snowflake Native App gets reviewed on.
Snowflake RBAC, applied per request
The data plane is where this actually gets enforced, not just described. Every warehouse query dvt issues runs under the calling user’s own Snowflake identity, so Snowflake applies that person’s role grants, row-access policies, and column masking the same way it would if they had typed the query themselves. dvt does not maintain a parallel authorization model for data access, because there is nothing for it to maintain: Snowflake is already the authority.
Access to the app itself works the same way. dvt declares application roles, and your account admin decides who holds them with an ordinary GRANT APPLICATION ROLE, the same mechanism you already use for every other Snowflake object. There is no separate dvt login system, no invitation flow, no seat count to reconcile. A user with the authoring role can create dashboards and edit their own and the ones shared with them; an elevated role can see and manage everything else, granted the exact same way. Nothing about how someone gets into dvt lives outside Snowflake’s own access control.
Where Claude and Cortex fit in
Agent access follows the identical rule, with no special case written for it. Cortex Agents call dvt’s MCP tools from inside your account, billed as your own compute like everything else the app does. Claude Code, or any other MCP-capable client, reaches the same registered MCP server from outside, authenticating with a Snowflake credential rather than a dvt API key. Either way, the agent inherits exactly the Snowflake role it was granted, and its queries run under that same caller’s-rights data plane. An agent cannot see or touch anything a human with its Snowflake identity couldn’t.
That access is enough to do real authoring work. Create, edit, and audit are first-class operations over MCP, so an agent can build a dashboard from a sentence, and any write can be previewed before it persists. That’s the same versioned-JSON foundation the rest of dvt is built on, described in full at dvt.dev/product; the native app is a deployment shape for it, not a separate product.
What this does not solve
Zero egress cuts both ways. Because the app cannot call out, there is no automatic error report or usage signal reaching us from inside your account. When something breaks, you tell us out of band; that is the cost of the posture, not a gap we’re pretending isn’t there.
It also runs on your Snowflake credits. The app’s containers and every query it issues consume your own compute, and in this deployment there is no dvt-hosted tier absorbing that cost for you.
Access control here is Snowflake roles and grants, not dvt’s own user management, which is a genuinely different model from dvt’s other editions and worth knowing before you plan a rollout. And a couple of capabilities available elsewhere in dvt, image export and scheduled delivery, are not yet available inside the native app.
None of that changes the core claim: your rows never leave your account, and the review that used to stall on a service user and an egress rule now has an answer your own admin can check in Snowsight. If you want the fuller security posture behind all of this, it’s laid out at dvt.dev/security.