When Software Queries Regulated Data, Separation Isn’t Optional
Every enterprise platform claims it keeps customers’ data separate. For most applications, a leak between customers is embarrassing. For a regulatory platform serving pharmaceutical companies, it is a compliance violation that could affect approval timelines, expose proprietary formulation data, or breach confidentiality agreements between competing sponsors.
Add AI assistants to the picture and the stakes rise. A person signed into Sponsor A’s workspace knows instinctively that they should not be looking at Sponsor B’s submissions. Software has no such instinct. It will retrieve whatever it is permitted to retrieve, and it will do so confidently.
This is why separation in a multi-tenant regulatory system has to be built into the foundations, rather than left to good practice.
Why “Just Remember to Filter” Fails
The simplest way to keep customers apart is to hold everyone in one database, label every record with its owner, and filter by that label every time you ask a question. This works until it doesn’t:
- A developer builds a new screen and forgets the filter. Everyone’s data comes back.
- An automatically generated request leaves the filter out, and an overnight job processes records belonging to several customers at once.
- Somebody investigating a problem runs a request without the filter, and confidential data ends up in a log file.
None of these are hypothetical. They are well-documented causes of data separation incidents across industries. Filtering every request is a convention, and conventions depend on everyone remembering them, every time, forever.
DnXT’s Four Layers of Separation
Our approach uses four layers, each of which keeps customers apart on its own, without relying on the others:
Layer 1: Establishing who is asking
Every incoming request is inspected to establish which customer it belongs to. Two independent checks run in sequence, so that if one cannot determine the answer, the other still can.
Where an AI assistant connects to the platform, the customer is determined from the credential it was given. The assistant cannot ask on behalf of a different customer, because there is nowhere for it to say so — the option is simply not offered.
Layer 2: Carrying that identity through the request
Once established, the customer’s identity is held for the life of that request, and everything the platform does next reads it from there rather than working it out again.
If the identity cannot be established at any point, the request fails immediately and visibly. There is no quiet fallback and no default. This matters more than it sounds: a system that guesses when it is unsure will guess wrong eventually, and it will do so silently.
Layer 3: A separate database per customer
Each customer’s information lives in its own database. Requests are directed to the right one based on the identity established in Layer 1.
This is the layer that makes the others belt-and-braces rather than load-bearing. Even if everything above it failed, a request against one customer’s database physically cannot return another customer’s information. There is nothing there to return.
Layer 4: Permissions within the customer
Inside a customer’s workspace, people — and any automated accounts — hold permissions. The platform checks them before allowing any action.
If the service that answers permission questions cannot be reached, the request is refused rather than allowed. That direction is deliberate: error handling that allows the action when something goes wrong turns every technical hiccup into a silent grant of access.
Keeping Identity Intact Across the Platform
A modern platform is made of many connected parts, and a single user request may pass through several of them. Each handover is an opportunity to lose track of who is asking.
DnXT attaches the customer’s identity automatically to every internal request, so if one part of the platform asks another, which asks a third, the identity travels the whole way without anyone having to remember to pass it along.
One Validated Route to the Data
Every request for stored information goes through a single validated component, treated as critical to GxP compliance. Its rules are simple and not negotiable:
- Every request must name the customer. There is no version of it that does not.
- The customer restriction is applied by the component itself, not by whatever asked it.
- Values supplied by a user are always passed separately and never pasted into the request, so nothing a user types can change what the request does.
- What comes back is checked again, on the way out, to confirm it belongs to the expected customer.
- Requests ask for named information only — never “give me everything” — so nothing unexpected can be returned.
Honest Context: What This Is and Isn’t
Keeping customers’ data separate is table stakes for any serious enterprise regulatory platform. DnXT is not unique in doing it. Veeva, IQVIA, and every serious enterprise vendor separates customer data.
What DnXT adds to the conversation is how that separation extends to AI assistants specifically. When an assistant connects:
- The customer is determined from its credential, not from anything it says
- Nothing in what the assistant can ask for mentions a customer — there is nothing to manipulate
- Every request underneath is restricted by the platform’s own design, not by the assistant behaving well
- The audit record captures both the customer and whether the action came from a person or from software, so any attempt to reach across is visible after the fact
The customer-facing layer that extends this to external AI assistants is currently in design, not yet deployed. The four layers underneath it are running in production today.
In a shared platform, the question is not whether you separate customers. It is whether your system still behaves correctly when a developer, a piece of software, or a misconfigured component forgets to. Building it into the foundations means the answer is yes.
This article was written by the DnXT Solutions team. We’ve aimed to present our approach accurately. If we’ve gotten something wrong about another vendor’s approach, we welcome corrections at se******@***********ns.com.
