Skip to main content
Attribute-Based Access Control

​
What You’ll Accomplish

Attribute-Based Access Control (ABAC) lets you scope policies using attributes on resource roles. You can:
  • Target many resource roles with a single rule by matching a shared attribute
  • Reduce long, brittle lists of individual resource roles in policy configuration
  • Keep using explicit per-resource-role assignment where that still fits your team
  • Manage attributes in one place, including batch-style updates

​
How It Works

1

Configure attributes

For each attribute, define what it represents and which resource roles it applies to.
2

Scope policies by attribute

When you configure a supported policy, choose attribute-based scope so one rule can match every resource role that carries that attribute.
3

Use alongside other rules

You can still assign policies to specific resource roles directly; both approaches can be used together.

​
Where You’ll See Attributes

AreaWhat you can do
Settings > AttributesCreate, edit, and review attributes and which resource roles they apply to
Resource rolesSet attributes in the Details section of a resource role
Feature configurationWhere a feature supports it, scope rules using attributes (for example, Guardrails, Live Data Masking, Access Control, Access Requests)

​
Quick Start

​
Step 1: Open Attributes

  1. In the sidebar, go to Settings > Attributes

​
Step 2: Create an attribute

  1. Click Create a new Attribute
  2. Define a Name (and any other required fields on the form)
  3. Choose which resource roles this attribute applies to—this is the set of roles that will match when you scope rules by this attribute
  4. Save your changes

​
Step 3: Scope a policy by attribute

When you create or edit a rule in a supported feature, you can attach it to an attribute instead of selecting many resource roles individually.
  1. Open the feature you need (for example, Guardrails, Live Data Masking, Access Control, or Access Requests)
  2. Create a new rule or policy, or edit an existing one
  3. Fill in the rest of the form the way you usually would (patterns, actions, approvals, and so on—whatever that screen asks for)
  4. In the scope or assignment section, choose attribute-based scope (or the equivalent label) and pick the attribute you created
  5. Save your changes
One attribute then covers every resource role it applies to—you do not need to add each role by hand.

​
Step 4: Verify

  1. Run a query or command from a resource role that should match the rule
  2. Run one from a resource role that should not match
  3. Confirm the outcome (for example, blocked vs allowed) matches what you expect

​
Best Practices

Name attributes for policy intent

Prefer stable, meaningful names (for example, prod-data-store) so rules stay understandable as teams change.

Keep assignments current

When resource roles change, update attribute assignments so policies still match the right scope.

Start with a small scope

Pilot attribute-based rules on a narrow attribute, then expand once outcomes look right in sessions and audits.

Pair with per-resource-role rules when useful

Use attribute-based scope for broad patterns and explicit resource role picks for exceptions—both can coexist.

​
Troubleshooting

​
I don’t see attribute-based options in a feature

Check:
  1. Your role can manage that feature
  2. The feature version you use includes attribute-based scope (options appear in the rule or policy screen when available)
  3. Attributes exist and are assigned to the resource roles you expect

​
A policy didn’t apply to a resource role

Check:
  1. The resource role has the attribute you used in the rule
  2. No conflicting rule with a narrower resource role selection is overriding your expectation
  3. Filters on the Resources or Resource Roles lists show the attribute you think you set

​
Next Steps

Access Control

Restrict who can use which connections

Guardrails

Block dangerous queries with pattern-based rules

Live Data Masking

Redact sensitive data in query results

Access Requests

Require approvals for sensitive access