01
Research Governance
Accountable: Research Leadership
Defines acceptable AI use, research priorities, exceptions, and institutional governance.
Research institutions combine participant data, independent studies, federal funding and collaborators. Put an AI agent across that environment and the question changes from “is the model secure?” to “can every AI action stay inside the authority it was given?” This guide maps the risks, the rules and the owners.
Research institutions are becoming AI-native. Their security architecture must become AI-native too.
Universities, medical schools, laboratories, research hospitals, government-funded institutes, and independent research organizations are rapidly integrating AI into the research lifecycle.
AI can now help researchers:
That creates extraordinary possibilities.
It also creates a security environment unlike ordinary enterprise AI.
A university may have thousands of researchers, hundreds of laboratories, multiple principal investigators, independent studies, controlled-access repositories, participant information, proprietary research, federal grants, external collaborators, and highly specialized computing environments.
Now put an AI agent across that environment.
The agent may have access to:
Research data → cloud storage → vector databases → APIs → institutional systems → external tools → other agents
The security question is no longer simply:
“Is the AI model secure?”
It becomes:
“Can the entire research ecosystem remain secure when AI can access, reason over, connect, transform, and act on research information?”
That is the central problem behind AI security for research institutions in 2026.
AI security for research institutions is the combination of cybersecurity, privacy, identity, data-governance, research-integrity, regulatory, and AI-agent controls used to protect research data, researchers, participants, intellectual property, and scientific workflows from AI-related threats.
A complete program covers:
AI models
AI applications
AI agents
Research data
Identities
Cloud infrastructure
Research repositories
Third-party tools
Institutional workflows
Human-subject protections
Research integrity
Federal funding requirements
The important distinction is that research security has multiple overlapping trust boundaries.
A researcher may be authorized for one study but not another.
A laboratory may be authorized for one dataset but not another.
A principal investigator may have access that a research assistant does not.
An AI agent may need access to only a subset of the researcher's permissions.
Therefore:
Research AI security is fundamentally an identity, authorization, data, and trust-boundary problem.
A commercial enterprise might have:
Employees → Applications → Corporate Data
A research institution can have:
Researchers → Labs → Studies → Participants → Repositories → Federal Data → Collaborators → AI Systems
The data itself can be unusually sensitive.
Examples include:
And research is collaborative by design.
A single project can span:
University A + University B + Hospital C + Federal Repository + Cloud Provider
AI can make those connections more useful.
It can also make them more dangerous.
There is no single federal law called the “AI Security for Research Institutions Act.”
Instead, AI operates inside existing research frameworks.
For human-subjects research covered by the Common Rule, 45 CFR Part 46 establishes requirements governing institutions and investigators, including IRB review and criteria for approval. Under §46.111, IRBs consider minimizing subject risk, reasonable risk relative to anticipated benefits and knowledge, informed consent, safety monitoring when appropriate, and protection of privacy and confidentiality when appropriate.
For NIH-funded research, the March 2026 NIH Grants Policy Statement serves as a major source of award terms and conditions, while NIH continues to issue Guide Notices that can supersede or clarify the Grants Policy Statement.
NIH's Data Management and Sharing (DMS) policy is another major anchor. Applicable NIH-funded research that generates scientific data needs a DMS Plan, and the plan should be updated during the project when appropriate. Check NIH's current DMS notices for required plan elements and effective dates.
For controlled-access data, NIH publishes security and operational requirements for controlled-access data repositories and for approved users. Check NIH's current requirements page for details and effective dates.
NSF's current core framework is PAPPG 24-1, supplemented by later policy notices. NSF's Supplement 1 to PAPPG 24-1 explicitly incorporates AI-based tools into its research-misconduct language.
The message is important:
AI is entering research policy through existing governance structures as well as AI-specific guidance.
A useful institutional framework starts with six major risk domains.
Can AI expose, infer, or reconstruct information about research participants?
Can an unauthorized person, AI agent, or external service access protected research data?
Can AI fabricate, alter, misrepresent, or improperly transform scientific information?
Can autonomous AI systems access tools, identities, databases, or workflows beyond what they require?
Can information from one PI, lab, or study surface in another research context?
Can AI use violate an IRB protocol, consent framework, data-use agreement, grant condition, repository requirement, or agency policy?
These risks overlap.
That is precisely why point solutions are not enough.
Generative AI can answer questions.
AI agents can increasingly take actions.
For a research institution, an AI agent might:
This creates the AI Agent Authority Problem.
The agent needs:
The strongest principle is:
The agent should never become the authority that decides what the agent is authorized to do.
OWASP's 2026 Agentic Applications framework identifies risks including identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures, and rogue agents.
For research institutions, those risks can translate into participant-data exposure, cross-study leakage, intellectual-property loss, or scientific-integrity problems.
An institution cannot reduce AI governance to:
“Does the vendor say the model is HIPAA compliant?”
Human-subjects research may involve the Common Rule, IRB oversight, consent requirements, privacy, confidentiality, and specific institutional procedures.
The IRB question is not simply:
“Is the software secure?”
It is:
“Do the AI-enabled research activities create risks to subjects that are appropriately minimized and controlled?”
That can include:
This is why IRB AI security deserves its own research-specific treatment rather than being buried inside generic healthcare AI content.
Related spoke: IRB AI Security: Human Subjects Research AI Risk 2026
A dataset may contain no:
name
phone number
and still contain highly identifying combinations.
Classic privacy research demonstrated that combinations of demographic fields could uniquely identify individuals, while later research showed similar linkage problems in supposedly anonymous behavioral datasets.
AI creates another analytical capability layer.
A model or agent may correlate:
DOB + geography + rare condition + treatment date
with information from other datasets.
The security question therefore becomes:
What happens when the AI can join clues that were never intended to identify someone individually?
NIST explicitly recognizes re-identification as a privacy risk and discusses de-identification as a risk-management problem rather than a guarantee of perfect anonymity.
Related spoke: AI Research Data: De-identification and Re-identification Risk
Imagine one university running a centralized AI research platform.
There are:
Study A
Study B
Study C
Study D
All use the same:
LLM + RAG + Vector DB + Agent Infrastructure
The infrastructure is shared.
The authorization boundaries are not.
A retrieval system that returns Study A information to a Study B researcher has created a cross-study data leakage AI incident even if:
The established pattern for multi-tenant retrieval is to derive tenant context from verified identity rather than a client-supplied value, and to preserve that isolation across every retrieval hop.
For research, “tenant” can mean:
PI
Lab
Study
Cohort
Institution
The rule is simple:
Relevance is not authorization.
Related spoke: Cross Study Data Isolation Risk: AI Agents 2026
Federal funding adds another dimension.
NIH's current 2026 policy materials explicitly address responsible AI use and research integrity.
NIH's May 2026 reminder states that AI use can create integrity problems involving fabrication, falsification, plagiarism, inaccurate references, and inappropriate alteration of research materials. NIH emphasizes that researchers remain responsible for reviewing and confirming AI-generated information.
NIH also has specific controlled-access genomic-data guidance. Its controlled-access repository requirements emphasize safeguarding data, identity and access controls, standard security practices, and protection of participant privacy.
NSF's current PAPPG framework and supplements provide another important anchor. NSF's Supplement 1 explicitly states that research misconduct can occur through use or assistance of AI-based tools in proposing or performing NSF-funded research, reviewing proposals, or reporting results.
Related spoke: NIH and NSF AI Compliance Considerations
Grant administration contains another AI security boundary:
Disclosure → Review → Determination → Management → Reporting
The danger is not merely that an AI assistant makes a mistake.
It is that the AI could become capable of manipulating workflow state.
For example, consider a system in which an AI:
If the same AI identity can satisfy both the initial workflow and the supposed independent approval step, the organization may have a separation-of-duties failure.
This is a threat model, not a claim that this precise event has already occurred in a documented research institution.
But it illustrates a critical principle:
An AI assistant should never be able to manufacture the evidence that proves its own independent authorization.
AI can automate administrative work.
It should not silently automate away accountability.
Related spoke: Grant Compliance Risk: AI Conflict of Interest
Clinical research introduces a particularly high-stakes AI problem.
An AI system can increasingly participate in:
event extraction
classification
case processing
prioritization
signal detection
workflow routing
Regulators are examining AI in medicines regulation, including pharmacovigilance tasks such as adverse-event report management and signal detection.
The security question is therefore:
Could a manipulated or flawed AI workflow suppress, downgrade, delay, or misroute an important safety signal?
There is not a publicly established case proving that an autonomous AI agent intentionally suppressed an adverse-event report in the precise manner described by this threat model.
But the architectural concern is real.
The safe design separates:
Detection
from
Policy
from
Final disposition
from
Audit
Related spoke: AI Agents Manipulation Risk: Adverse Event Reporting Integrity
Every AI agent should have a clear identity.
Institutions should know:
Which agent is this?
Who owns it?
Which project is it operating for?
What data can it access?
Which tools can it invoke?
What actions can it perform?
Can another agent delegate authority to it?
NIST's 2026 work on software and AI agents emphasizes identity, authentication, authorization, auditing and delegation.
For research environments, this creates a powerful principle:
Every AI agent should be treated as a non-human identity with bounded authority.
A shared “research-bot” account with institution-wide privileges is fundamentally different from:
Study-123-Agent
with:
read-only access
to:
Study 123
for:
30 days
under:
one research project
That is the difference between convenience and controlled autonomy.
AI security must follow data through its entire lifecycle.
What information enters the system?
Where is it stored?
Which model processes it?
Which agent can retrieve it?
Can AI combine or alter it?
Can the resulting information expose sensitive facts?
Which external systems receive it?
What remains in logs, caches, memory, or model-related services?
NIH's DMS framework reinforces this lifecycle perspective by requiring plans for managing and sharing scientific data and allowing them to be updated as a project evolves.
This means AI governance belongs inside the data management lifecycle, not beside it.
A strong conceptual architecture is:
Notice what is missing.
The model does not decide:
Who the researcher is.
Which study they can access.
Which tools they can invoke.
Whether an action is authorized.
Those decisions belong to deterministic security controls.
A useful institutional principle is:
Never trust an AI agent merely because it is operating inside the university network.
Verify continuously:
Identity
Authorization
Resource
Purpose
Action
Destination
This is especially important when an AI agent crosses system boundaries.
For example:
Each transition should preserve authorization.
Every important agent should have an identifiable owner and dedicated identity.
Give agents only the minimum data and tools required.
Separate PI, lab, study, and participant access boundaries.
Apply authorization filters before sensitive information reaches model context.
Observe tool calls, data access, unusual behavior, and external connections.
Require meaningful human authorization for high-impact decisions.
Test whether prompt injection, tool abuse, memory contamination, or agent-to-agent delegation can cross security boundaries.
These controls reinforce one another.
No single layer should be expected to stop every AI attack.
Traditional security testing often asks:
“Can an attacker compromise the application?”
AI security should additionally ask:
“What happens after the agent is manipulated?”
Test scenarios such as:
Prompt injection
Can hostile instructions redirect the agent?
Privilege escalation
Can an agent gain broader access than intended?
Cross-study retrieval
Can Study A appear in Study B's context?
Memory leakage
Can one project's memory appear in another?
Tool abuse
Can the agent invoke an unauthorized API?
Delegation abuse
Can Agent A cause Agent B to perform a prohibited action?
Data exfiltration
Can sensitive research data reach an external destination?
Approval bypass
Can the agent manufacture or replay approval states?
These are not merely model evaluations.
They are system security tests.
Every institution should maintain an inventory of important agents.
For each one, ask:
Whose permissions does it use?
What can it read?
What can it change?
What systems can it access?
What other agents or workflows can it trigger?
This produces an AI Agent Blast Radius profile.
A literature agent that reads public research papers has a relatively narrow profile.
An agent that can access controlled participant data, laboratory systems, cloud storage, and other autonomous agents has a much broader one.
The goal is not zero capability.
The goal is controlled capability.
AI security is sometimes treated as an IT problem.
For research institutions, it is also a scientific integrity problem.
Imagine an AI system:
The impact goes beyond cybersecurity.
It can affect:
research validity
publication integrity
participant protection
grant compliance
institutional reputation
public trust
NIH's 2026 AI-integrity guidance and NSF's revised misconduct language make this connection particularly clear.
A mature program should have clear ownership.
Sets acceptable uses and research priorities.
Evaluates applicable human-subject risks.
Manages technical security.
Addresses sensitive information and privacy obligations.
Tracks grant and award requirements.
Controls datasets and sharing.
Handles scientific-integrity concerns.
Manages infrastructure and identity.
Remain responsible for appropriate research use.
AI security becomes much stronger when these functions collaborate rather than operate independently.
Effective research AI security requires more than a list of controls. Every control needs a clearly accountable owner, responsible operators, supporting stakeholders, evidence, and a defined review cadence.
Accountable: Research Leadership
Defines acceptable AI use, research priorities, exceptions, and institutional governance.
Accountable: IRB
Evaluates applicable participant risks, privacy, confidentiality, and protocol implications.
Accountable: Data Governance / Data Owners
Controls dataset classification, access, sharing, segregation, and lifecycle requirements.
Accountable: Information Security
Controls AI identities, permissions, tools, runtime behavior, and agent security.
Accountable: Research Integrity
Protects scientific accuracy, originality, reproducibility, and integrity of the research record.
Accountable: Research Administration
Tracks NIH, NSF, award, disclosure, and institutional compliance obligations.
Accountable: IT / Cloud
Secures the underlying infrastructure, networking, identity services, and recovery capabilities.
Accountable: Internal Audit / Security Testing
Tests whether the controls actually work under realistic conditions.
| Control Area | Accountable Owner | Responsible Owner(s) | Consulted | Key Evidence / Output | Review Cadence |
|---|---|---|---|---|---|
| AI Governance & Policy | Research Leadership | AI Governance / Information Security | IRB, Privacy, Research Integrity, Research Administration | AI policy, approved-use standard, exception register | Annual + policy changes |
| AI System Inventory | AI Governance / IT | IT / Cloud, Information Security | PIs, Procurement, Data Governance | AI/agent inventory, model/vendor/version register | Quarterly |
| Research Data Classification | Data Governance | Data Owners, Privacy | PI, Information Security, IRB | Classification records, handling requirements | Onboarding + material changes |
| Participant Privacy & Confidentiality | IRB / Privacy | PI, Privacy, Information Security | Research Integrity, Data Governance | Privacy assessment, protocol safeguards | Per protocol + amendments |
| Human-Subject AI Risk | IRB | PI / Research Team | Privacy, Security, Research Integrity | IRB determination, protocol AI-risk documentation | Initial review + amendments |
| AI Informed-Consent Considerations | PI / IRB | Research Team | IRB, Privacy, Legal / Compliance | Consent language and protocol documentation | Initial approval + material AI changes |
| NIH / NSF Compliance | Research Administration | PI, Grants / Compliance Team | Research Integrity, Privacy, Security | Agency-specific compliance checklist, award records | Application + award lifecycle |
| AI Research Integrity | Research Integrity | PI, Research Team | IRB, Research Administration, AI Governance | AI-use disclosure, verification records | Per project + material changes |
| AI Agent Identity | Information Security | IAM / IT | PI, Data Governance, AI Governance | Agent identity, owner, service-account record | Creation + quarterly |
| Agent Least Privilege | Information Security | IAM, Application Owners | PI, Data Governance | Permission matrix, access-review evidence | Quarterly |
| Study-Level Data Segmentation | Data Governance | AI Platform / Application Team | PI, Security, Privacy | Study/tenant policies, segregation tests | Continuous + architecture changes |
| Cross-Study Leakage Prevention | Information Security | AI Platform / RAG Team | Data Governance, PI | Isolation test results, access-control evidence | Pre-production + recurring |
| AI / RAG Retrieval Authorization | Information Security | AI Platform Team | Data Owners, IAM | Retrieval-policy configuration, authorization tests | Continuous + system changes |
| AI Memory Isolation | Data Governance | AI Platform Team | Privacy, Security, PI | Memory scope, retention and deletion controls | Quarterly |
| Tool & API Authorization | Information Security | Application Owners / AI Platform Team | PI, IT, Data Owners | Tool allowlist, API permissions, authorization logs | Quarterly |
| MCP Security | Information Security | AI Platform / Integration Team | Data Governance, IAM | MCP inventory, scopes, tool authorization | Quarterly + MCP changes |
| Agent-to-Agent Delegation | Information Security | AI Platform Team | AI Governance, IAM, PI | Delegation policy, trust map, test results | Quarterly |
| Cloud & Infrastructure Security | IT / Cloud | Cloud Security / Infrastructure | Information Security, AI Governance | Architecture diagrams, segmentation evidence | Continuous |
| Network Egress Controls | Information Security | Network / Cloud Security | AI Platform Team | Firewall, proxy and destination allowlists | Continuous |
| Secrets & Credential Management | Information Security | IAM / Secrets Management | IT, AI Platform Team | Credential inventory, rotation evidence | Continuous |
| Third-Party AI / Vendor Risk | Procurement / Vendor Risk | Procurement, Security | Privacy, Legal, PI, Data Governance | Vendor assessment, contract / DPA, approval | Onboarding + annual |
| Research Data Sharing / DMS | PI / Research Administration | Data Governance | NIH/NSF Compliance, Privacy, Security | DMS Plan, sharing records, access controls | Per award + updates |
| Controlled-Access Data Security | Data Owner / Research Leadership | Data Governance, Security | PI, Repository Custodian | Data-use authorization, access logs | Continuous |
| AI Output Validation | PI | Research Team | Research Integrity, Domain Experts | Verification records, source checks | Per material output |
| High-Impact AI Decisions | Designated Human Authority | Qualified Reviewer | PI, IRB / Compliance as applicable | Approval record, decision rationale | Every high-impact action |
| Human-in-the-Loop Controls | Research Leadership | PI / Designated Reviewer | Security, IRB, Research Integrity | Approval workflow and reviewer assignment | Per workflow |
| Audit Logging | Information Security | IT / AI Platform Team | Research Integrity, Compliance | Tamper-resistant audit logs | Continuous |
| AI Agent Behavior Monitoring | Information Security | SOC / AI Security Team | AI Platform, PI | Telemetry, alerts, anomaly reports | Continuous |
| Research Safety Monitoring | Clinical / Research Safety Owner | Safety Team / PI | IRB, Security, Research Integrity | Safety-signal monitoring and escalation records | Continuous |
| Adverse-Event AI Integrity | Clinical Safety / Pharmacovigilance | Safety Operations | PI, Security, Quality | AE audit trail, validation evidence | Continuous |
| AI Conflict-of-Interest Workflow | Research Administration / COI Official | Compliance Team | PI, Research Integrity, Security | Disclosure, review and approval records | Per disclosure + annual |
| Separation of Duties | Research Leadership / Compliance | IAM + Workflow Owner | Internal Audit, Security | RACI, approval-policy configuration | Quarterly |
| AI Incident Response | CISO / Security Leadership | SOC / Incident Response | PI, Privacy, IRB, Research Administration | Incident plan, containment evidence | Annual + incidents |
| AI Security Testing / Red Teaming | Information Security | AI Security / Testing Team | AI Platform, PI, Data Governance | Test cases, findings, remediation records | Pre-production + periodic |
| AI Agent Blast-Radius Assessment | Information Security | AI Security / Architecture | PI, Data Governance, IAM | Agent blast-radius map, containment plan | Before production + material changes |
| Business Continuity / Recovery | IT / Research Leadership | Infrastructure / Platform Team | Security, PI | Recovery plan, backup and restoration tests | Annual |
| AI Retirement / Offboarding | AI Governance / IT | IT, IAM, Data Governance | PI, Research Administration | Decommission record, credential revocation | At retirement |
Before deploying a new research AI system, ask:
The hub becomes much more useful when each major risk has a dedicated technical spoke.
IRB AI Security: Human Subjects Research AI Risk 2026
Focus: Common Rule, IRB review, participant privacy, consent, AI agents.
Grant Compliance Risk: AI Conflict of Interest
Focus: FCOI, workflow integrity, separation of duties, excessive agency.
Research AI Identity and Authorization
Focus: AI identities, service accounts, least privilege, delegation, auditability.
AI Research Data: De-identification and Re-identification Risk
Focus: quasi-identifiers, linkage, k-anonymity, AI inference.
NIH and NSF AI Compliance Considerations
Focus: federal funding, research integrity, AI policy, data governance.
Cross Study Data Isolation Risk: AI Agents 2026
Focus: cross-PI, cross-lab, cross-study leakage, multi-tenant RAG.
AI Agents Manipulation Risk: Adverse Event Reporting Integrity
Focus: safety signals, clinical research, AI-mediated reporting integrity.
This architecture creates a strong topical cluster because every spoke addresses a different security boundary while remaining connected to the same institutional AI-security problem.
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.
HexTyx has also built test applications modeled on research workflows (grants and IRB, lab-notebook archives and study enrollment). We will publish results from them once live testing is complete, and have not claimed any here.
Each spoke below carries the findings most relevant to its boundary. Test your own agents with the HexTyx Playground.
Research institutions are unlikely to become less connected.
They are likely to become more connected.
AI agents will increasingly interact with:
datasets
repositories
laboratory systems
cloud platforms
research software
grant systems
literature
external tools
other agents
That means the traditional perimeter becomes less useful.
The new perimeter is:
Identity + Data + Agent + Authorization + Runtime
This is why research AI security must evolve from:
“Keep unauthorized people out.”
to:
“Ensure every AI action remains within the exact authority granted to it.”
AI security for research institutions in 2026 is not simply about securing an AI model.
It is about protecting an entire research ecosystem.
That ecosystem includes:
People
Participants
Data
Studies
Labs
PIs
Agents
Identities
Tools
Cloud systems
Federal funding
Scientific records
Institutional trust
The regulatory foundation is already substantial.
The Common Rule establishes human-subject protection and confidentiality considerations.
NIH's current 2026 policies address AI use, research integrity, scientific-data management, and controlled-access data security.
NSF's current PAPPG framework and supplements incorporate AI into its evolving research-integrity environment.
The technology layer is moving just as quickly.
AI agents can access tools.
RAG systems can retrieve information.
MCP can connect agents to resources.
Memory can persist context.
Multi-agent workflows can propagate actions.
The consequence is a new institutional security principle:
AI should have access only to what it is authorized to access, action only within what it is authorized to do, and influence only within the research boundary it was explicitly given.
That means:
Secure the identity.
Secure the data.
Secure the study boundary.
Secure the agent.
Secure the workflow.
Secure the research record.
Secure the human subjects.
And test the whole system—not just the model.
Because the future of scientific research may be increasingly AI-powered.
Smarter AI.
Safer Research.
Stronger Science.
Protected Participants.
Trusted Discovery.
Before deploying an AI agent into a research environment, ask:
“If this agent were manipulated tomorrow, what could it access, what could it change, whose data could it expose, and how quickly could we stop it?”
That answer defines the real AI risk university research profile.
Protect the research.
Protect the participant.
Preserve the science.**
Run the free playground scanner against your own AI application, or read the other guides in this series.