Scoped access to VDMs

    A VDM 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.
    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.

    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.

    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.

    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.

    Was this guide helpful?