Shawn DavisonMay 29, 2026

Multi-Tenant Isolation for Databricks, Part 3: External Agent Integration Through MCP

Part 1 of this series compared isolation architectures: dedicated catalogs, dedicated workspaces, and strong logical isolation. Part 2 moved from architecture choice to execution and positioned tenant-scoped Genie spaces as a core AI boundary.

In this final article, we close the loop on the external edge: how to integrate AI agents through MCP without breaking tenant isolation.

Why MCP Changes the Risk Profile

MCP unlocks powerful tool-calling and automation, but it also amplifies mistakes – so tenant context must survive from first authentication to final tool invocation, with enforcement that aligns to both Genie and Unity Catalog.

External agent traffic differs from internal analyst traffic:

requests originate outside your workspace boundary
agents may execute high-frequency tool calls
identity is often translated across multiple systems
credential misuse can scale rapidly

The architecture must preserve tenant context from first authentication event to final tool invocation.

External Agent Traffic Differs from Internal Analyst Traffic diagram

Designing the Tenant Boundary at the MCP Edge

In Part 2, the safe pattern was one Genie space per tenant – provisioned from a standard template and bound only to tenant-approved data resources and tools. MCP integration must preserve that same boundary when requests originate outside the workspace.

The invariant is simple: an external request must resolve canonical tenant context before it reaches Genie, tools, or data – and it must remain constrained by Unity Catalog policies throughout execution. If tenant context is inferred downstream, or if credentials and routing decisions are shared across tenants, the Genie boundary becomes a shared risk surface again.

The Tenant-Safe MCP Control Stack

A strong pattern for external integration has four controls:

Identity-first tenant resolution
Tenant-scoped credentials
Policy-validated request routing
Full audit lineage

The guiding principle is simple: external agents should operate with no more privilege than a tenant-scoped user in the same context.

End-to-End Request Flow (Tenant-Preserving)

External app/agent authenticates and presents OIDC-backed identity context.
MCP entry layer validates token integrity and tenant claims.
Request is evaluated against tenant and tool policy.
Tenant-specific credential reference is resolved from the edge control plane (backed by KMS/secret management).
Request is routed to the correct tenant Genie space and tenant-bounded Unity Catalog objects (catalog/schema/views depending on the isolation model).
Response is returned with request, tenant, tool, and policy metadata logged.

This flow preserves tenant boundaries through every hop instead of relying on downstream systems to "figure it out."

Deep Dive

Controls, Observability, and Launch Gates

With the MCP edge defined, the remaining work is operational: keep tenant context deterministic, enforce least-privilege access through the edge control plane, validate isolation continuously, and avoid shortcuts that reintroduce shared risk.

The Edge Control Plane: Policy + Secrets + Routing

Most production designs include an edge control plane to centralize the decisions that should not drift across tenants – policy evaluation, tenant context resolution, credential reference handling, and deterministic routing. The edge control plane integrates with a key service (or secrets manager) to store, encrypt, rotate, and revoke tenant-scoped credential material or credential references.

What the edge control plane should do:

map validated identity to canonical tenant context
evaluate requests against tenant and tool policy before execution
resolve tenant-scoped credential references securely (supporting rotation and revocation)
route deterministically to the correct tenant Genie space and tenant-bounded data path
implement break-glass controls with strict audit trails
provide event-level lineage for compliance reviews

What it must not do:

store plaintext secrets in analytical tables or logs
bypass policy evaluation for convenience
share credentials across tenant boundaries by default

Authorization and Policy Guardrails

Enforce explicit tool allowlists

Per tenant, define exactly which tools, connectors, and actions are permitted. Deny by default and require explicit approvals for expansion.

Validate tenant context at every boundary

Do not trust client-supplied tenant hints alone. Reconcile token claims, principal mappings, and policy state before execution.

Apply quotas, throttles, and circuit breakers

Tenant-level limits protect both stability and blast radius. They also improve fairness when multiple tenants share infrastructure.

Minimum Audit Lineage for External Agents

For external agent systems, logs are a security control, not just an operations artifact. At a minimum, track:

tenant ID and principal identity
request ID and correlation ID
requested tool and approved policy path
credential reference/version (not raw secrets)
target Genie space or data endpoint
outcome status, latency, and denial reasons

This enables incident response, tenant reporting, and compliance evidence generation.

Failure Modes to Test Before Launch

Include these in CI/CD and staging validation:

spoofed tenant claim rejected
valid user with wrong tenant context denied
stale or revoked credential blocked
out-of-policy tool call denied with clear error
one-tenant outage does not cascade to others

Negative tests are critical. Most cross-tenant incidents come from incorrect assumptions in edge-path handling, not from primary happy paths.

Common Anti-Patterns

Shared service principal for all tenants – Tenant-scoped credential references from the edge control plane, with rotation and revocation as first-class workflows.
Letting MCP clients choose target tenant without policy checks – Reconcile OIDC claims, principal mappings, and policy state; deny when tenant context cannot be proven.
One policy path for every agent type – Explicit per-tenant allowlists and differentiated policies where agent classes differ materially.
Deferring audit schema until after launch – Ship minimum dimensions (tenant, principal, tool, policy path, credential ref version, target, outcome) with the integration.
Key rotation only in emergencies – Automated rotation, monitoring, and break-glass with full lineage.

Deployment Roadmap

For teams adopting MCP-based external integration, sequence work so identity, secrets, and policy land before scale – and observability ships with the first production path.

Define tenant claim model and policy schema
Implement an edge control plane with secret reference patterns
Add policy enforcement and deny-by-default routing
Integrate tenant-scoped Genie and Unity Catalog targets
Add comprehensive observability and negative tests
Run controlled rollout with tenant-level throttles

Final Takeaway & What's Next

Part 1 helped you choose the right isolation architecture. Part 2 showed how tenant-scoped Genie spaces create an AI boundary aligned to least privilege. In Part 3 we extended that boundary to external agents in a powerful and safe way through MCP.

Teams that operationalize this boundary and preserve tenant context end-to-end – with identity-first routing, tenant-scoped credentials, strict policy enforcement, and full audit lineage – can adopt agentic AI at scale without compromising tenant isolation.

Shawn Davison

Shawn is a serial entrepreneur and software architect with 25+ years of experience building innovative technology used by millions worldwide. Beyond transforming concepts into realities, Shawn is an IRONMAN Triathlete, loves photography, the outdoors, snowboarding, and kitesurfing.