Data Access Control
Data RBAC (Role-Based Access Control) lets admins control who can see which databases, tables, and columns. Restrictions apply everywhere — agents don't even see restricted data in their context, so they can't accidentally reference it.
How it works
Access is resolved through a 4-tier hierarchy. The most specific level wins:
Each level can set one of three permission values:
| Value | Meaning |
|---|---|
| Allow | User can access this resource |
| Deny | User cannot access — agents won't see it at all |
| Inherit | Defer to the next level up in the hierarchy |
What you can restrict
Access control operates at three granularity levels:
- Connection level — Hide an entire database from certain users or groups. The database won't appear in the agent's context at all.
- Table level — Hide specific tables within an allowed connection. The agent can query other tables in the same database but won't know the hidden table exists.
- Column level — Hide specific columns within an allowed table. The agent can query the table but won't see or reference the hidden columns.
Example: The marketing team can see the sales database but not the salary column in the employees table. An agent answering a marketing user's question will never reference salary data — it's not in the agent's context.
How restrictions affect agents
RBAC is enforced before agents ever see your data — restricted tables and columns are completely invisible to agents, and queries are validated before execution.
- Agents don't see restricted schemas in their prompts — they literally don't know hidden tables or columns exist
- They can't write queries against hidden data because it's absent from their context
This means a user can't trick an agent into accessing restricted data by phrasing a clever question — the data simply isn't available to the agent.
Resolution order
When Thallus needs to determine whether a user can access a specific resource, it walks the hierarchy from most specific to least:
- Check user override — If an explicit setting exists for this user, use it
- Check group settings — If the user belongs to multiple groups, any "allow" wins
- Check organization settings — The org-level default
- Check platform settings — The system-wide default
- Default — If nothing is set at any level, access is allowed
Where to configure
| Tier | Location | Who can access |
|---|---|---|
| Platform | Admin → Platform → Data Connections | Superadmins only |
| Organization | Admin → Organization → Data Connections | Org admins and superadmins |
| Group | Admin → Groups → [select group] → Data Connections | Org admins and superadmins |
| User override | Admin → Users → [select user] → Data Connections | Org admins and superadmins |
Viewing effective access
Admins can view the resolved permissions for any user — the final result after all hierarchy levels are evaluated. This shows exactly which connections, tables, and columns are visible to that user.
This is useful for:
- Auditing — Verify that sensitive data is properly restricted
- Troubleshooting — Answer "why can't I see this table?" questions by checking where a deny rule is set
- Onboarding — Confirm new team members have the right access before they start using Thallus
Related pages
- Connecting Databases — Set up the connections that RBAC controls
- PII Detection — Automatic flagging that informs RBAC decisions
- Schema Discovery — How table and column metadata is discovered