When AI Agents Query Regulated Data, Isolation Isn’t Optional

Every enterprise SaaS platform claims multi-tenant isolation. For most applications, a data leak between tenants is embarrassing. For a regulatory platform serving pharmaceutical companies, it’s a compliance violation that could affect drug approval timelines, expose proprietary formulation data, or breach confidentiality agreements between competing sponsors.

When you add AI agents to the mix, the stakes increase. An AI agent querying data doesn’t have the contextual awareness a human user does. A human logging into Tenant A’s workspace intuitively knows they shouldn’t see Tenant B’s submissions. An AI agent making API calls has no such intuition — it will query whatever data it’s allowed to access.

This is why AI security in multi-tenant regulatory systems must be architectural, not conventional.

Why “Just Add a WHERE Clause” Fails

The simplest multi-tenant pattern is a shared database with a TENANT_ID column, and every query includes WHERE TENANT_ID = ?. This works until it doesn’t:

  • A developer writes a new endpoint and forgets the WHERE clause. Data from all tenants is returned.
  • An ORM-generated query doesn’t include the filter. A batch job processes records across tenants.
  • A debugging session runs a query without the filter. Sensitive data appears in log files.

These aren’t hypothetical — they’re well-documented patterns in multi-tenant security incidents across industries. The WHERE clause is a convention. Conventions break when humans (or AI agents) don’t follow them.

DnXT’s Four-Layer Isolation Architecture

Our approach to multi-tenant isolation uses four layers, each enforcing tenant boundaries independently:

Layer 1: HTTP Header Inspection

Every inbound request is inspected for tenant identity. Two filters run in sequence:

  • TenantBodyPeekFilter (priority +5) — runs first, peeks into the request body for tenantID, tenant, or tenantId fields as a defense-in-depth backup.
  • TenantContextFilter (priority +10) — resolves the canonical tenant from the X-Tenant-ID header, falling back to session, hostname, or the body-peek result.

For the customer-facing MCP server, tenant identity is derived from the API key. The caller cannot specify a different tenant. This is a server-side enforcement — the MCP tool schema doesn’t expose a tenant parameter.

Layer 2: ThreadLocal Context

Once resolved, the tenant ID is stored in a TenantContext ThreadLocal variable for the duration of the HTTP request. All downstream code within that request thread reads from this context. Explicit tenantID parameters in method signatures take precedence over the ThreadLocal — but if neither is available, the system throws an IllegalStateException.

There is no silent fallback. The system does not default to TenantAdmin or any other tenant. If tenant identity cannot be determined, the request fails loudly.

Layer 3: Database Schema Routing

Each tenant has its own Oracle schema: TENANTADMIN, ALKERMESSBX_COM, DNXTCOMPLIANCE. Hibernate routes queries to the correct schema based on the resolved tenant. Even if application-layer isolation failed (which the first two layers prevent), the database schemas provide hard boundaries — a query against ALKERMESSBX_COM physically cannot return rows from TENANTADMIN.

Layer 4: Permission Enforcement

Within a tenant, users (including AI service accounts) have permission sets. The workflow engine’s upsertAndAdvance endpoint accepts a permissionCode parameter. If the user lacks that permission, the response is 403 FORBIDDEN. If the permission service is unreachable, the response is 503 SERVICE UNAVAILABLE — fail-closed, not fail-open.

Cross-Service Propagation

In a microservices architecture, a single user request may fan out to multiple services. Each hop is an opportunity for tenant context to be lost. DnXT addresses this with TenantHeaderInjector — a wrapper around RestTemplate that automatically injects the X-Tenant-ID header on every outbound service-to-service call.

This means if the workflow service calls the document service, which calls the audit service, tenant identity is propagated through the entire chain without any service needing to manually pass it.

The Validated Component: TenantScopedQuery

For database queries, we use TenantScopedQuery — a Tier-1 GxP-critical validated component. Its rules are simple and non-negotiable:

  • Every query requires a mandatory tenantId parameter. There is no overload without it.
  • The TENANT_ID filter is appended server-side, not by the caller.
  • All parameters are bound (parameterized queries), never concatenated into SQL strings.
  • Post-query filtering verifies that returned records match the expected tenant (defense-in-depth).
  • Column lists are explicit (GLB_DATA_COLUMNS), never SELECT *.

Honest Context: What This Is and Isn’t

Multi-tenant isolation is table stakes for any enterprise SaaS regulatory platform. DnXT isn’t unique in having it. Veeva, IQVIA, and every serious enterprise vendor implements tenant isolation.

What DnXT contributes to the conversation is how this isolation extends to AI agent interactions specifically. When an AI agent connects via MCP:

  • Tenant is resolved from the API key, not from the agent’s request
  • The agent’s tool schema doesn’t include tenant parameters — there’s nothing to manipulate
  • Every downstream query is tenant-scoped by the architecture, not by the agent’s behavior
  • Audit records capture both the tenant and the source (mcp-open-gxp), making cross-tenant access auditable

The customer-facing MCP layer that extends this to external AI agents is currently in design phase — not yet deployed. The four-layer architecture underneath it is running in production.

In a multi-tenant system, the question isn’t whether you filter by tenant. It’s whether your system can produce correct results if a developer, an AI agent, or a misconfigured service forgets to filter. Architectural enforcement means the answer is yes.

This article was written by the DnXT Solutions team. We’ve aimed to present our architecture accurately. If we’ve gotten something wrong about another vendor’s isolation approach, we welcome corrections at se******@***********ns.com.