Governance & policies

Governance in ObeliskDB is enforced where it cannot be bypassed: inside the query rewrite, on the path every statement takes. A policy is not advice to a model — it is a transformation applied to the scan before any result reaches the caller, human or agent.

Roles and grants

Role-based access control with a role DAG, the standard system hierarchy, and container-level USAGE checks. ACCOUNTADMIN bypasses object checks; every other role sees only what it is granted.

CREATE ROLE ANALYST;
GRANT USAGE ON DATABASE DEMO TO ROLE ANALYST;
GRANT SELECT ON TABLE DEMO.SALES.ORDERS TO ROLE ANALYST;
USE ROLE ANALYST;
SHOW ROLES;
SHOW GRANTS TO ROLE ANALYST;

Permission errors mean the role lacks access, not that the object is missing — Obi is taught to say so and suggest the grant that would fix it.

Masking, in the scan

A masking policy is applied inside the scan subquery, not at output projection. That distinction matters against an adversarial querier: because the filter runs over masked values, an agent cannot confirm a secret by observing whether WHERE ssn = '...' selects a row.

CREATE MASKING POLICY MASK_SSN AS (V TEXT) RETURNS TEXT ->
  CASE WHEN CURRENT_ROLE() = 'ACCOUNTADMIN' THEN V ELSE '***' END;
ALTER TABLE HR.PII MODIFY COLUMN SSN SET MASKING POLICY MASK_SSN;

SHOW POLICIES;   -- masking + row access, with what they attach to

The policy is precise: a privileged role still reads real values, so it is a scoped confidentiality boundary rather than a blanket denial. Masked columns are excluded from zone-map pruning for soundness.

Row access policies

Row policies filter rows by the current role or context, applied in the same scan rewrite. Filters see the policy-filtered set, so nothing leaks through an aggregate or a join.

Aggregation thresholds

Beyond masking a value, you can require that aggregates cover a minimum cohort — the query-set-size restriction that defeats reconstructing an individual by probing tiny groups.

ALTER TABLE HR.EMPLOYEES SET AGGREGATION THRESHOLD = 5;
-- SELECT AVG(SALARY) ... WHERE id = 1  ->  refused
-- SELECT AVG(SALARY) FROM HR.EMPLOYEES ->  allowed

Agents inherit governance

Every guarantee here applies to Obi and to external MCP agents exactly as it applies to a human — an agent under the ANALYST role sees masked data, and can do only what the role can do. Two agent-specific controls build on this layer:

• - Compelled governance — restrict a session to metrics and insights only (GOVERNED_ONLY), so raw table access is refused entirely.
• - Injection resistance — agent sessions refuse irreversible and privileged operations outright.

Both are covered in The guarantees.

Users and preferences

Multi-user mode: with no users defined the platform is open (single-player); the moment a user exists, login is required and every surface (UI, emulator, pgwire) verifies passwords.

CREATE USER ada PASSWORD='...' DEFAULT_ROLE=ANALYST;
ALTER USER ada SET DEFAULT_WAREHOUSE=WH DEFAULT_NAMESPACE=DB.SCHEMA THEME='light';
SHOW USERS;

Per-user preferences (theme, default role, warehouse, namespace) persist and apply at login. The console's Admin tab drives users, roles, grants, and policies without SQL — every action goes through the same governed front door and lands in history.

Audit

Everything is on the record: query_history and the statements log capture each statement with its accessed objects, versions, and cost; SHOW AGENT SESSIONS is the agent audit trail. See receipts in the guarantees.