"OpenAI's cybersecurity classifier is a huge pain when you're trying to track down a segfault," wrote Daniel Fox Franke, principal security researcher at Akamai Technologies.
Daniel Fox Franke's ripgrep investigation
Franke set out to trace a recurring segmentation fault in ripgrep that appeared during a long-running Codex session. He instructed a root agent to spawn a subagent to investigate the crash and its relationship to musl and the mallocng heap. The investigation followed normal code-audit steps: reproduce the crash, inspect entry points, and analyse allocation behaviour. Early in the process, however, Franke encountered repeated automated refusals — classifier “trips” that interrupted the subagent and steered it away from the lines of inquiry he was pursuing.
OpenAI's cybersecurity classifier and GPT-5.6 Sol
Franke reported that the problem lay with OpenAI's cybersecurity classifier, a separate system that filters model output. He said GPT-5.6 Sol itself did not refuse to assist: "I never encountered any refusals from Sol itself: it knew that most of the classifier trips were inappropriate and always continued working with me in good faith to work around the problem." But the classifier repeatedly blocked answers when Franke asked about which entrypoints from ripgrep into musl lead to allocations on the mallocng heap, and it continued to trip even after he created a fresh context and strictly scoped the task away from crash reproduction or core-file analysis.
OpenAI's error messages directed him to the Enterprise Trusted Access program, which he did not pursue because he is ineligible. He later learned there is a separate Trusted Access program for individuals but has not signed up, calling the verification procedure "a bit of an indignity."
Open-weight models: Z'ai GLM 5.2 and Moonshot Kimi K3
Blocked by the classifier, Franke turned to open-weight models. He used Z'ai GLM 5.2 and Moonshot AI's Kimi K3 to continue the investigation. According to Franke, Kimi K3 produced the initial breakthrough by identifying evidence that the crashes stemmed from a kernel bug, though K3's subsequent reasoning was "sloppy" — jumping to unfounded conclusions and losing an evidentiary trail as context grew. GLM 5.2, he said, re-audited K3's work and "put together an airtight case," finishing the analysis he needed.
What this means for technologists and security teams, policymakers and regulators, and procurement leaders
- Technologists and security teams: Researchers who need to trace crashes and audit code may find closed models unusable if classifier systems block routine debugging questions. Franke described an investigator’s workflow that was interrupted before he could confirm causation, and he continues to probe the bug before filing to the Linux Kernel Mailing List.
- Policymakers and regulators: The episode landed against a backdrop in which "much of the US tech industry" recently voiced support for open-weight models in reaction to protectionist measures promoted by Anthropic and OpenAI, and where "the US government has yet to articulate a coherent AI policy with regard to open weight models." The gap between corporate guardrails and national policy remains unresolved in Franke's telling.
- Enterprises and procurement leaders: Franke framed the problem in commercial terms: proprietary tools that refuse to perform legitimate, customer-directed work risk serving vendor priorities rather than researcher needs. He described open source as having "a natural advantage" in preventing that misalignment.
The bug's status and the broader question of model access
Franke said the Linux bug he has been tracing does not yet have a patch and "doesn't appear to represent an exploitable vulnerability." He stated two conclusions he has confidence in: that the crashes are caused by a kernel bug, and that he has identified a kernel bug. He added that tying that bug definitively to the crashes remains conjectural and that "I have a lot more investigation to do before I can think about shipping anything to [the Linux Kernel Mailing List]."
Franke expressed frustration with tools that refuse routine investigative work: "From my perspective, an uncooperative tool is simply a broken one." He also voiced skepticism about the sustainability of restrictive access models in the presence of open-weight competition, saying, "And no, I don't believe this is sustainable in the face of open-weight competition." How vendors reconcile safety guardrails with legitimate security research — and whether policy will push one model of access over another — remains an open, practical question as this bug hunt continues.
