Skip to main content
By default every member of an organization can query every connected data source. For most companies that’s too open. CoreBase’s access policy engine lets you scope reads to a specific user attribute, table, or column pattern — enforced server-side, before SQL hits your database.

​
The model

A policy is a single rule:

​
Where attributes come from

User attributes live on each member’s organization membership metadata and are carried into their session token at sign-in. Set them per member from your organization settings. Example membership metadata:
A user with dept=hr can only see tables and Slack channels covered by HR policies.

​
Common policies

Lock #finance Slack to admins

source_type=slack_message, container=channel:C123, access_level=admin_only

HR email by sender domain

source_type=o365_email, container=sender_domain:hr.example.com, access_level=restricted, attrs={dept:hr}

PII columns admin-only

source_type=mssql, container=column_pattern:.*_ssn$, access_level=admin_only

Branch-scoped customer rows

source_type=postgres, container=table:customers, access_level=restricted, attrs={branch:user.branch}

​
Audit

Every retrieval emits a row to audit_logs. The columns capture the state at query time — so even if a policy changes later, you can still see what was enforced when:
  • user_id, is_admin_at_query, user_attrs_snapshot
  • query_hash (SHA-256 of the prompt; raw text is not stored), query_length
  • retrieved_chunk_ids, retrieved_count, applied_policy_ids
  • chat_id, duration_ms, created_at
Filter by user, policy, or time range under Security → Audit Log.
Defense-in-depth: a user with no user_attrs set is treated as having empty attrs — they only see access_level=all content. Missing attrs are not a bypass.