What Is AI Scientist Studio? AI Agents Inside Your TRE
AI Scientist Studio is Lifebit’s environment for building and running AI research agents inside a data custodian’s own governed Trusted Research Environment (TRE). Agents use any foundation model the researcher chooses, execute on compute in the custodian’s cloud account, inherit the permissions of the person running them, and can only release results that pass Lifebit’s Airlock output controls. Patient-level data never moves, and the chat history, outputs, and audit trail stay inside the environment.
This explainer is written for the people who will be asked to approve it: biobank CTOs, heads of research data at pharma companies, and the governance teams who sit beside them. It covers why the product exists, how it is built, what an agent is made of, how governance works, and what to ask any vendor before letting AI agents near sensitive health data. The product page is at AI Scientist Studio.
Why AI Scientist Studio exists
2026 has been the year AI science workbenches went mainstream. Google has Co-Scientist. OpenAI launched GPT-Rosalind in May and Rosalind Workbench on 28 August. Anthropic launched Claude Science on 30 June. These are capable tools, and they share one design assumption: the work happens in the vendor’s cloud, so the data has to get there.
For public literature, open datasets, and a company’s own non-sensitive research, that assumption is reasonable. For governed health data, it usually is not. A national genomics program, a hospital research network, or a biobank holds data under consent terms, data sharing agreements, and residency rules that were written around a simple principle: approved researchers come to the data, and the data does not go to them. Uploading patient-level records into a third-party AI service breaks that principle regardless of how good the model is.
The Trusted Research Environment model was built to solve exactly this problem for human researchers. The Five Safes framework from the UK Office for National Statistics (ONS) asks whether the project, the people, the setting, the data, and the outputs are safe. AI Scientist Studio is Lifebit’s answer to what happens when the researcher is partly an agent. Safe Settings, Safe Outputs, and Safe Projects have to hold when an agent is doing the analysis, not just when a person is. The practical conclusion is to bring the model to the data, which is what the product does. For background on the broader category, see Lifebit’s guide to the agentic federated TRE.
How it works: the four layers
AI Scientist Studio splits into four layers. Two run on the Lifebit Platform and two run in the customer’s own cloud. That split is the core of the design, because it decides where sensitive data can and cannot go.
| Layer | Where it runs | What it does | Why it matters |
|---|---|---|---|
| Intelligence | Lifebit Platform | Defines agents and orchestrates their reasoning, using the foundation model the researcher selects | Model choice stays open, and models can be swapped without rebuilding agents |
| Governance | Lifebit Platform | Applies permissions, per-workspace AI enablement, Airlock output controls, and audit | The custodian’s rules apply to agents the same way they apply to people |
| Execution | Customer’s cloud | Runs the agent’s analysis on compute inside the custodian’s governed environment | Analysis happens next to the data, so patient-level records are never copied out |
| Storage | Customer’s cloud | Holds the data, plus chat history, outputs, and audit trails | Everything an agent touches or produces stays under the custodian’s control |
The result is that the parts which need to be shared (agent definitions, governance logic) live on the platform, while the parts which must stay local (data, compute, and every record of what happened) live with the custodian. This is the same federated pattern Lifebit uses for its federated Trusted Research Environment: compute moves to the data, and data never leaves the source.
What an agent is made of
An agent in AI Scientist Studio is a configured worker with five components. Each one is something a research team can inspect and a governance team can review.
- Instructions. The task definition and working rules for the agent, written in plain language.
- Reasoning model. The foundation model that does the thinking. Researchers can bring their own or choose from GPT, Gemini, Claude, or open-source models, and can swap models later.
- Skills. The scientific tools the agent is allowed to call, such as analysis methods or pipelines.
- Connectors. The routes to data sources the agent can reach, which are still bounded by the user’s permissions.
- Knowledge bases. Reference material the agent can draw on, such as protocols, data dictionaries, or study documentation.
Model agnosticism matters more than it might seem. Foundation models change quickly, and a custodian that locks its research workflows to one model vendor inherits that vendor’s roadmap, pricing, and hosting decisions. Separating the agent’s definition from its model means a team can compare models on the same task or move to a newer model without redesigning its governance. Dr. Maria Chatzou Dunford, Lifebit’s CEO, put the principle in one line: “Bring any AI model to the data.”
How governance works
The governance question for any AI agent is simple to state: what can it see, what can it do, and what can it take out? AI Scientist Studio answers each of those with controls that already exist for human researchers in a TRE.
Agents inherit the user’s permissions
An agent runs with the permissions of the person who launched it. It cannot see anything that user cannot see. There is no separate service account with broader access, and no path for an agent to query a dataset its user has not been approved for. For a data access committee, this means existing approvals remain the unit of control.
Only approved results leave, through the Airlock
Agents can produce outputs inside the environment, but nothing leaves until it passes Lifebit’s Airlock output controls. This is the Safe Outputs principle applied to agent work. An agent that generates a table, a figure, or a model summary is subject to the same export review as a human researcher. Lifebit’s explainer on what an automated airlock is covers how that review works in practice.
Audit trails and chat history stay inside
Every conversation with an agent, every output it produces, and the complete audit trail of its actions are stored inside the custodian’s environment. That matters for two reasons. The conversation itself can contain sensitive detail, so sending it to an external service would be a leak in its own right. And a custodian cannot govern what it cannot reconstruct, so a full local record is what makes review and incident investigation possible.
AI is enabled per workspace
AI is switched on workspace by workspace. Each custodian decides where agents are allowed and where they are not. A biobank might enable agents in a workspace for cohort discovery on a well-understood dataset while keeping them off in a workspace holding a more sensitive collection. That keeps the decision with the organization accountable for the data.
Federated runs across multiple sites
Many research questions need more data than any single custodian holds. Rare disease work, multi-ancestry genomics, and pharma evidence generation routinely span institutions and countries. AI Scientist Studio agents can run federated across multiple sites. Each site’s analysis executes inside that site’s environment under that site’s rules, and only approved results come back through each Airlock.
This avoids the familiar trade-off between scale and control. The alternative is pooling data into one place, which typically means long data transfer agreements and a central copy that every contributor has to trust. Federation lets each site stay the custodian of its own records. Lifebit’s guide to running multi-site studies without moving data explains the underlying pattern.
Named use cases
Lifebit has named four areas where agents are intended to work:
- Cohort discovery. Translating a research question into cohort criteria and finding matching participants within approved data.
- Deep phenotyping. Characterizing participants in detail across the clinical, genomic, and other data a custodian holds.
- Analysis. Running statistical and scientific methods using the skills an agent has been given.
- Evidence generation. Assembling findings into outputs that can pass review and be used downstream.
These run on the same platform Lifebit provides to organizations including Genomics England, CanPath, the Singapore Ministry of Health, and Boehringer Ingelheim, and to the NIHR BioResource. Across its customers, Lifebit’s platform covers more than 275 million patients in over 30 countries.
An illustrative walk-through
The following is a hypothetical example, written to show the sequence of steps. It does not describe a real project, and it reports no results.
- Setup. A pharma data lead has approved access to a workspace at a biobank where the custodian has enabled AI. She creates an agent with instructions to support a cohort feasibility question, selects a reasoning model, attaches the relevant analysis skills, connects the approved datasets, and adds the study protocol as a knowledge base.
- Question. She asks the agent to identify participants meeting a set of inclusion and exclusion criteria and to describe the cohort’s key characteristics.
- Execution. The agent works on compute inside the biobank’s cloud account. It can only reach the data her permissions allow. Every step and message is logged locally.
- Iteration. She refines the criteria in conversation. If she wants to test whether another model handles the task differently, she can swap models and rerun.
- Federation. If the question needs a second site, the agent runs there too, inside that site’s environment and under its rules.
- Release. When she wants to take aggregate results out, they go through the Airlock. Anything that does not pass review stays inside.
At no point in this sequence does patient-level data leave either custodian. What she takes away is what the Airlock approved, and the custodian keeps a complete record of how it was produced. You can read more on the AI Scientist Studio page.
How to evaluate any AI vendor for governed health data
Whether you are assessing AI Scientist Studio or any other product, these are the questions a data custodian should ask before AI agents are allowed near sensitive data:
- Where does the agent’s compute run, and whose cloud account is it in?
- Does any patient-level data, including data quoted in chat, leave our environment?
- Does the agent act with the user’s permissions, or with a broader service identity?
- What controls govern outputs, and can an agent export anything without review?
- Where are chat history and audit logs stored, and can we reconstruct every action?
- Can we enable or disable AI per project or workspace?
- Are we tied to one model provider, or can we choose and change models?
- How does the product work across multiple sites without pooling data?
For the underlying concepts, Lifebit’s guide to what a Trusted Research Environment is is a useful starting point.
Frequently asked questions
What is AI Scientist Studio?
AI Scientist Studio is Lifebit’s product for building and running AI research agents inside a data custodian’s governed Trusted Research Environment. Agents execute in the custodian’s cloud, inherit user permissions, and can only release results through Lifebit’s Airlock output controls.
Which AI models does AI Scientist Studio support?
It is model-agnostic. Researchers can bring their own model or choose from foundation models such as GPT, Gemini, Claude, or open-source models, and they can swap models without redefining their agents.
Does patient data leave the custodian’s environment?
No. Agents run on compute inside the custodian’s own cloud account, and patient-level data never moves. Chat history, outputs, and audit trails also stay inside the environment. Only results approved through the Airlock leave.
Can an agent access more data than its user?
No. Agents inherit the permissions of the user who runs them, so an agent cannot see anything its user cannot see.
How does AI Scientist Studio relate to the Five Safes?
Lifebit frames it as the ONS Five Safes applied to agentic AI. Safe Settings, Safe Outputs, and Safe Projects continue to hold when the researcher is an agent, through in-environment execution, Airlock review, and per-workspace AI enablement.
Can agents run across more than one site?
Yes. Agents can run federated across multiple sites. Each site’s analysis runs inside its own environment under its own rules, and only approved results are returned.
Who decides where AI is switched on?
The data custodian. AI is enabled per workspace, so each custodian chooses which workspaces allow agents and which do not.