---
title: "Scoped access to VDMs"
description: "Group VDMs into VDM schemas, grant them to roles in the Access Matrix, and govern a VDM so a team can read the roll-up without access to the tables it was built from."
canonical: "https://rig.so/guides/vdm-access"
format: markdown
---

Search guides, references, playbooks…⌘K

Browse guides

# Scoped access to VDMs

A [VDM](https://rig.so/guides/virtual-data-models) inherits its access by default, so only roles that can read every table behind it can read the VDM. Governing it adds readers: roles granted its VDM schema can read every column, including the ones the model wrote, with no access to its sources. Nobody who could read it before loses access.

Before you start
You need admin access for VDM schemas and the Access Matrix. To govern a VDM you need `data_engineer` or higher, and you must be able to read all of its sources unmasked yourself.

## Set it up

1. In `Admin`, open the `Access` tab, then **Collections**, then **VDM schemas**. Click **New VDM schema** and type a label; the name fills itself in.
   
   ![The VDM schemas tab in Collections with a new schema labelled Account summaries, stored as vdm_account_summaries](https://rig.so/vdm-access-new-schema.jpg)
2. Open the VDM. In **Who can read this VDM**, pick the schema, then tick the roles that should read it. Each role shows whether it reads through the sources, through the VDM schema or not at all.
3. Click **Govern**. The dialog shows which roles will gain access and which already have it through the sources.
   
   ![The Govern dialog: viewer will gain access to every column without access to its sources, while owner already reads it through its sources](https://rig.so/vdm-access-govern.jpg)
   
   ![The Who can read this VDM panel in governed mode: owner reads via sources, viewer reads via the VDM schema, with Add a person and Return to inherit](https://rig.so/vdm-access-governed.jpg)Once governed, viewer reads it through the VDM schema. Return to inherit undoes it.

To give one person this VDM and nothing else, use **Add a person**. If the VDM's SQL, prompts or upstream models change, it drops back to inherit until someone governs it again. All of this is in the audit log.

## Grant from the Access Matrix

The **Access Matrix** lists schemas down the side and roles across the top; click a dot to grant or remove access. The **VDM schemas** tab works the same way, and expanding a row shows whether each VDM in it is governed.

![The VDM schemas tab of the Access Matrix: Account summaries granted to owner and viewer, expanded to show customer_account_summaries as governed](https://rig.so/vdm-access-matrix-vdm.jpg)

## Check what a role can see

On a VDM's page, pick a role under **Who can see this?** for a one-line answer. For everything at once, open **Preview as Role** and click **What can viewer see?** Each table and VDM shows as readable, with any masked columns, or blocked, with the reason. AI tools get the same check over MCP as `check_role_access`.

![Preview as Role for viewer filtered to customer: readable tables with masked columns listed, the governed VDM among them, and two blocked raw tables with the reason](https://rig.so/vdm-access-check.jpg)

## Good to know

- An explicit deny on the VDM still wins over governing.
- Masks on the VDM apply everywhere it is read.

For roles and masking in general, see [role-based access control](https://rig.so/guides/rbac).

Was this guide helpful?

Yes No

---

- [This page as HTML](https://rig.so/guides/vdm-access)
- [Site map for language models](https://rig.so/llms.txt)
- [API and agent documentation](https://rig.so/developers)