The Control Plane for Agentic Clinical Operations: Governing Autonomous Digital Actors in Regulated Trials

Note: The regulatory and standards references below provide existing control foundations. Their applicability depends on jurisdiction, intended use, system role, and risk classification. The article does not suggest that every cited requirement applies to every clinical-trial agent.

An artificial intelligence (AI) agent supporting clinical trial operations may begin with a narrow role. Consider site readiness. The agent reviews available information, identifies a missing document, and drafts a follow-up for the study team. The boundaries are relatively clear. Then the environment changes. Users provide feedback; the agent retains more context; a document repository is connected; its CTMS permissions expand; and additional tools become available. Activities that initially required human intervention are gradually automated.

The underlying model may still be the same, and there may be no obvious software release. Yet the agent is no longer performing the same operational role.

Same model, same agent, different capabilities

This isn't an article about whether clinical operations will use AI agents. It is about what happens when those agents acquire the authority to act.

That is the control problem regulated clinical research now needs to address. The question is no longer limited to whether a model was validated or whether an agent has access to a particular system. It is whether the agent's effective ability to access, remember, decide, delegate, and act remains within the boundaries originally assessed and approved.

Existing regulations, guidance, and standards already provide much of the foundation. The consolidated ICH E6(R3) guideline addresses computerized systems, security, validation, user management, access permissions, audit trails, data governance, and record retention.¹ FDA guidance addresses trustworthy and reliable electronic systems, electronic records, and electronic signatures used in clinical investigations.² The NIST AI Risk Management Framework provides a lifecycle approach to AI risk management. At the same time, its Playbook specifically addresses post-deployment monitoring, user input, override, incident response, recovery, and change management.^3,4 For high-risk AI systems within scope, the EU AI Act includes requirements covering record-keeping, human oversight, post-market monitoring, and reassessment following substantial modification.⁵

The issue is not that clinical research lacks control. The harder question is what those controls need to surround when the actor itself can change operationally over time.

From application governance to autonomous capability

Traditional computerized-system governance has familiar objects: users, applications, roles, permissions, configurations, transactions, and releases. AI agents introduce another object: autonomous capability.

An agent may authenticate into systems, operate on behalf of a person or role, retrieve information, retain context, select tools, interpret conditions, make decisions, execute transactions, and invoke other agents or services. Those activities should not be treated as one large permission.

Take the site-readiness example. The agent may need permission to read the status of a missing document, retrieve supporting evidence, and draft a communication. That is relatively straightforward. But can it decide that the missing document does not block activation? Can it approve an exception, change the readiness status, or trigger the next operational step? Those are different authorities.

System permission is not the same as business authority

That distinction is central to what I call the Agentic Control Plane: the identity, authorization, policy, monitoring, evidence, assurance, and containment mechanisms that surround an autonomous actor throughout its operating life.

Identity, delegation, and authority

Every consequential action begins with identity, but for an agent, identifying the technical actor is not enough. The agent may act independently as a service, on behalf of a trial manager, in support of a clinical operations role, or under authority delegated by another business role.

Authentication answers which agent is making the request. Delegation answers a different question: whose authority is it exercising, and within what limits? Those limits may include study, duration, data domain, tool, transaction type, and the ability to delegate again. This becomes particularly important when agents invoke other agents or services. Authority should not quietly expand as execution moves further down the orchestration chain.

Least privilege still applies. In fact, NIST SP 800-53 defines least privilege as applying to processes acting on behalf of users, not just users themselves.⁶ Agentic systems need to carry that principle beyond system access into operational authority. Reading a readiness record, assessing whether requirements are complete, changing the record, approving an exception, and certifying completion are separate capabilities. An agent may legitimately require the first two while having no business authority for the others.

Periodic access review therefore needs to broaden. It may no longer be enough to ask whether an agent still requires a CTMS entitlement. Organizations may also need to review whether they still require a particular tool, action right, delegated authority, memory store, or the ability to invoke another autonomous actor. The control surface is wider than conventional access certification.

Segregation still matters

Segregation of duties is familiar territory in regulated environments. NIST SP 800-53 explicitly addresses both separation of duties and least privilege through controls AC-5 and AC-6.⁶ Agentic workflows make the same principle harder to see.

Consider a site-readiness agent that identifies a missing requirement, determines whether an exception applies, initiates remediation, updates the CTMS, and verifies that the issue has been resolved. The workflow may be efficient, but the requester, decision-maker, executor, and checker have effectively become one autonomous actor.

Adding more agents does not automatically solve the problem. Agent A may identify the issue, Agent B may assess it, and Agent C may confirm completion. If all three operate through the same credentials, shared memory, delegated authority, policy environment, or controlling orchestrator, the organization has technical separation without genuine control independence.

For higher-risk activities, segregation may need to operate across identity, authority, execution, approval, and assurance. This is the practical meaning of Segregation of Agent Authority. The aim is not to insert human approval into every workflow. It is to prevent one autonomous control domain from quietly acquiring the ability to request, decide, execute, and verify the same consequential action.

