What is RBAC (Role-Based Access Control)? Definition for Data Teams

RBAC (Role-Based Access Control) is an access control method that assigns permissions based on roles rather than individual users. In data analytics, it determines which metrics, dimensions, and rows each team, customer, or AI agent can query. Define roles once, assign users to them, and access rules apply automatically. Unlike ad-hoc permission systems where access is granted per user per resource, RBAC scales with your organization. Add a new team member to the "analyst" role and they inherit the correct metric visibility without anyone filing a ticket. This is especially important for B2B SaaS products where hundreds of customer tenants each need isolated, scoped data access.

How does RBAC work in analytics?

Roles map to metric visibility. A "marketing" role can query campaign metrics but not financial data. An "executive" role sees everything. A "customer" role sees only their tenant's data. Each role defines which cubes, measures, and dimensions are accessible. This works across every query surface: dashboards, API calls, and AI agent requests all resolve to the same role definitions.

Row-level security adds another layer. Context variables (like tenant_id or department) filter every query at execution time. The filter is injected by the semantic layer before the SQL reaches the warehouse. The user never sees rows outside their scope, and the application code doesn't need to implement the filtering. Compare this to building tenant isolation in application code, where every new endpoint, dashboard, and integration needs its own WHERE clause. One missed filter is a data breach.

cubes:
  - name: orders
    sql_table: public.orders
    access_policy:
      - role: customer
        row_filter:
          sql: "tenant_id = {BONNARD_TENANT_ID}"
      - role: marketing
        includes:
          - order_count
          - total_revenue
          - status

Why do data teams need RBAC?

Multi-tenant B2B products. Every customer must see only their data. Without RBAC at the data layer, you end up writing tenant filtering logic in application code, duplicating it across dashboards, APIs, and AI integrations. One missed filter and customer A sees customer B's revenue numbers.

Compliance requirements. SOC 2, GDPR, HIPAA all require demonstrable access control. Roles defined in YAML and enforced at the query layer provide an auditable, version-controlled record of who can access what. No manual permission spreadsheets.

AI agent governance. When an AI agent queries your data via MCP, it needs the same access rules as a human user. RBAC applied at the semantic layer means the agent's publishable key maps to a role. The agent can only query metrics its role permits. No prompt injection bypasses the data layer.

How Bonnard implements RBAC

The admin UI provides governance groups that map to roles in your semantic layer definitions. You create groups, assign metric and dimension visibility per group, and define row-level security filters using context variables. Groups are composable: a user can belong to multiple groups, and the most restrictive policy wins.

Publishable keys carry the tenant and role context. When an AI agent or React component makes a query, Bonnard resolves the key to a role, applies row-level filters, and restricts the result to permitted metrics. Every query is logged with the role and tenant context for audit purposes. This audit log satisfies SOC 2 and GDPR requirements for demonstrable access control without building a separate compliance layer.

Define access rules in YAML, manage them in the admin UI, and deploy with bon deploy. Read more about governance in the semantic layer guide.

Related terms

• Semantic Layer
• Metric Governance