A research institution is already multi-tenant: PIs, labs, studies, cohorts. AI does not remove those boundaries. It makes them more dynamic, and a study boundary has to survive the AI.
Part of the AI Security for Research Institutions guide series.
Universities and research centers routinely manage hundreds of projects at once.
Different principal investigators.
Different grants.
Different participant populations.
Different data-use agreements.
Different collaboration boundaries.
Traditional systems often represent those boundaries using permissions, schemas, collections, folders, and project roles.
AI agents can create a new path around those boundaries because the agent itself becomes an intelligent retrieval and orchestration layer.
Imagine a research AI assistant used by multiple laboratories.
Study A contains controlled-access genomic data.
Study B contains participant interview data.
Study C contains unpublished experimental results.
The AI platform indexes all three.
A human user from Study B submits a question.
If retrieval is not strongly scoped, the system may return information from Study A or Study C.
The user may not even know that it happened.
That makes cross-study leakage particularly dangerous.
A common architecture uses a study_id filter in retrieval queries.
That can be useful.
But if the application constructs the filter from model-generated instructions, the model may become part of the authorization path.
An attacker may manipulate the agent into changing the filter.
This creates a critical principle:
authorization metadata should be enforced by the server-side security boundary, not trusted solely to the model or a user-controlled query parameter.
A robust research AI architecture should isolate at least:
Study records and documents must remain within authorized study scope.
Queries must be evaluated against actual identity and study membership.
Persistent agent memory should not silently mix information across studies.
Service accounts should not erase the distinction between users and projects.
One agent should not automatically gain the authority of another.
Persistent AI memory can create unexpected leakage.
Suppose an agent helps Study A today and Study B tomorrow.
If both workflows write into the same semantic memory store, information from Study A could later influence Study B.
The system may not show the original source.
The AI may simply “remember” the information.
That makes memory isolation a research-data control.
A practical approach is to scope memory by:
Imagine:
Orchestrator → DataAgent → AnalysisAgent → ActionAgent
The Orchestrator is allowed to work on Study A.
The DataAgent retrieves Study A data.
The AnalysisAgent receives that data.
The ActionAgent can write to a system with broader authority.
If trust context is lost during the handoff, the final agent may not know the data originated from a restricted study.
The answer is to preserve provenance and trust context across agent boundaries.
Every chunk in a research knowledge base should carry enough metadata to support authorization.
Useful fields include:
That information must be enforced at retrieval.
Do not rely on the model to interpret it correctly every time.
Institutions can think of study isolation as a logical data firewall.
Before AI context is assembled, the system should determine:
Who is asking?
Which study are they acting within?
What task are they performing?
What data is allowed for that task?
What action can follow?
Only then should retrieval and execution proceed.
A researcher asks an innocent question about a study.
The agent retrieves a document.
The document contains a hidden instruction telling the agent to query another study.
The agent changes its retrieval behavior.
The second study's data enters the context.
The agent summarizes the data and sends it to an external endpoint.
The entire sequence may appear as a normal AI interaction in application logs.
But it crossed four boundaries:
study → retrieval → agent authority → external channel.
That is why cross-study testing must follow the complete attack path.
Research institutions should explicitly test:
A successful “no leakage” test proves very little if the test did not exercise adversarial conditions.
Before deploying shared AI infrastructure:
The research environment is already multi-tenant.
AI does not remove those boundaries.
It makes them more dynamic.
The security goal is therefore not merely to prevent database-level cross-tenant access.
It is to prevent an autonomous system from turning legitimate access in one research context into unauthorized access in another.
A study boundary should survive the AI.
HexTyx tests AI agents against live, LLM-backed applications that use synthetic data in controlled environments. Our record covers 28 domain applications. These are not research-institution deployments and no real participants or studies were involved, but the failure patterns map directly onto the boundaries in this guide.
Memory and retrieval are real cross-boundary channels. In a synthetic memory-assistant app (Mneme), tested against Claude Haiku 4.5, one user’s session recalled and re-executed a fact written under another user’s account. It was the most severe result in that batch. In a synthetic multi-tenant CRM (Mercury), an inbox-processing scheduler sent an exfiltration email to an external address before any user interaction.
Neither required breaking a database boundary. The agent layer carried information across a line the storage layer still enforced, which is why this guide treats memory, retrieval and delegation as isolation boundaries of their own.
Run the free playground scanner against your own AI application, or read the other guides in this series.