Tenant Isolation for AI Support Systems: A Layered Architecture

Tenant isolation for AI support is the set of controls that keeps one customer workspace's conversations, documents, memories, credentials, tool results, and operator data from appearing in another workspace's request or response. It is not a prompt telling the model to respect privacy. It is an end-to-end property of the system that chooses data before a model call, constrains actions during the call, and filters what survives afterward.

The boundary is harder than it looks because an AI support answer crosses more surfaces than an ordinary record lookup. A single turn may resolve an identity, load a conversation, retrieve text and vectors, select agent memory, apply workspace instructions, call a model provider, run an authenticated API check, write debug metadata, and hand the case to an operator. A missing tenant check anywhere in that path can turn a relevant answer into a cross-customer disclosure.

Start with a concrete tenant boundary. In developer support, a tenant is usually a company or workspace that owns sources, customer conversations, agents, credentials, integrations, roles, and audit history. Users inside that workspace may still have different permissions, but the first non-negotiable rule is that no user, public channel, job, or model turn can cross into another workspace unless a deliberately authorized platform operation does so.

Authentication answers who presented a credential. Authorization answers what that identity may do. Tenant isolation adds another question: which customer's resources can this execution ever address? AWS's SaaS guidance emphasizes that a user can be authenticated and authorized for an application feature while a missing tenant constraint still exposes another customer's object. The tenant must therefore participate in every resource decision, not merely appear as a label in a session.

Resolve tenant context from a trusted credential or server-side relationship. An authenticated operator token can resolve to a workspace membership. A public widget key can resolve to a workspace and a particular agent. A scheduled job can carry a server-created workspace identifier from the row it is processing. What should not happen is accepting a customer-supplied `workspaceId` and treating it as authority merely because the value is well formed.

Represent that context as a small immutable execution object: tenant ID, actor ID and kind, permitted roles or scopes, channel, agent identity, and a correlation ID. Pass it through route handlers, retrieval, tool calls, persistence, and telemetry. Re-resolve or revalidate it at trust-boundary crossings instead of allowing downstream code to replace it from a request body, document, model output, or tool argument.

A pooled database can support strong logical isolation, but the tenant key must be part of the data model. Workspace-owned root records should carry a non-null tenant identifier. Child records such as messages or chunks should either carry the same identifier or have a mandatory parent relationship that can prove ownership. Uniqueness rules often need the tenant key too: a conversation key, source slug, external event ID, or agent name that is unique globally can reveal existence or create collisions across customers.

Enforce the boundary in more than one layer. Application queries should state the tenant predicate explicitly, including reads by ID. Database row-level security can then provide a backstop for roles subject to those policies. PostgreSQL applies `USING` expressions to visible existing rows and `WITH CHECK` expressions to proposed inserts or updates; when row security is enabled and no applicable policy exists, access defaults to denied. Parent-scoped child policies must cover reads and writes, not only the table that carries the tenant ID directly.

Know when the backstop is absent. PostgreSQL table owners and roles with `BYPASSRLS` normally bypass row security, and Supabase documents that service credentials can do the same. A server using such a role cannot cite RLS as its primary isolation control. It needs mandatory workspace filters, ownership checks before child access, tightly contained service credentials, and negative tests that inspect the actual query behavior.

Retrieval-augmented generation adds an authorization problem before it adds an answer-quality problem. Ingestion must attach tenant ownership to sources, documents, chunks, embeddings, and derived metadata. Retrieval must select only sources authorized for the active workspace and, when applicable, the selected support agent. Similarity ranking should run inside that authorized candidate set or be followed by a hard allowlist intersection before any content enters the prompt.

Do not ask the vector model to infer ownership from content. Do not retrieve globally and trust a metadata hint in the prompt. Do not assume that an unreferenced document is harmless because the final answer did not cite it. Once cross-tenant text enters the context window, confidentiality has already failed; the model may paraphrase it, use it to choose a tool, or expose it through debug traces even if the visible answer looks generic.

The same rule applies to keyword fallback, related-chunk expansion, reranking, and citation hydration. Every secondary fetch must preserve the authorized source set. A safe semantic search returning no matches should degrade to tenant-scoped keyword retrieval or missing-context behavior, not a workspace-wide or global fallback. Relevance can narrow authorized data; it cannot authorize data.

Conversation history and agent memory deserve their own review. A conversation identifier must be scoped to the workspace and verified against the requesting customer or operator before its messages are loaded. Public channels need additional binding: a browser secret, verified customer identity, channel account, or named-agent key should not be replayable against a conversation created under a different boundary.

Long-term AI memory increases the blast radius of a mistake. Store tenant and agent ownership with every memory record, retrieve it through the same boundary as current source context, and avoid treating a previous answer as unquestioned truth. A memory can preserve outdated guidance or customer-sensitive content even when it belongs to the correct tenant. Retention, deletion, correction, provenance, and revalidation are therefore part of isolation's integrity side.

Prompt instructions are not an authorization layer. OWASP's prompt-injection guidance notes that direct or indirect input can alter model behavior and that retrieval alone does not eliminate the risk. A hostile support message or ingested document may demand another customer's records, hidden instructions, wider search, or a privileged tool call. The model must be unable to satisfy that request because unauthorized data and capabilities never entered its execution envelope.

Minimize the provider payload to the evidence needed for this turn. Redact credentials and sensitive customer text before embeddings and generation. Separate customer-visible citations from operator-only source metadata. Keep system instructions, provider routing, internal confidence traces, and service credentials out of response-shaped objects. If the provider call fails, return a sanitized classification rather than its raw request or diagnostic body.

