Multi-Tenant Governance for a Shared Client-Intelligence Vector Store Under Financial-Services + Healthcare Isolation/Retention Rules

The question

For a phData client intelligence layer (call transcripts, D&B/PitchBook data), what multi-tenant data governance architectures allow shared embedding/vector stores while meeting financial-services and healthcare data isolation + retention requirements? Context: the CAF restructure brief (2026-06-14) flags this as the single biggest open question — "Can intel live in a shared multi-tenant store, or does each client need isolation + retention rules?" — an active phData project decision blocker that intersects Snowflake row-access policies, Iceberg table isolation, and a likely SOC 2 / HIPAA surface.

What we already know (from the vault)

[[2026-06-15-caf-architecture-decisions-and-meta-council]] — The founder has already locked the CAF tenancy model: "open internal, hard-walled external." Internal data plane is flat + shared (no per-client RLS, no per-client schemas); the entire isolation budget moves to one chokepoint — the external tailored-demo boundary, where a per-client gated URL serves exactly one client's bundle. Datastore = Snowflake VARIANT + a thin typed spine (client_id, phase, contract_id, status, owner). This is the decision context the present question must serve.
[[2026-04-28-snowflake-enterprise-knowledge-management]] — Snowflake's governed-perimeter pitch: Cortex Search runs embeddings + retrieval inside the Snowflake boundary; permissions are RBAC-native, enforced at retrieval via metadata filters keyed to row-access policies. This brief already flagged the honest edge case: cross-tenant SaaS-style isolation where you don't want any cross-tenant chunk leakage even on admin-role compromise is where managed vector DBs with hard tenant separation are still cleaner than Cortex RBAC.
[[2026-06-15-caf-demo-readonly-vs-liveapp-spec]] — The static-export path's security argument: a per-client JSON bundle "literally cannot leak another client's data (it isn't in the bundle)." That is physical isolation at the export seam — the strongest form, and directly relevant to the shared-vs-isolated tradeoff below.
[[2026-01-25-ae-roundup-iceberg-catalog-layer]] — Iceberg + the catalog layer (Russell Spitzer): catalog-level governance and table-level isolation are how open-table-format estates draw tenant boundaries when not living in a single warehouse's RBAC.

What the web says

Snowflake's official multi-tenant primitive is session attributes + row access policies (RAPs). A single Cortex Agent serves many tenants; you pass a tenant value in the agent:run variables block, it becomes a session attribute, and RAPs filter rows so each tenant sees only its own (Snowflake docs — Cortex Agents multi-tenancy).
The load-bearing security control is the immutable session attribute (is_immutable_session_attribute: true). Once set, the tenant context cannot be changed by generated SQL, tool calls, or adversarial prompting — Snowflake rejects the modification. This is what makes a shared store safe: the LLM physically cannot escape its tenant boundary (Brian Hess, "Don't Trust the LLM with Tenant Isolation," Snowflake Builders Blog, May 2026).
Tenant isolation must live at the data layer, never the agent layer — "security should not depend on prompt engineering." When the agent generates SQL dynamically, the traditional middle-tier enforcement disappears, so governance shifts entirely to RAPs + immutable attributes (Hess, ibid.). Three sub-patterns: user-per-tenant (RAP on CURRENT_USER(), finest isolation, highest credential overhead), role-per-tenant (X-Snowflake-Role header), tenant-session-attribute (immutable var; breaks connection pooling unless you COALESCE() immutable + mutable forms).
Cortex Search embeddings stay inside the Snowflake perimeter — embedding generation and query serving run within Snowflake, each customer's data isolated; chunk/document-level control via metadata filtering keyed to the calling role (Snowflake — Cortex Search hybrid search). Same session governance applies.
For external/standalone vector stores, namespace-per-tenant is the structurally-enforced pattern; metadata filtering is the weaker, shared alternative. Pinecone explicitly recommends namespaces "unless you require the ability to query across tenants" — namespaces physically partition records and simplify offboarding (delete the namespace). Metadata filtering shares compute/storage and can't track per-tenant cost or scaling (Pinecone — Multi-Tenancy in Vector Databases).
The pool / silo / bridge framework maps the tradeoff. Silo (dedicated store per tenant) = max isolation, recommended for regulated industries; pool (shared store, tenant_id filtering) = max efficiency; bridge = shared infra + per-tenant overrides. No major framework (GDPR, HIPAA, SOC 2, PCI-DSS) mandates a specific isolation architecture — all four are outcome-based and risk-proportionate; but legal/contractual segregation obligations push toward silo/physical isolation, and SOC 2 Type II / HIPAA BAA / FedRAMP frequently tip regulated tenants to silo (Just After Midnight — pool/silo/bridge; Blaxel — multi-tenant isolation for AI agents).
Per-tenant customer-managed keys + crypto-shredding are the retention/erasure lever. Envelope encryption with a per-tenant KEK lets you satisfy strict erasure by destroying the key (data becomes cryptographically inaccessible) rather than physically deleting rows — useful where a shared store makes row-level deletion expensive ([Blaxel, ibid.]; HIPAA Vault — multi-tenant isolation).

Convergences and contradictions

Strong convergence — enforce isolation in the data layer, never the LLM. Snowflake docs, the Hess Builders piece, and the vault's own KM brief all agree: RAPs / immutable session attributes / namespaces are the boundary; prompt engineering and agent-layer filtering are not security. This holds for both structured rows and embeddings.
Convergence — a shared store can be compliant, but the bar is "structurally enforced + provable at audit." SOC 2 auditors accept shared RLS if paired with robust audit logging and automated isolation tests. The contradiction is with regulated-tenant risk appetite: nothing mandates silo, yet financial-services/healthcare contracts and BAAs routinely demand it, so the architecture decision is driven by client contract terms more than by the regulation text.
Tension with the locked CAF call. CAF's "flat internal, hard-wall external" assumes phData staff are the only internal readers (low regulatory surface) and the real PHI/financial risk lives in client-supplied content (call transcripts may carry PHI; D&B/PitchBook are licensed third-party data with their own redistribution terms). If client intel ever carries regulated client data, "flat internal" needs at minimum classification tagging + retention rules per source, even if not full per-client RLS.

Synthesis for RDCO

The decision framework is a 2x2 on two independent axes, not one shared-vs-isolated switch. Axis 1 = isolation (shared store with structurally-enforced row/namespace boundaries vs physically separate stores per client). Axis 2 = retention (uniform policy vs per-source/per-client retention + erasure rules). CAF has already chosen shared on axis 1 for the internal plane, which is the right default for a 12-engineer internal tool: a shared Snowflake catalog with a client_id spine, Cortex Search for embeddings inside the perimeter, and RAPs only if/when an internal-isolation need appears. The honest caveat from the 2026-04-28 KM brief still stands — if a single admin-role compromise leaking all clients' intel is an unacceptable outcome (it may be for transcripts carrying PHI or for licensed PitchBook data under redistribution terms), then the shared store needs either per-client namespaces (silo on axis 1) or per-tenant CMK + crypto-shredding to bound the blast radius. For a phData-internal discovery tool this is likely acceptable as shared; the moment the same store backs an external, client-facing surface, the calculus flips to silo.

For the embedding/vector layer specifically, the cleanest CAF-aligned pattern is Cortex Search inside Snowflake, governed by the same session attributes + RAPs as the typed spine. This keeps embeddings in one governed perimeter (no permissions duplication across a separate Pinecone/Weaviate that gets audited independently), inherits Snowflake Horizon lineage, and lets the immutable session attribute be the hard tenant boundary if internal isolation is ever required. If a regulated client contractually requires hard physical separation that Snowflake RBAC "handles awkwardly" (the edge case the KM brief named), the fallback is namespace-per-tenant in a dedicated managed vector DB or a per-client Iceberg table set with catalog-level isolation — chosen per-client, not as the default. Iceberg table-per-client under a governed REST catalog is the open-table-format equivalent of silo, and the right reach when intel must live outside one warehouse's RBAC.

Retention is the axis CAF's locked decision is currently silent on, and it's where the real financial-services/healthcare exposure sits. Call transcripts can carry PHI; D&B/PitchBook are licensed feeds with contractual retention/redistribution limits. The recommended move is to tag every record in the VARIANT spine with source, sensitivity_tier, and retention_class at ingest (cheap to add now to the thin typed spine already designed), then drive retention via Snowflake's native time-based policies / dynamic tables and crypto-shred by per-source KEK where erasure-on-demand is contractually required. This satisfies the "outcome-based" posture of HIPAA/SOC 2 without forcing per-client physical isolation, and keeps the flat-internal model intact.

What this implies for the CAF decision blocker: the answer is "shared store is fine for the internal plane — the question was mis-framed as binary." Isolation and retention are separable; CAF can keep shared on isolation and still meet financial-services/healthcare requirements by adding (a) source/sensitivity/retention tagging to the spine, (b) Cortex Search in-perimeter embeddings, (c) immutable-session-attribute RAPs available but not default, and (d) a documented per-client silo fallback (namespace or Iceberg-table-per-client) triggered only by a contract that demands physical separation. The external demo boundary remains the one hard wall, exactly as locked. This unblocks the project: no internal RLS rebuild required, retention handled by tagging + policy, and a clear escalation path when a regulated client's contract demands more.

Open follow-ups

Do any in-scope CAF clients' call transcripts actually contain PHI or NPI, and do D&B/PitchBook licenses impose retention/redistribution limits that force per-source retention rules? (Drives whether tagging is mandatory now vs later.)
Does phData's existing Snowflake estate carry a HIPAA BAA / SOC 2 Type II scope that the CAF catalog would inherit, or would CAF expand the audit boundary?
What is the per-client erasure SLA in any CAF client contract? (Determines whether crypto-shred-by-KEK is needed vs row-level delete being sufficient.)
Cortex Search service-per-business-unit vs one mega-index: at CAF's Fortune-2000 scale, does blast-radius containment argue for multiple Cortex Search services even within the flat-internal model?
If the external demo goes "live app" (per the read-only-vs-liveapp fork), does the OLTP serving store (Postgres/RDS/Aurora) need its own tenant-isolation design, or does the static per-client bundle export remain the isolation seam?
Iceberg-table-per-client under a REST catalog — what is the concrete governance + cost profile vs Snowflake-native, for the silo fallback case?

[[2026-06-15-caf-architecture-decisions-and-meta-council]]
[[2026-04-28-snowflake-enterprise-knowledge-management]]
[[2026-06-15-caf-demo-readonly-vs-liveapp-spec]]
[[2026-01-25-ae-roundup-iceberg-catalog-layer]]
[[2026-06-14-caf-restructure-organizing-brief]]

Sources

Vault:

[[2026-06-15-caf-architecture-decisions-and-meta-council]] — rdco-vault/01-projects/phdata/2026-06-15-caf-architecture-decisions-and-meta-council.md
[[2026-04-28-snowflake-enterprise-knowledge-management]] — rdco-vault/06-reference/research/2026-04-28-snowflake-enterprise-knowledge-management.md
[[2026-06-15-caf-demo-readonly-vs-liveapp-spec]] — rdco-vault/01-projects/phdata/2026-06-15-caf-demo-readonly-vs-liveapp-spec.md
[[2026-01-25-ae-roundup-iceberg-catalog-layer]] — rdco-vault/06-reference/2026-01-25-ae-roundup-iceberg-catalog-layer.md
[[2026-06-14-caf-restructure-organizing-brief]] — rdco-vault/01-projects/phdata/2026-06-14-caf-restructure-organizing-brief.md

Web:

multi tenant governance shared vector store