GenieRails

Put Genie onboarding on rails — with built-in guardrails. Take a Genie agent from dev to production without exposing sensitive data: Unity Catalog's built-in classifier decides what is sensitive, GenieRails derives how it's protected and applies it as code — groups, column masks, row filters, ACLs, entitlements, and the agent itself — and no new business access is granted until every classified sensitive column the agent can reach is covered.

Pick your path

You want to	Start with
Govern and promote agents (the champion flow): ship a Genie agent from dev to prod with its sensitive columns masked	the Dev-to-Prod Walkthrough (~30 min), then the agents playbook
Govern tables only: for a central data governance team that defines the table rules (masks on classified columns, row filters, who reads each table), reviews them as code and promotes them from dev to prod, for every consumer of those tables, Genie agents included. Also for platform teams securing catalogs before Genie rolls out	Govern tables only, then the governance playbook

After the first deployment: one team doing both, pipelines and the deployment machine.

How it works

1. Unity Catalog decides what's sensitive. Its built-in Data Classification scanner reads your data and tags each sensitive column.
2. GenieRails decides how it's protected. From those tags it derives one treatment per column — column masks and row filters — plus access rules mapped to your existing IdP groups, and applies it all as Terraform, so you don't write any.
3. A coverage check is the safety net. Any make apply that would add or widen business SELECT or CAN_RUN withholds that new access (or fails closed) unless a recent coverage check passed, meaning every classified-sensitive column has protection. Protection still applies. So no one gains new access to unprotected sensitive data.
4. Dev rehearses; prod is the real thing. Build and test in dev, promote the rules to prod, let prod classify its own data, and release a rehearsed commit (release-plan, then release): masks go on before any user is granted access.

Documentation

Browse all docs → — the full index: walkthrough, playbooks, pipelines, architecture, effective-access verification, and troubleshooting.

Command and settings reference → — every make target and every env.auto.tfvars / auth.auto.tfvars setting.

Bootstrap note: make bootstrap-sp prints a new OAuth secret by default; BOOTSTRAP_AUTH_ENV=<env> writes a newly minted secret directly to that env's private auth.auto.tfvars instead. See the command reference for the guardrails. It reuses an SP only by exact display name (SP_NAME, default genierails-deployer): pass SP_NAME=<its name> for an existing SP, or it creates a second one.