Memory changes the control boundary

Conventional identity and access management asks what an actor is allowed to access. Agents introduce a second question: What is the actor allowed to remember?

An agent may retain session context, operational memory, retrieved summaries, previous decisions, embeddings, user preferences, and patterns learned from earlier interactions. Revoking access does not necessarily remove information that has already been written to persistent memory.

An agent may lose access to a study while retaining information derived when that access was valid. An agent used in an unblind context could later carry information into a blinded workflow. An agent supporting multiple studies could unintentionally reuse country- or protocol-specific context elsewhere. Memory, therefore, needs its own controls over provenance, purpose, isolation, retention, expiry, and deletion.

It also needs a boundary around learning. Imagine repeated feedback to a site-readiness agent: “For this country, we normally accept that document later.” First, this is contextual guidance. If it is retained and reused repeatedly, it can begin to behave like an operating rule.

That should not happen silently. Agents may reasonably adapt to presentation preferences or benign working patterns. They should not infer new compliance rules, approval rights, quality thresholds, or exceptions to controlled processes without a governed change. A Controlled Learning Boundary separates what an agent may adapt through experience from what can change only through approved policy or process change. ISO/IEC 42001 provides a management-system foundation for establishing, implementing, maintaining, and continually improving organizational AI governance.⁸

When the model stays the same but the agent changes

Much of AI governance focuses on model drift. Agentic systems create a broader problem because the same model can behave differently when prompts, retrieval sources, memory, tools, permissions, user feedback, delegated authority, or operating context change.

The NIST AI RMF Playbook calls for post-deployment monitoring that includes mechanisms for user and AI-actor input, appeal and override, decommissioning, incident response, recovery, and change management.⁴ NIST AI 800-4, published in 2026, also focuses on the challenges of monitoring deployed AI systems and on whether they continue to operate reliably in real-world settings.⁹

The useful control question is therefore broader than model drift: Has the agent's effective capability moved outside the approved boundary?

That is Agent Governance Drift. It may happen gradually. A temporary permission remains active, a new tool is connected, persistent memory is enabled, a manual review disappears, a local exception becomes routine, or broader authority is delegated because the agent has performed well. Each change may appear reasonable in isolation. Together, they can create Agentic Control Debt: permissions, exceptions, retained context, and unresolved control decisions that make assurance progressively harder.

This is one reason conventional release management may miss the real change. The software version can remain unchanged while the operational capability moves considerably.

Control the action, not just the tool

Agents operate through tools, but granting an agent access to a CTMS connector should not grant them every action that the connector technically supports. A connector may allow reading, updating, closing, approving, or triggering downstream workflows. The agent's permitted action set may be much narrower.

Critical controls therefore need to sit close to the action boundary. Natural-language instructions that tell an agent what it should or should not do are not sufficient for consequential actions. A site-readiness agent may be allowed to read evidence and draft a recommendation, while changing a critical readiness status requires human approval, and approving an exception remains human-only. Those distinctions should be enforced technically rather than left to prompt wording.

Human oversight should also be risk-based. Low-risk and reversible actions may run autonomously. Other actions may require human monitoring, intervention rights, explicit approval, or exclusion from delegation. For applicable high-risk AI systems, Article 14 of the EU AI Act requires that systems be designed to be effectively overseen by natural persons during use, with measures proportionate to the risk, autonomy, and context.⁵

Independent assurance matters as well. An agent checking its own consequential action recreates the same concern that segregation of duties was designed to address. A second AI agent is not automatically an independent checker. If it shares the same authority, memory, policy path, or controlling system, it may reproduce the same failure mode.

Keep enough evidence, not everything

Agentic execution can leave a much larger information footprint than a conventional transaction. A simple readiness update may involve retrieved documents, session context, prompts, memory reads, intermediate outputs, policy checks, tool calls, approvals, execution traces, and telemetry.

Retaining all of it is not automatically safer. The organization needs enough evidence to reconstruct and defend consequential action without turning every agent interaction into a permanent regulated record.

ICH E6(R3) defines audit trails around manual and automated actions and expects relevant metadata, including audit trails, to support traceability.¹ The guideline also takes a risk-proportionate approach to data, records, and computerized systems, as well as to retention. ISO/IEC 27001 provides a framework for an information security management system to manage security risks.⁷ In contrast, GAMP 5 provides risk-based industry guidance for computerized systems that are effective, high-quality, fit for their intended use, and compliant with applicable regulations.¹⁰

The practical design question is: What is the minimum sufficient evidence needed to reconstruct this autonomous action? That should drive retention. Indiscriminate storage creates its own obligations around privacy, security, discovery, migration, validation, and lifecycle management.

Runtime governance matters

Periodic certification still has a role, but it is not enough for an actor whose effective capability can change between formal review cycles. Certification asks whether the agent still needs its identity, tools, access, memory, delegation rights, and authority. Runtime monitoring asks whether it is operating inside those approved boundaries.

