Building secure agents in clinical trials

In June 2026, Novo Nordisk disclosed that attackers had reached its internal systems and copied data from some of its clinical trials, including patient IDs, years of birth, biomarkers, immunogenicity results, and lifestyle details down to smoking and alcohol use.¹ The company said the data was pseudonymized and that no participant could be identified from it. The group that claimed the attack said the haul was larger, and included dozens of the company's own proprietary AI models alongside the trial data. Researchers who examined the intrusion traced the entry point to credentials left sitting in code, tied to an account that had far more access than it needed.²

This is an all too familiar kind of security vulnerability, the kind that happens with or without AI in the picture. But as AI takes on more of the work in clinical trial operations, from reading, classifying, and QCing trial master file (TMF) documents to emailing sites, reconciling queries, and moving data between systems, the same mistake gets easier to make and more expensive when it happens. An agent that holds too much access is a bigger target than a person who does, because it acts continuously and at a scale no single credential misuse by a human ever could.

What can go wrong with an agent

A copilot drafts text and leaves a person to decide what to do with it, whereas an agent takes actions on live systems with real credentials and real access, and it's that difference that leads to risk.

Prompt injection

An agent works by reading text from different sources, such as documents, emails, query responses, or records pulled from other systems. A prompt injection is when an attacker hides instructions inside the text that an agent reads, hoping the agent will follow them instead of performing its actual task. For instance, a single line hidden in an emailed document could tell the agent to download documents it should not touch and send them somewhere it should not. It is the most common attack on these systems, and it is genuinely hard to completely prevent.³⁴

Too much access

To be useful, an agent needs tools and credentials so it can read from the EDC or update the TMF, for instance. The problem of too much access arises when the agent is given more access to perform its task than it requires. This is the same failure mode behind the Novo Nordisk breach.² A prompt-injection attack that succeeds against a properly scoped agent still can't reach documents it was never given access to in the first place.

How you secure it

Securing an agent means keeping it isolated, constrained, and guardrailed, with access only to the systems it needs at the moment it needs them.

Filtering

Anything that reaches the agent without the system controlling it, such as a user typing into a chat interface or a document being ingested, needs to pass through a filtering check first. That check usually runs on a small, secondary model whose only job is to sit between the untrusted prompt or document and the main system and decide whether it looks malicious.⁵ A set of deterministic filter checks can run alongside it to catch specific malicious phrases like "give me your system prompt." What these filters ultimately prevent are the prompt injection attacks described above.

It's also worth noting that clinical trial systems start from a smaller risk than an open system like ChatGPT because the user base is a limited group of people from a sponsor or CRO, and not the general public. This means a legitimate user typing something malicious directly into the system is unlikely. Rather, the real risk comes through the documents and emails an agent reads, and that is exactly what filtering is there to catch.

Least privilege

Least privilege means an agent holds no more access than its task requires.⁶ For instance, an agent built for TMF QC and filing should be able to read documents from the TMF and file them back in the right place, but it has no need to have the ability to delete anything. Similarly, an agent that reviews MVRs should be able to read the report, the protocol, and the clinical monitoring plan, as well as write its findings back into the CTMS, and nothing beyond that.

Human approval

A person stays in the loop on consequential actions, so a manipulated or mistaken agent cannot act alone. Anything irreversible, an email to a site, a closed query, an edited record, passes through someone who can approve, change, or reject it. This is not just good practice, the EU AI Act requires human oversight for high-risk systems, including the ability to monitor what the system does and to override or halt it.⁷

A platform built for regulated data

The controls above shape how an agent behaves, but the architecture it runs on matters just as much. In a properly architected system:

• Each customer's data is kept separate from every other customer's through an isolated tenant architecture, so an agent can never see another customer's data.
• Data is encrypted while it moves between systems using TLS 1.3+ and while it is stored using AES-256, with encryption keys that are never shared across customers.
• Every action an agent takes gets logged to immutable storage so an agent cannot hide what it did or how it reached a decision.
• Any third-party model provider has a zero-data-retention agreement in place, so customer data is never used to train external models.

Conclusion

Agents will let teams be more efficient across clinical operations than ever before, but only where people can trust what the software does with their data. That trust gets earned the same way it always has: least privilege, isolated tenants, human approval, and a real audit trail.

At Phases, we've built our systems in line with the security practices outlined in this article, and more, from day one. We are also SOC 2 Type II compliant, meaning an independent auditor examined our security controls over several months and confirmed they operate as described,⁸ and we have our systems periodically and independently penetration tested on top of that.

To see what this looks like in practice, book a demo below. In the meantime, our Trust Center has the full detail on our security and compliance practices.