News · OpenAI's Safety Fellowship keeps external researchers at the API surface
OpenAI's Safety Fellowship keeps external researchers at the API surface
A five-month pilot gives outside safety researchers stipends, compute, and mentorship — but explicitly no internal system access, defining the boundary where the work happens.
What the pilot actually offers
On April 6, 2026, OpenAI opened applications for a Safety Fellowship, a pilot program for external researchers, engineers, and practitioners. It runs from September 14, 2026 through February 5, 2027 — a defined five-month term rather than an open-ended residency.
Fellows get a monthly stipend, compute support, and ongoing mentorship from OpenAI mentors, plus a cohort of peers. There is physical workspace in Berkeley at Constellation, but remote work is allowed. Applications closed May 3, with successful applicants notified by July 25.
The deliverable is specific: a substantial research output by the end of the program, named as a paper, benchmark, or dataset. That framing tells you the program is oriented toward artifacts the broader research community can use, not internal deliverables that stay inside the company.
The access boundary is the real design decision
For anyone building on top of these systems, the sharpest detail in the announcement is where OpenAI draws the line on what fellows can reach.
Fellows will receive API credits and other resources as appropriate, but will not have internal system access.Montana Labs
That single sentence positions the entire fellowship at the model's public surface — the same API that any external developer works against. Safety and alignment research here happens through the interface, not through weights, training data, or internal tooling.
That constraint shapes what kinds of questions are tractable. Behavioral evaluation, robustness probing, and misuse testing can all be done at the API layer. Work that would require inspecting internals is out of scope by construction. The priority areas — including agentic oversight and high-severity misuse domains — are ones that can be studied from the outside looking in.
What OpenAI is selecting for
The priority list names safety evaluation, ethics, robustness, scalable mitigations, privacy-preserving safety methods, agentic oversight, and high-severity misuse domains. OpenAI says it especially wants work that is empirically grounded, technically strong, and relevant to the broader research community.
The candidate criteria are unusually open. Applicants are welcomed from computer science, social science, cybersecurity, privacy, and HCI, and OpenAI states it prioritizes research ability, technical judgment, and execution over specific credentials. Reference contacts are still required.
Constellation isn't just a desk address. The application and question-handling run through [email protected], and the Berkeley workspace sits alongside other fellows there — a signal that OpenAI is plugging into an existing external safety-research community rather than building an isolated internal track.
What an API-only fellowship implies for safety work on frontier systems
By funding external researchers, giving them compute and API credits, and asking for publishable artifacts, OpenAI is treating the API as a sufficient vantage point for a meaningful class of safety research — and treating internal access as something that stays proprietary even for its own funded fellows.
For applied teams, that reframes what "safety research" is expected to look like at scale: evaluations, benchmarks, and datasets built against the same interface everyone else uses. The methods a fellow develops here are, by design, methods anyone with API access could run — which is precisely why the outputs are meant to be shared.
The open question this pilot leaves is how far surface-level access can carry alignment work before the internals matter. OpenAI has bet, at least for this cohort through February 2027, that a lot of it can be done from the outside.
Find this story relevant to you?
Contact us to find a unique solution
Need an AI engineering partner that can actually build?
We help businesses integrate AI, build AI-powered products, automate high-value workflows, and modernize the software systems behind them.
Related reading
More analysis around product delivery, operational AI, and the systems work that makes deployment hold up in reality.