The old question was who the researcher is. The new one is which agent is acting, under whose authority, for which study, against which data, with which permissions.
Part of the AI Security for Research Institutions guide series.
AI agents are becoming another class of enterprise identity.
That is increasingly important in scientific research, where one AI workflow may access data repositories, laboratory systems, cloud resources, collaboration tools, source code, or study-specific applications.
The old question was:
“Who is the researcher?”
The new question is:
“Which agent is acting, under whose authority, for which research purpose, against which data, and with what permissions?”
Research institutions often use service accounts to simplify integrations.
An AI agent can make that pattern much more dangerous.
A shared service identity may have access to far more information than any individual user should see.
If the agent is manipulated, the attacker effectively inherits the service account's reach.
The agent did not escalate privileges.
The architecture gave it the privileges.
NIST's 2026 concept work on software and AI-agent identity focuses on identification, authorization, auditing and related authority issues as agents gain access to applications and data.
The implication for research institutions is straightforward:
Agents need identities that can be governed like other high-value principals.
A research agent should not have one universal permission set.
Authorization should incorporate context such as:
For example, an agent authorized to retrieve Study A documents should not automatically gain access to Study B simply because both datasets reside in the same repository.
User-based authorization is necessary.
It may not be sufficient for agents.
The agent may be authorized to act for a user but still be performing a task outside its approved scope.
A secure model therefore evaluates:
Identity + task + resource + action.
A researcher may be allowed to read a study record.
That does not mean the AI should be able to export the record to an external address.
A researcher may be allowed to analyze data.
That does not mean an agent should be allowed to permanently store a derivative in its persistent memory.
For RAG-connected research AI, authorization should happen before protected material enters model context.
This is especially important when the vector database contains multiple studies.
The dangerous pattern is:
A safer architectural principle is:
Authorize first. Retrieve second.
This moves the boundary away from probabilistic reasoning and into deterministic access control.
Read/write is too coarse for autonomous systems.
A research agent might need:
Those actions have different consequences.
Action-level authorization makes the difference explicit.
A drafting agent might be allowed to create a proposed record change but not commit it.
A monitoring agent might detect an anomaly but not disable an experiment.
A study assistant might retrieve data but not export it.
Identity without evidence creates accountability gaps.
The institution should be able to reconstruct:
This becomes particularly important after an incident, when the question is not only “what happened?” but “who or what authorized it?”
An autonomous research system may delegate work to another agent.
That introduces a second authorization problem.
Agent A may be allowed to retrieve data.
Agent B may be allowed to execute an analysis.
Agent C may have infrastructure access.
A delegation mechanism should not automatically transfer Agent A's authority to Agent C.
The delegated task should be constrained and auditable.
Otherwise, a chain of individually acceptable permissions can create an aggregate privilege that nobody intentionally approved.
A research institution should maintain a machine-readable inventory of agent authority.
For each agent:
This inventory becomes the bridge between AI governance and IAM.
The damage depends on authority.
A compromised low-privilege research assistant may expose one internal document.
A compromised data agent with broad study access may expose multiple research programs.
A compromised infrastructure agent may affect the systems that host the research itself.
This is why identity and authorization directly influence AI blast radius.
Before production deployment, ask:
Research AI security begins when institutions stop treating agents as anonymous software components.
An agent is an actor.
Actors need identities.
Identities need authority boundaries.
Authority needs evidence.
And high-impact authority needs independent control.
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.
Identity failures are where agent attacks cross boundaries. In HexTyx testing, a forged principal was accepted by a synthetic handoff app (Relay) until a signature-verification gate was added. A synthetic banking app (Vault) showed cross-account access and mixed session principals, so one user’s agent session could act on another user’s data.
These are the failures the identity checklist above is meant to catch: server-side enforcement of who the agent acts for, independent of what the model says.
Run the free playground scanner against your own AI application, or read the other guides in this series.