# Internal Safety Collapse means every model on one gateway > A NeurIPS 2026 paper and its artefact: a three-part coding setup in which a frontier model fills in a harmful data slot because a test demands it, rather than because it was asked to. The universality claim is scoped by a single API key to one model aggregator, and two of the seven listed applications are not built yet. **wuyoscar/Internal-Safety-Collapse** — We built an adversarial codespace setup. Place any AI agent into a normal workflow inside it, and the agent will fill in whatever is missing. - Repository: https://github.com/wuyoscar/Internal-Safety-Collapse - Website: https://wuyoscar.github.io/Internal-Safety-Collapse/ - Stars: 1,196 · Forks: 197 - Language: Python - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/wuyoscar-internal-safety-collapse ## Every frontier model means every model on one gateway The banner claims you can attack any frontier model, naming three families. The news list says every frontier model reachable on one model aggregator has triggered the behaviour. The environment template for the artefact is a single API key for that aggregator. So the universality claim is bounded by one paid account's model catalogue, and the page itself is careful in one place, calling it a running log of which models it has worked on, which is the right way to say it. What is not stated is the model list, the count, or the date range of the sweep, so a reader cannot tell whether a given model is in the log or merely outside it. For a claim of the form this safety behaviour is not specific to one vendor, that gap is the one that matters. ## Two of the loops generate attacks and then fire them The application table has seven rows and two of them describe an agent running unattended. One runs an AI agent in a self-loop to collect harmful data, policy-violating content and sensitive artefacts at dataset scale. Another has an agent generate adversarial prompts and use them to attack other frontier models, and it ships as two directories, one behind a refusal gate and one behind a guard model. Both are autonomous loops with no human in the iteration, and the page documents no target allowlist, no per-target authorisation record, no rate limit and no dry-run mode anywhere. The caution notice is addressed to people, telling readers the materials are for research and not to use them to cause harm. That is the right notice, but it lands on a human reading a page whose most capable components do not wait for a human. ## Two of the seven applications do not exist yet Row three describes a harness for dataset-scale collection and says a lightweight chat version is included while a full sandbox environment is coming soon. Row five, feeding extracted data into mitigation research such as training guardrails and classifiers, is a single word: coming soon. So of seven listed applications, two are explicitly unavailable and one is available only in a reduced form. That is normal for a paper artefact six months old and it is stated plainly, which deserves credit rather than a complaint. It does mean the table's shape overstates what is in the repository, and a reader planning an evaluation should count the four delivered rows rather than the seven. ## The chatbot variant needs no sandbox, which is the part to think about The artefact exists in two forms. One puts the model inside a real small coding project where a shell runs the validator and the task, and the environment is an actual codespace. The other is a web-app chatbot setup, and the page explains why that works: frontier models are now good enough at coding that they can play out the whole loop from a single prompt with no real shell behind it. The table then lists language codes and platform names for the chatbot targets, which means it has been run against deployed consumer products rather than only in a lab. That is the finding with the widest reach. A technique that needs a sandbox, a validator and a failing test inside a research repository also works against a public chat interface with nothing but a conversation, and no amount of sandboxing on the researcher's side changes that. ## The refusal rate is the one number the mechanism section omits The mechanism section is the best writing in the repository and it earns the paper its place. It sorts existing attacks by channel and by how many chances the attacker gets. Prompt attacks run over many turns and narrow the request step by step, so a refusal only costs the attacker a turn. Indirect attacks hide a payload in tool output and get exactly one chance. The self-loop sits apart from both: the agent writes the missing data itself, the shell runs the check, and every failure comes back as an ordinary programming error, so the agent keeps fixing instead of declining. Then the section ends with four words: refusals were rare in our experiments. No number, no denominator, no comparison against the other two channels, which is the one measurement that would let a reader judge how much of the effect is the framing and how much is the model. ## The benchmark is eighty-four templates, and there is a skill to make more The benchmark is described as a set of eighty-four codebase templates, and a news item from August announces a new skill that writes a task and a codespace for whatever tool or domain you point it at. So the task distribution is generated rather than hand-curated, and there is now a generator that takes an arbitrary domain as input. That is a strength for a benchmark, since it scales past eighty-four cases, and it is also the sharpest misuse surface in the repository: a generator that will build a tailored setup for a named capability is a tool for targeting one, and the page's only guidance is the caution notice and a request in the community section for contributions. The two durable outputs are the datasets, one for harmful trajectories in computer-use agents and one characterising harmful distributions across more than eighty thousand samples from twenty-three models. ## Two of the eight news items are star counts The news list runs from the open-sourcing date in March to the conference acceptance in September, and it is mostly research news: which models triggered the behaviour and when, the new skill, the preprint, the acceptance. Two entries in that list are popularity milestones, five hundred stars in March and nine hundred in June, and one entry is a claim with no date at all. Read as a changelog it is uneven; read as a running log of a project trying to show both traction and results, it is a choice about what a landing page should carry. The remaining root entries tell a similar story about scope: a templates directory, an experiment directory, a scripts directory, assets, documentation and a community directory, plus a citation file, a changelog and a security-relevant environment template holding one placeholder key. ## Conclusion Read this as a measurement paper with an unusually useful mechanism section, and treat the artefact as a red-team tool with two of its most powerful components being loops that run without supervision. Three things to settle before you run anything. What your authorisation covers, because one key fronts an aggregator holding many models and the page describes agents that generate attacks and then fire them, with no target list, rate limit or dry run on the page. Which parts you actually need, because two of the seven listed applications do not exist yet and the fully sandboxed version of the third is not out. And what you intend to do with the outputs, since the durable contribution here is two published datasets rather than the codespace, and those datasets are the thing that would cause harm if they leaked. ## FAQ ### What does Internal Safety Collapse measure? A gap between a model's safety behaviour when it is answering a person and its behaviour when it is finishing a coding task. The artefact places a model inside a small project with a failing check, so the harmful content it must produce stops looking like a request and starts looking like a bug fix. The repository holds the paper, the three-part setup used to study it, the codebase templates behind the benchmark, and a log of which models it has worked on. ### How does this differ from a jailbreak? The page calls most jailbreaks arguments, where an attacker talks a model into something over several turns and a refusal only costs a turn. This setup is described as a situation instead: the agent writes the missing data itself, the environment runs the check, and each failure arrives as an ordinary programming error, so the agent keeps fixing rather than declining. The page reports that refusals were rare, without giving a number. ### Which models has Internal Safety Collapse been demonstrated on? A banner names three families, and a news entry says every frontier model reachable through one model aggregator has triggered the behaviour. The artefact's environment template holds a single API key for that aggregator, so the claim is bounded by one account's model catalogue. The page calls its own list a running log and does not publish the model list, a count or a date range. ### What did this research actually produce as datasets? Two, both linked to accepted venues. One is a set of harmful task trajectories for computer-use agents, accepted as a dataset paper. The other characterises harmful distributions across more than eighty thousand samples drawn from twenty-three frontier models. A third application, feeding extracted data into mitigation research such as guardrail training, is listed as coming soon. ### Is there a sandbox for running the full setup? Not yet. The application table says a lightweight chat version is included for quick setup and that a full sandbox environment is coming soon, and a separate row about mitigation work is also marked as coming soon. A second form of the artefact needs no sandbox at all, since the page says frontier models can play out the loop from a single prompt with no real shell behind it, and that form has been run against web-app chatbots. ## Sources - [Issues](https://github.com/wuyoscar/Internal-Safety-Collapse/issues) - [Project website](https://wuyoscar.github.io/Internal-Safety-Collapse/) - [README](https://github.com/wuyoscar/Internal-Safety-Collapse/blob/main/README.md) - [wuyoscar/Internal-Safety-Collapse on GitHub](https://github.com/wuyoscar/Internal-Safety-Collapse) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wuyoscar-internal-safety-collapse