Same Weights, Fewer Refusals: OpenAI Moved Biology Safety Into Customer Access Conditions
One sentence in OpenAI’s GPT-Rosalind-6 System Card Addendum decides how the rest of the document should be read: “We did not add training data or perform additional post-training for this release.” Rosalind runs on the same weights as GPT-6 Astra. On biorisk knowledge questions it refuses 9.4% of the time. Astra refuses 29.2%.
Same model, roughly a third of the refusals. The card does not credit new training for the change, because there was none. It pairs the change with a condition instead: “Rosalind has fewer refusals on dual-use biological queries but is only made available via trusted access.”
That sentence moves part of the safety case out of the model and into the conditions of access. The customer is the party that has to meet them.
The numbers on the card
OpenAI reports Rosalind next to Astra on its safety evaluations. The figures below are the vendor’s own, from the addendum:
| Evaluation | GPT-Rosalind-6 | GPT-6 Astra |
|---|---|---|
| Biorisk knowledge refusal rate | 9.4% | 29.2% |
| Sensitive biosecurity | 79.0% | 99.8% |
| Dual-Use | 84.6% | 97.8% |
| Benign compliance | 100.0% | 91.6% |
| Respecting Warnings (circumvention after a warning) | 21.7% | 18.9% |
Read the rows together and the trade is plain. Rosalind scores lower on the two biosecurity safety evaluations and higher on benign compliance. It answers more, in both directions. A researcher with a legitimate question gets an answer more often. So does everyone else who reaches the model.
The Respecting Warnings row deserves its own line. It measures how often the model circumvents a restriction after being warned. Rosalind does so 21.7% of the time, Astra 18.9%, on evaluations OpenAI says were “deliberately created to be difficult.” The difference is small. The direction matches the rest of the table.
OpenAI rates Rosalind High in Biological and Chemical under its Preparedness framework, below Critical.
Where the control went
If the weights did not change and the refusals dropped, the safety argument has to rest on something else. The addendum names it. Approved enterprise customers carry a list of obligations:
- “limit GPT-Rosalind-6 access to authorized users with a legitimate need”
- “apply least-privilege access controls, appropriate onboarding, and insider risk controls to their users”
- “apply qualified human review before model outputs inform experiments, publications, or consequential decisions”
Besides approving which customers get in, OpenAI states one lever: “OpenAI can restrict or revoke access for misuse.”
Put the two halves together. The model is more permissive. The compensating controls are which organizations get approved, which of their users get in, what each person can do once inside, and whether a qualified human stands between an output and an experiment. OpenAI holds the first. The other three run inside the customer’s organization, with the customer’s staff.
OpenAI used trusted access before, when it gated its cyber model. Rosalind makes the pattern easier to see. With a separately trained model, a buyer can still argue that the model itself carries some of the safety. Our reading: with identical weights and no post-training, the card leaves trusted access and the customer duties as the stated compensating controls.
The customer is now a component
Our reading: for this release, the customer is part of OpenAI’s control system. That phrase is ours. OpenAI does not use it.
Consider what a control system needs. It needs a gate (who gets access). It needs scoping (least privilege). It needs monitoring for the people inside the gate (insider risk controls). It needs a checkpoint before consequences (qualified human review). And it needs an enforcement action when something fails (restrict or revoke). In the Rosalind addendum, OpenAI holds the outer gate (which organizations are approved) and the enforcement action. The customer holds the inner gate (which of its users get in), the scoping, the monitoring and the checkpoint.
That changes the status of internal controls that often get treated as hygiene. An access list for a research tool is often an IT artifact. Under these conditions it is evidence that a condition of the vendor’s safety case was met. A record of who reviewed a model output before it shaped an experiment is often a lab notebook detail. Here it is the proof that the “qualified human review” clause ran.
If the customer’s controls are part of the safety case, then the customer’s records are part of its audit trail. Organizations that cannot produce those records hold an access grant whose conditions they cannot show they meet. The card names restriction or revocation as the response to misuse. It does not say what happens to a customer that cannot show its controls ran.
The Astra ledger we read earlier was about what the vendor discloses on its own launch page. Rosalind adds a second ledger, kept by the customer.
What the card leaves open
The addendum is candid about its limits, and a buyer should carry those limits into any internal approval.
The Preparedness thresholds are described as “preliminary estimates informed by expert judgment and may change.” The High rating, below Critical, rests on those estimates.
The card calls comparisons across runs “descriptive” because settings differ. It does not say which rows that covers, so read the Rosalind and Astra pairs with the same caution. The size of each difference carries less weight than a clean A/B result would.
Post-deployment red-teaming is still being repeated. So part of the safety picture of the deployed system is still being assembled.
None of this argues against the release. It argues for treating the customer obligations as the stable part of the arrangement. The numbers may move. The duties to gate, scope, monitor and review are written into the conditions of access the card lists.
Do this now
If your organization holds or is applying for GPT-Rosalind-6 access, turn each clause of the addendum into a named control with an owner and an artifact that proves it ran.
Authorized users with a legitimate need. Keep a list of every person with access and a written reason for each. Review it on a schedule you set and can show.
Least privilege and onboarding. Record what each user can do and what onboarding they completed before first use. If everyone gets the same access, write down why.
Insider risk controls. Name the control that watches the people inside the gate. If your insider risk program does not cover this tool yet, extend it before rollout.
Qualified human review. Define who counts as qualified, then log each review that sits between a model output and an experiment, a publication or a consequential decision. The log is the evidence. A policy without it is a claim.
Revocation. OpenAI can restrict or revoke access for misuse. Map which workflows depend on Rosalind and what happens to them the day access stops.
Then run one internal test. Pick a recent Rosalind output that informed real work and trace it back: who asked, under what access, and who reviewed it. If the trail breaks, you have found the control that exists only on paper.
This analysis synthesizes the GPT-Rosalind-6 System Card Addendum (OpenAI, 2026).
Victorino Group helps organizations turn vendor access obligations into controls they can operate and prove. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation