Role-based access control in Rig: control who can access what data

    Fine-grained access controls let you decide exactly who in your team is allowed to see, edit, or request which data, all the way down to the row and column. Preview what each role sees before you ship.

    Access gateway: who sees which schema

    Inside the access gateway, every data collection and schema you've connected to Rig shows up in one place. The schema matrix is where you decide who is allowed to access what.

    Access matrix
    5 roles · 6 collections
    Role
    CRM
    medium
    Meeting notes
    low
    Banking — payroll
    high
    Product analytics
    low
    Banking — ops
    critical
    Warehouse
    medium
    analyst
    editor
    owner
    sales
    viewer

    PII, financial data, and context-layer permissions

    Beyond schema access, you can decide who can edit data context and what sensitive categories each role is allowed to see. Rig auto-classifies PII, financial, and confidential fields when it builds your context layer, and you can edit the classifications whenever you need to.

    RolePIIFinancialConfidential
    ownerallowallowallow
    editorpartialallowredact
    analysthashallownull
    viewernullnullnull

    Column masks, row filters, and area grants

    Mix and match four primitives to model how each role sees your data, with column-level masks and row-level filters that scope exactly which cells and which rows a role can read.

    Column mask

    Redact specific columns for a role.

    Row filter

    Limit which rows a role can see.

    Table override

    Allow or block a specific table.

    Area grant

    Permit a virtual collection of tables.

    Preview before you ship

    Pick a role and preview exactly what they'll see, either by asking a question in plain English or running a SQL query as them. Confirm the masked columns and filtered rows match your policy before you grant the role to anyone.

    1

    Pick a role

    Viewer · Analyst · Admin

    2

    Choose SQL or prompt

    Test the rules against schema.

    3

    Run

    Use the insert to pull a query.

    4

    Inspect

    See what comes back redacted, blocked, or live.

    Model permissions so that anyone on the team can plug into your internal data and context layer from Claude or Cursor, while the data team sets permissions on who is allowed to access what and tests that they work.

    Was this guide helpful?