That requires a behavioral baseline: the expected actions, tool paths, authority levels, operating conditions, and escalation points for the agent. Monitoring should detect unexpected tool calls, unusual use of authority, new delegation paths, policy violations, abnormal memory behavior, or activity outside the approved operating envelope.

The EU AI Act's concept of substantial modification is useful here. Article 3(23) defines a substantial modification as an unplanned or unforeseen post-deployment change that affects compliance with applicable requirements or changes the system's intended purpose for which it was assessed. For applicable high-risk AI systems, Article 43(4) requires a new conformity assessment following a substantial modification.⁵

The broader governance lesson remains useful even when a clinical-trial agent does not fall under that legal classification: a material change in capability requires an explicit reassessment trigger. Waiting for the next conventional software release may be too late.

Containment also needs to exist outside the agent. An organization should be able to suspend the agent identity, revoke delegated authority, disable selected tools, isolate persistent memory, stop workflows, or return execution to a human process without relying on the agent to police itself.

Shadow agency

Enterprise-approved agents will not be the only autonomous actors touching clinical operations. Agents will also appear inside SaaS platforms, vendor products, low-code tools, functional solutions, and user-built workflows. Some may begin interacting with regulated processes before entering the same governance path as formally deployed clinical technology.

This creates Shadow Agency. Shadow IT introduced technology outside formal governance. Shadow Agency introduces technology outside formal governance that can act.

An agent registry therefore becomes basic infrastructure. Before an organization can govern autonomous capability, it needs to know which autonomous actors exist, where they operate, what authority they hold, and which systems they can affect. That registry cannot be treated as a static inventory. If an agent's authority, tools, memory, or system connections change, its governance record needs to change as well.

These controls are not all new. Most have roots in GCP, computerized-system governance, information security, access management, or AI lifecycle governance. What changes is the need to connect them around an actor whose effective capability can change as its authority, context, tools, and memory change.

Governing the capability to act

Agentic AI does not make existing clinical-trial controls obsolete. ICH E6(R3), FDA guidance, NIST, information-security standards, GAMP, ISO/IEC 42001, and, where applicable, the EU AI Act already provide a substantial foundation for identity, access, oversight, traceability, risk management, lifecycle monitoring, and controlled change.

What changes is the object those controls increasingly need to surround. An agent is not simply a model. It is the combination of its identity, delegated authority, access, memory, tools, decision rights, execution rights, learning boundaries, and operating context. Those elements can change independently, sometimes without a conventional software release.

For regulated clinical operations, the governance question therefore extends beyond whether the model or software has changed. The more useful question is: has the autonomous capability changed?

The Agentic Control Plane is the architecture needed to keep that answer visible and to keep the authority to act within the boundaries the organization intended.

About the author

Tushar Sinkar is an AI and digital transformation leader with experience across clinical trials, enterprise technology, product delivery, and regulated transformation. He focuses on translating complex operational challenges into scalable digital capabilities across process orchestration, data readiness, governance, and responsible AI adoption.

References

1. International Council for Harmonization of Technical Requirements for Pharmaceuticals for Human Use. ICH Harmonized Guideline: Guideline for Good Clinical Practice E6(R3). Final version. Adopted 16 June 2026. The official consolidated guideline confirms the date and includes dedicated sections on computerized systems, security, validation, user management, audit trails, and record retention.
2. U.S. Food and Drug Administration. Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers. Guidance for Industry. October 2024.
3. Tabassi E. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. National Institute of Standards and Technology; 2023. DOI: 10.6028/NIST.AI.100-1.
4. National Institute of Standards and Technology. NIST AI RMF Playbook. MANAGE 4.1, Post-deployment AI system monitoring. The official Playbook specifically includes user and AI-actor input, appeal and override, decommissioning, incident response, recovery, and change management.
5. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonized rules on artificial intelligence (the Artificial Intelligence Act). Article 3(23), substantial modification; Article 12, record-keeping; Article 14, human oversight; Article 43(4), conformity assessment following substantial modification; Article 72, post-market monitoring.
6. Joint Task Force. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53 Revision 5. National Institute of Standards and Technology; September 2020. AC-5 addresses separation of duties, and AC-6 addresses least privilege, including processes that act on behalf of users.
7. ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection - Information security management systems - Requirements. International Organization for Standardization and International Electrotechnical Commission; 2022.
8. ISO/IEC 42001:2023. Information technology - Artificial intelligence - Management system. International Organization for Standardization and International Electrotechnical Commission; 2023.
9. Rao A, Keller A, Kalra N, Steed R, Kwegyir-Aggrey K, Klyman K, Staheli D, Bergman A. Challenges to the Monitoring of Deployed AI Systems: Center for AI Standards and Innovation. NIST AI 800-4. National Institute of Standards and Technology; March 2026. DOI: 10.6028/NIST.AI.800-4.
10. International Society for Pharmaceutical Engineering. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems. Second Edition. July 2022. ISPE explicitly describes GAMP as pragmatic industry guidance rather than a prescriptive standard.