AI Agent Governance for Clinical Research Site Operations

Why Clinical Research Sites Are a Distinct Governance Environment

Clinical research sites present a governance problem that differs from general enterprise AI deployment. Site operations teams are introducing AI agents to support protocol interpretation, patient recruitment screening, source data verification, and interactions with electronic data capture (EDC), clinical trial management (CTMS), and electronic trial master file (eTMF) systems. These are regulated data environments. Good Clinical Practice (GCP), as codified in the finalized ICH E6(R3) guideline, requires sponsors and investigators to maintain data integrity, traceability, and audit trails for every system used in trial conduct, including electronic systems. Separately, 21 CFR Part 11 imposes audit trail, access control, and record authenticity requirements on any electronic system touching regulated records. Neither framework was written with AI agents in mind, but neither exempts them. An agent that reads eTMF documents, screens patient recruitment data, or writes to an EDC form is, from a regulatory standpoint, an electronic system touching regulated records, and its actions inherit the same accountability requirements as a human user's. This is the starting point for any governance approach: existing GCP and Part 11 obligations apply regardless of whether the acting entity is a person or an agent, and no confirmed FDA or ICH guidance currently carves out a separate standard for autonomous agent actions.

System Access Patterns and Where Permission Boundaries Matter

Agents deployed in site operations typically need some combination of read access to eTMF documents for protocol interpretation, read access to patient records or recruitment platforms for eligibility screening, and read or write access to EDC and CTMS systems for data entry, query resolution, or status updates. Each of these access patterns carries a different risk profile. Read-only access to a protocol document for interpretation purposes is materially lower risk than write access to a case report form or an eligibility determination that could affect trial enrollment. A defensible governance posture separates these by system and by action type: read access can often be granted with lighter oversight, while any write action affecting source data, CRFs, or patient eligibility should be treated as requiring human-in-the-loop approval until a clearer regulatory or organizational precedent exists. This is not a documented regulatory requirement specific to agents, since no such requirement currently exists, but it follows directly from the accountability principles in ICH E6(R3) and the audit trail obligations in Part 11, both of which assume a responsible human role behind any recorded action.

Auditability: Translating Part 11 Requirements Into Agent Logging

21 CFR Part 11 requires audit trails that establish who performed an action, what the action was, when it occurred, and, where relevant, the before and after state of a record. Applied to AI agents, this means the audit requirement is not satisfied by a model's free-text reasoning trace. It requires structured logging of the discrete actions the agent actually took: which tool was called, with what parameters, against which system, at what time, under which agent and session identity, and with what result. This distinction matters operationally. A log of an agent's internal reasoning may be useful for debugging but does not, by itself, meet the attributability and traceability standard that Part 11 and ICH E6(R3) apply to electronic records. Site operations teams evaluating agent deployments should treat tool-call-level logging, not model-output logging, as the compliance-relevant artifact. Because agent actions may span multiple systems (for example, an eligibility screening result in a recruitment platform that later informs a CTMS enrollment record), centralized logging that correlates actions across systems is generally more useful for audit reconstruction than relying solely on each system's native, siloed audit trail.

Tool-Call Governance and the MCP Security Context

Many agent architectures now separate model reasoning from tool execution using standardized protocols such as the Model Context Protocol (MCP), maintained by Anthropic. This separation creates a natural enforcement point: permission checks can occur at the boundary where a tool call is about to execute, before it reaches an EDC, CTMS, or eTMF system. Recent MCP specification updates have added OAuth-based authorization, enabling scoped, revocable tokens per tool or session rather than static, long-lived credentials. This is directly relevant to least-privilege design in clinical environments, since it allows access to be granted narrowly and revoked quickly if a session is compromised or a permission needs to change. Separately, OWASP's guidance on large language model and agentic AI security identifies excessive agency, insecure tool design, and inadequate access control as leading risks for autonomous agents that invoke external tools, and explicitly distinguishes model-level restrictions such as system prompts from enforceable runtime controls such as policy engines and gateways. For regulated environments, the OWASP position is direct: prompt-level restrictions alone are not a sufficient control, because they can be bypassed or fail silently, whereas a runtime enforcement layer can block a disallowed action outright. Neither MCP nor OWASP guidance is clinical-research-specific, but both describe control patterns that map cleanly onto the access boundaries clinical systems require.

Governance Gaps and Where Judgment Is Still Required

It is worth being explicit about the limits of current guidance. No FDA, ICH, or NIST document as of this writing specifically addresses AI agent identity, tool-call permissioning, or runtime policy enforcement for clinical trial site systems. The governance mappings described here extend existing GCP, Part 11, and NIST AI Risk Management Framework principles to agent architectures by analogy, not by direct regulatory mandate. Site operations teams and sponsors should treat this as an area requiring internal risk determination rather than a settled compliance checklist. A conservative, defensible interim posture favors read access with lighter controls, write access gated by human review, non-human agent identities distinct from shared credentials, and centralized, structured logging capable of reconstructing any agent action across systems. This posture aligns with the accountability and risk-based validation principles in ICH E6(R3) without waiting for agent-specific regulatory guidance that does not yet exist.