Tools turn confidentiality failures into integrity failures. An AI support system may test an endpoint, look up an account, update a ticket, send a reply, or create an issue. Each tool needs a server-side policy that binds its resource, credential, method, and result to the active tenant. The model may propose arguments, but code must validate ownership and capability before execution.

Store tenant credentials separately from indexed documentation and conversation content. Select them by trusted workspace and source ownership, decrypt only on the server at execution time, and return a redacted outcome rather than the secret or full internal exchange. Apply least privilege: a read-only health check and a write-capable production credential should not share the same default execution policy.

Make consequential actions harder than informative ones. Require an explicit customer or operator request for live checks, keep mutating methods off by default, use documented example bodies rather than invented values, enforce SSRF-safe destination rules, cap payloads and time, and record a tenant-scoped audit event. A prompt-injected instruction should meet the same authorization and confirmation barriers as a manually crafted API request.

AI support arrives through channels with different identity strength. An authenticated operator inbox can derive workspace membership from a user session. Email and community connectors resolve through installation or routing records. A public chat widget often begins with a publishable workspace key, which identifies the destination but should not grant general data access. Reading history or attaching verified customer details needs a stronger conversation or identity proof.

Keep public access route-specific. Resolve the workspace from the key, apply rate and payload limits, constrain queries to that workspace, and return generic not-found behavior for unknown or mismatched identifiers. If one workspace has multiple named agents or widgets, bind each conversation to the agent that created it so one public key cannot enumerate another agent's history or inherit its private source attachments.

Operators need logs to investigate failures, but observability data is itself tenant data. Retrieval labels, prompt excerpts, tool previews, message bodies, customer identifiers, costs, and exception details can all reveal private context. Store the tenant and actor on each event, apply the same read permissions as the product surface, redact recursively, and avoid metric labels with unbounded customer content.

Platform administration is the deliberate exception that proves the rule. If staff can inspect or impersonate a workspace for support, require a separate privileged control plane with named grants, reason, mode, expiry, actor identity, target tenant, and immutable audit history. Read-only access should fail closed on writes. Tenant-visible activity can be mirrored in a safe form without exposing the platform's global security log.

Positive tests show that a customer can use the product. Isolation tests prove that the same request fails when one element belongs to someone else. Build fixtures for at least two tenants with intentionally similar document titles, endpoint paths, conversation keys, customer emails, and questions. Then swap IDs, public keys, agent IDs, source attachments, cache entries, queue messages, and tool targets one at a time.

Assert more than the HTTP status. Verify that the unauthorized row was not read, the vector match was not passed to reranking, the model was not called with foreign text, the tool was not invoked, no citation or debug field contained the other tenant's label, and no audit event landed in the wrong workspace. A safe 404 after a cross-tenant read is still a failure if sensitive content reached an internal prompt or log first.

Repeat the matrix for list and aggregate routes, pagination, exports, realtime subscriptions, retries, deletion, membership changes, impersonation, disabled agents, zero-source agents, provider failures, and concurrent jobs. NIST's Generative AI Profile emphasizes testing and risk management across the lifecycle; isolation belongs in pre-deployment gates and recurring regression suites, not only in a one-time penetration test.

Woes implements a pooled, workspace-scoped model, so its strongest claims are about layered logical isolation rather than dedicated infrastructure per customer. Authenticated workspace routes resolve the caller through `getRequestAccount`, derive the active workspace from profile or accepted membership data, and use that server-resolved value for route queries. Workspace-owned records carry `workspace_id`; child source and conversation records are linked through parents.

The server uses a Supabase service-role client for protected operations. Because that role bypasses RLS, Woes's own migrations describe database policies as a defense-in-depth backstop for future authenticated-role access, not as the control that makes service queries safe. The account, support-agent, and widget paths checked for this article explicitly filter by the resolved workspace, validate parent ownership where they traverse child data, and keep the service credential server-side. This distinction is important: saying “RLS is enabled” without naming the bypass path would overstate the design.

The support-agent retrieval path first selects ready customer-facing sources from the active workspace. A named agent receives an attached-source allowlist; an explicit empty set yields no context, and semantic results are intersected with the authorized source map before prompt assembly. Public widget routes resolve a workspace and optional named agent from a publishable key, scope conversation reads to that workspace, and reject or hide history bound to another agent key. Stored API credentials remain separate from source content and are applied server-side through the guarded live-call path, with redacted results returned to agent context.

These controls do not prove every deployed database policy, environment setting, integration journey, or future route automatically. They define the implementation contract that tests and release review must keep checking. The useful product promise is not that one mechanism makes Woes isolated; it is that workspace context is preserved across request resolution, data access, retrieval, widget history, credentials, and customer-visible output.

A design review should be able to trace one request without hand-waving. Ask where tenant context originates, how it is protected from client replacement, which stores and queues receive it, what happens under service-role or administrator access, how retrieval limits candidate data, which tools can act, what reaches the model provider, and where logs are authorized. If an answer depends on the model being cooperative, the boundary is incomplete.

Prefer controls that fail closed and compose. A missing named-agent runtime should hand off instead of widening retrieval. An empty source scope should produce missing context instead of a global search. An invalid widget key should reveal nothing. A write tool without explicit policy should not run. A background job without trustworthy tenant context should stop before reading customer data.

Tenant isolation for AI support is ultimately an evidence problem. Architecture diagrams define intended boundaries; query constraints, database policies, credential design, negative tests, audit records, and production checks show whether those boundaries hold. Build the proof alongside the agent, because adding isolation after retrieval, memory, and tools are already shared is both harder and riskier.