In Part 1 of this series, we compared dedicated catalogs, dedicated workspaces, and strong logical isolation. This article moves from architecture choice to execution and focuses on one of the most important controls in the strong logical isolation model: tenant-scoped Genie spaces.
Designing the Genie Boundary
As a conversational interface, Genie interprets user questions, resolves context, and returns answers through the connectors, tools, and permissions available. When exposed to external users, it becomes an access surface that requires isolation discipline. Designing this boundary correctly is essential to preventing cross-tenant leakage.
The key architecture decision is whether spaces should be shared across tenants or provisioned per tenant. While a shared Genie space can look operationally efficient, it combines risk domains that should stay separate:
- Data connectors for multiple tenants
- Broader tool visibility than necessary
- Conversational context and history in one place
- Increased chance of accidental over-permissioning
Even when base table permissions are well designed, a shared AI surface creates unnecessary governance pressure.
The Tenant-Scoped Genie Model
Why do we need tenant-scoped Genie rooms? Ideally, we would have a single Genie template, and parameterize access with a tenant_id. Databricks has enabled this type of functionality with Embedded Dashboards, using a special parameter called __aibi_external_value which can be used during the authentication process to filter access. However, this functionality is not yet available for Genie rooms.
The safer pattern is still one Genie space per tenant, provisioned from a standard template and bound only to tenant-approved data resources.
Core design principles
- Each tenant gets a dedicated Genie space
- Each space only references that tenant's schema/views
- Each space receives only required tools
- Access is granted to tenant-specific principals only
- Provisioning is fully automated and idempotent
This aligns AI behavior with the same least-privilege posture enforced in Unity Catalog.
Reference architecture
An implementation blueprint usually looks like this:
- Resolve tenant identity at login via OIDC claims.
- Provision tenant principal(s) and group mappings with SCIM.
- Create or update tenant schema and filtered views in Unity Catalog.
- Create Genie space from a template with tenant placeholders.
- Bind Genie connectors/tools to tenant-safe objects.
- Grant run-level permission to tenant principal(s) for that space only.
- Validate with automated negative tests before activation.
The key is deterministic automation. Manual exception handling is where drift and security mistakes begin.
Quick Start Checklist
The baseline for tenant-scoped Genie is repeatability: standard controls that make each space easier to scale, audit, and validate from the beginning. Start with these essentials:
- Define tenant-aware Genie template schema
- Automate tenant space creation and updates
- Enforce least-privilege grants per tenant principal
- Add tenant-specific health checks and drift detection
- Include cross-tenant denial tests in CI/CD
Final Takeaway & What's Next
Tenant-scoped Genie spaces turn conversational AI from a potential governance liability into a controlled, auditable interface. When each tenant gets a dedicated space bound to tenant-filtered data and least-privilege permissions, you dramatically reduce leakage risk while keeping the platform scalable.
In Part 3, we will extend this model to external agent integration through MCP and show how to preserve tenant boundaries across tool-calling workflows.
- Part 1: Why isolation decisions matter and how to choose the right architecture
- Part 3: External agent integration through MCP with tenant-safe credential and request flows
