AI for Research Efficiency, episode 9: Your data, your keys, your campus
Narration: an AI-generated voice (ElevenLabs).

[0:00] Before you hand it over
Before you hand an agent a file, stop and ask where it's going.
Three questions: where does it go, does it belong there, and whose rules apply?
AI for Research Efficiency. Episode 9: Your data, your keys, your campus.
Last time, many agents at once: several terminals, or one agent that splits the work.
This time, the rules around all of them, with a checklist at the end.

[0:38] 1. Your plan decides
One: your plan decides where it goes.
Whatever the agent reads goes to the company that runs the model, along with your request.
On a personal plan, it may be used to train future models, unless you switch that setting off.
On a work, school or API plan, it isn't used for training by default.
So check which plan you're on, and its setting, before you start.

[1:09] 2. What never goes in
Two: what never goes in.
Student records, health data, study participants' data under an IRB protocol, export-controlled work, and other people's unpublished work.
None of it goes to an agent, unless your campus has approved that tool for that data.
At the University of Arkansas, for example, data comes in four classes: restricted, highly sensitive, sensitive, and public.
Restricted and highly sensitive data may only go into tools the university licenses or approves for it.

[1:50] 3. Keys
Three: keys.
A key is a password your scripts use, and some keys can spend money.
Put it in a file named .env, and list that file in .gitignore, so it never reaches a repository.
Then give the agent the key's name, never its value. A pasted key goes to the vendor, and stays in the session's history.
Without a rule, an agent reads the file when you ask. Here, Codex prints the value into the conversation.
So write the rule into your instruction file: never read or print .env. Claude Code can enforce it with a deny rule.
Codex can deny the file in a permission profile. Antigravity's sandbox is meant to block it; in our test, it read the file anyway.
Give each project its own key, with only the access it needs. If one leaks, revoke it first.

[3:00] 4. Someone else's work
Four: someone else's work.
If you review grant proposals, the funders have spoken. At NIH, reviewers are prohibited from using AI tools in analyzing and critiquing NIH grant applications and R&D contract proposals.
NSF reviewers are prohibited from uploading any content from proposals, review information and related records to non-approved generative AI tools.
A journal's peer review has rules of its own. Read them before you open the manuscript.

[3:36] 5. Your campus's rules
Five: find your campus's rules.
At the University of Arkansas, any AI tool used for university business must be vetted and approved.
Its approved list names chat tools. On 4 October, none of the three agents in this series was on it; for those, there's a tool exception request.
Your campus will have its own list. Search its website for approved AI tools, or ask its IT security office.

[4:09] Try it
Pause here, and check two things: your tool's training setting, and your campus's approved list.

[4:19] Review and next
So: check your plan, keep protected data out, keep keys in .env, keep reviews out, and find your campus's list.
Next: research APIs, a ladder of keys.