Skip to content

Data Access & Governance (dw-governance)

The Data Access & Governance agent is the policy and access layer of the swarm. It evaluates actions against your active governance policies with a fast policy engine and returns an allow / deny / review decision with the matched rules — so a decision is always traceable to the rule that made it. Access provisioning is least-privilege by design: requests carry a written justification, grants support column-level restrictions, and access auto-expires after 90 days by default instead of accumulating forever.

It can also work your platform’s native access controls, not just its own records. Against Databricks Unity Catalog it reads the grants actually in effect, normalizes them across platforms, diffs them against intent, and — behind an approval gate — writes reconciliation back out as native GRANT/REVOKE, with before-and-after snapshots folded into a hash-chained audit log.

  • Policy evaluation with receipts. check_policy validates an action against active policies and returns allow/deny/review plus the specific matched rules.
  • Least-privilege provisioning. provision_access processes access requests (plain English justifications accepted) with column-level permissions and 90-day auto-expiration; enforce_rbac applies role-based control with role hierarchy.
  • Column-level PII scanning. scan_pii uses three-pass detection — column-name heuristics, pattern matching on sampled values, and model-assisted classification — and reports at column level, because a table-level “probably has PII” wastes remediation effort.
  • Live grant import. list_platform_privileges reads the grants in effect on a Unity Catalog securable, normalized to common access levels, with inherited grants flagged and unmappable native privileges surfaced rather than dropped.
  • RBAC reconciliation. diff_catalog_rbac produces a dry-run plan of where intended and live grants disagree; sync_catalog_rbac applies it behind an approval gate, with configurable conflict policy — platform wins, Data Workers wins, or most-restrictive (which never escalates access).
  • Audit reports with an evidence chain. generate_audit_report covers agent actions, policy evaluations, access grants, and PII detections for a period, on demand or scheduled.

“Can the analytics role read finance.payroll? Show me which policy decides that.”

“Grant Priya read access to the marketing schema for 30 days — she’s debugging the attribution model.”

“Scan crm.contacts for PII, column by column.”

“Diff our intended grants against what’s actually live in Unity Catalog — dry run only.”

“Generate an access audit report for Q2.”

  • Databricks Unity Catalog — the first live backend for reading and reconciling platform-native grants.
  • Warehouses and catalogs — Snowflake, BigQuery, DataHub, OpenMetadata as the assets policies and scans apply to.
  • Identity — Okta and Azure AD user context through the connector gateway.

See the connector catalog, and least-privilege connector setup for scoping credentials.

The agent starts in 🟡 Evaluation on built-in sample data — the policy engine, RBAC logic, and PII pattern matching are the real thing. It earns 🟢 Connected per system through a passing live test. See Verify your setup.

  • Live grant read/write is implemented for Databricks Unity Catalog today; other platforms run on sample data until their live paths ship. When a backend isn’t live, the response says so rather than reporting a recorded grant as a real mutation.
  • grant_access, revoke_access, and sync_catalog_rbac are production writes: they are blocked without an approved request, and every call lands in the hash-chained audit log. There is no autonomous path to changing access.
  • Scheduled RBAC sync is off by default, and scheduled runs are dry-run — turning a diff into a real apply always goes back through the approval gate.
  • PII detection reports findings with the pass that produced them; it is a detection aid with a precision target, not a compliance certification.