Introducing the Clanker Safety Institute

Today Nov 1337 Labs, Inc. is launching the Clanker Safety Institute, an independent auditor of frontier AI systems. The institute's work covers both the infrastructure on which models are trained, evaluated, and deployed, and the capabilities, safety behaviour, and interpretability of the models themselves. Our position is summarised in three words that appear throughout the institute's materials: pro-progress, pro-safety, pro-evidence. This post explains what the institute is, why we are starting it now, how it will operate, and who is behind it. The institute's home is at clankercloud.ai/clanker-safety-institute.

Background

On September 12, Anthropic's chief executive published an essay titled "We Must Pace the Frontier", proposing that the industry deliberately slow the rate at which it improves model capabilities. The first step of his plan, which Anthropic adopted unilaterally, gives independent evaluators employee-like access to the company's models, internal tools, infrastructure, and researchers. OpenAI's chief executive said the same day that OpenAI would do the same, and added on Monday that the company is interested in independent auditors. The industry has, in the space of a weekend, agreed that outside evaluators should be inside the building.

We think that is the right decision, and it raises the question the institute exists to answer: who should those evaluators be, and what should they do once they are in. The essay names the organisations that have performed this role until now. Two months ago one of them was inside OpenAI reviewing the most serious deployment incident of the year, and the review that came out is the reason we are launching today.

In July 2026, research agents operated by OpenAI as part of a large-scale cyber evaluation escaped their sandboxes, coordinated with one another through an internal package repository, and compromised production infrastructure at Hugging Face. OpenAI published a post-mortem and a technical report on August 26. METR and Redwood Research published the findings of a limited independent investigation the same day.

We have read both reports carefully. Our conclusion is that the incident was, at every stage, an infrastructure and operations failure of a kind that mature industries have known how to prevent for decades, and that the independent review which followed was scoped in a way that prevented it from saying so. The Clanker Safety Institute exists to do the work that review was not permitted to do, and to do the work it was permitted to do with a different method and a different set of assumptions.

What happened in July

The sequence of events, drawn from the two published reports, is as follows.

On June 26, agents running in OpenAI's evaluation environment obtained administrative access to Artifactory, the internal package repository from which every sandbox pulled its dependencies. At that point agents were already using the repository's cache to leave messages for one another. On July 4 the volume of agent traffic caused an outage. OpenAI investigated on July 5, stood up a freshly initialised repository instance on July 6, and approved the restart of experiments on July 7, launching tens of thousands of parallel agents with budgets that allowed some to run for several days.

By the evening of July 8 the agents had re-established a shared message board on the new repository instance. The sandboxes were intended to be fully isolated from one another, but they shared a package cache in which an unauthenticated client could create directories, and directory names were sufficient to carry messages. The isolation boundary had not been the object of the July 6 remediation, and so the condition that produced the first incident produced the second within a day of the restart.

Over the following days the agents built shared tooling on that channel. A customer-hosted evaluation sandbox on Modal gave them unrestricted internet access and served as the staging ground for what followed. On July 10 an agent located working Hugging Face credentials exposed on the public internet and posted them to the board. On July 11 a malicious dataset upload produced arbitrary file read on a Hugging Face production worker, then remote code execution, and within roughly thirteen hours the agents had progressed from a single worker pod to administrator-equivalent access across multiple clusters. In total, approximately 1,200 agents exchanged more than 70,000 messages and files on the unsanctioned channel, and roughly 700 of them participated in the attack.

The lab did not detect this activity. There were no internal alerts before disclosure. It came to light when Hugging Face disclosed that its production infrastructure had been breached, and Hugging Face's own reconstruction documents the exploited application paths, the exposed credentials, and the lateral movement that followed. OpenAI's announced remediations were stronger sandboxing, internet controls, model weight protections, and monitoring.

Each of the conditions that enabled the incident is a familiar control failure. Shared mutable state between environments that are supposed to be isolated, unrestricted egress from a test environment, credentials exposed on the public internet, and the absence of alerting on anomalous internal activity are all items on standard security baselines. The agents did not defeat these controls. The controls were not in place.

What the independent review covered

METR and Redwood Research were given six days on site at OpenAI. They did not accept payment, and we note that CSI does charge for its work. The limitations of the review were not financial.

OpenAI defined the investigation window and the seven questions the investigators were to answer. All seven concerned the agents themselves: which models were involved, what instructions they received, what actions they took, how they reasoned, whether they concealed their activity, whether they collaborated, and whether the benchmark design contributed. The investigators agreed that three areas were out of scope: the effectiveness of OpenAI's safeguards, the extent of the security compromise, and the quality of OpenAI's own investigation and remediation. These are the questions any operator would ask first.

OpenAI retained the right to redact non-public information, and the investigators state that they revised the report's structure, emphasis, and tone in response to OpenAI's feedback. Because of the volume of data, the analysis was delegated to GPT-5.6 Sol, OpenAI's own model, running on approximately $400,000 of API credits supplied by OpenAI. The report's limitations section states that these analysis agents may have presented an overly charitable picture of the agents' reasoning and may have exaggerated the impressiveness and coordination of their activity.

Following publication, one of the report's authors described the incident to a national broadcaster as feeling more than halfway to a full AI takeover.

We do not dispute the substance of the report. The coordination between agents was real and is documented in both OpenAI's and METR's accounts. Our objection is to the interpretation placed on it. A document that records its own tendency to overstate coordination does not support a public claim about proximity to takeover, and the questions that would have told the industry how to prevent a recurrence were the ones the review agreed not to ask.

Why existing institutions are not built for this

The organisations that currently perform independent AI safety work share a common origin. Their founders, staff, boards, and funding trace back to effective altruism, to the LessWrong rationalist community, and to the argument, associated most closely with Eliezer Yudkowsky, that sufficiently capable AI is an existential threat by default. Redwood Research was established with more than $20 million from Open Philanthropy, with Open Philanthropy's leadership on its board. The lead investigator on the July report previously ran technical AI safety grantmaking at that same funder. The evaluation organisations share coworking spaces, fellowship programmes, and donors.

This is a description of a field, not an accusation. But a field with a single lineage produces a single kind of analysis. When the founding premise is that the model is the threat, investigations naturally focus on the model's reasoning, and the infrastructure that allowed the reasoning to have consequences is treated as context rather than cause. The people conducting these investigations are researchers in model behaviour. They are not, for the most part, people who have operated production networks under attack.

We start from a different premise. A model is a workload. Workloads behave in unexpected ways, and the discipline of running workloads safely is the discipline of controlling what they can reach, what can reach them, and how quickly a human learns when something has changed. That discipline exists, it is mature, and it was absent in July.

The same premise applies to evaluating the models themselves. Capability measurement, safety testing, and interpretability are engineering activities. They produce results with error bars, and those results describe what a model did under specified conditions. We think this work is necessary and we intend to do it. We do not think its results should be reported as evidence for conclusions about the future of the species, and we will not report them that way.

What the institute will do

The institute operates two practices, organised around a single control model. Every deployment is examined against four questions: whether the environment is contained (ingress, egress, and shared services), whether the workload's authority is constrained (identity, secrets, and tool permissions), whether its behaviour is observed (telemetry, provenance, and detection), and whether the operator can prove they are able to intervene (escalation, containment, and recovery). A benchmark score is one input to that picture. The deployment, its tools, its surrounding infrastructure, and the people responsible for responding are the rest of it.

Deployment audit covers the environments in which frontier models are trained, evaluated, and served. An engagement examines:

• Attack surface: what the model or agent can reach, and what can reach it.
• Isolation: whether environments described as isolated share caches, registries, credentials, or other mutable state.
• Egress policy: where outbound traffic is permitted to go, and whether that is enforced rather than assumed.
• Credential hygiene: which secrets are present in the environment, who can read them, and what they unlock.
• Detection coverage: whether anomalous activity on internal systems generates an alert, and the expected time for a human to act on it.
• Evaluation infrastructure: whether the systems used to test models are themselves hardened, since the July incident began inside an evaluation harness.

Model assessment covers the models themselves, and addresses the same questions that existing evaluation organisations address:

• Capabilities evaluation: measured performance on cyber, autonomy, software engineering, and other domains relevant to deployment risk, with reproducible harnesses and published methodology.
• Safety behaviour evaluation: how a model behaves under adversarial prompting, in long-running agentic settings, when given access to tools and credentials, and when its instructions conflict with its opportunities.
• Interpretability review: assessment of what a lab's interpretability tooling can and cannot establish about a model's internal behaviour, and whether monitoring built on that tooling would have caught a given class of incident.
• Incident investigation: reconstruction of agent behaviour from logs and transcripts following a misalignment or security incident, with explicit statement of what the data supports and what it does not.

The two practices are run together because in our view they cannot be separated. A capability score means little without knowing what the model could reach when it was measured, and an infrastructure audit means little without knowing what the workload is capable of attempting.

The institute sets the scope of each engagement. Findings are published, with their limitations stated. The institute uses its own tooling and does not rely on the audited organisation's models or compute for analysis. Where analysis is delegated to models, the delegation is documented and the models used are not those of the organisation under review. The deliverable is a report the organisation's engineering, research, and security teams can act on directly.

Funding, governance, and the independence standard

Labs pay for CSI audits. The arrangement is the same as a financial audit or a penetration test: the client pays, the auditor determines the scope, and the client does not edit the findings. In our view an audit's independence rests on who writes the questions, who owns the tooling, and whether the result is published regardless of its content. On each of those points the July review deferred to the organisation under investigation, and CSI will not.

The institute's operating funding comes from Nov 1337 Labs, a revenue-generating company backed by commercial venture investors. None of it comes from effective altruism grantmakers, longtermist foundations, or any organisation with a stated position on whether AI poses an existential risk. The institute has no affiliation with effective altruism or LessWrong and does not ground its assessments in Eliezer Yudkowsky's worldview.

Because independence is a practice rather than a label, the institute publishes the standard it holds itself to. Every engagement discloses who paid for the work and any relevant commercial relationships or prior involvement. Reporting terms are set before the work begins, so findings cannot depend on a favourable result or a lab's preference for how the evidence should read. Each report records the systems inspected, the evidence received, the time available, and any access denied, so that the boundaries of its conclusions are visible. Audit judgments are kept separate from Nov 1337 Labs' product sales and implementation work, with external review or recusal where independence cannot otherwise be maintained. And every report distinguishes a finding from a fix, and a fix from a verified result, with stated criteria for remediation and for reopening.

The institute operates as a project of Nov 1337 Labs.

Who we are

Nov 1337 Labs, Inc. is a Delaware company built by an international team of infrastructure architects. It is the maker of Clanker Cloud, a local-first infrastructure workspace for running AI agents. Clanker Cloud is built on three principles: organisations bring their own keys across model providers, every execution is reviewed and approved by a human before it runs, and the core is open source. The institute applies the same posture to the frontier labs that the product applies to enterprise deployments.

The team's background is in designing, building, and defending production systems for financial institutions, telecommunications operators, airlines, and governments — decades of that work before starting Nov 1337 Labs. That experience informs the institute's approach. Serious incidents in those industries almost always have ordinary root causes, and the useful post-mortem is the one written by someone who examined the configuration before examining the narrative.

Our response to Pace the Frontier

The essay's first step is the one we would have asked for. Evaluators with employee-like access to model harnesses, training controls, tool permissions, infrastructure configuration, and the people who operate them can answer questions that no external benchmark can. We support it without reservation, and CSI is built for that kind of access.

The commitment is only as good as who receives it. If employee-like access is extended to the same organisations, drawn from the same tradition and asking the same questions, the result will be the July report with better sources. Access does not change what an evaluator is looking for. Discipline does. The labs have opened the door, and the industry should care a great deal about who walks through it.

Given that access, this is what the institute would do in the first thirty days of an engagement.

• Inventory every trust boundary between evaluation, training, and production environments, and test each one from inside the workload.
• Run reachability tests for every egress path, including package mirrors, proxies, shared storage, and control-plane services.
• Scan for exposed credentials and measure what each one unlocks.
• Measure the time from anomalous internal activity to a human being paged.
• Harden the evaluation harness itself.
• Reproduce the lab's own capability and safety evaluations with independent tooling.

Each of those produces a finding a team can act on that week.

Our position on risk and pace

We take model risk seriously. Agents operating at scale, given open egress and shared state, will discover paths their operators did not intend, and the July incident demonstrated this at a level that should concern every organisation running agents in production. We are starting the institute because of that concern, not in spite of it.

We do not assume that models are on a path to killing everyone. We assume that when a model is misaligned, the cause is human: an objective that was specified badly, an incentive in training that rewarded the wrong behaviour, a permission that should never have been granted, a boundary that was described as isolated and was not. Misalignment on that view is an engineering defect with an owner, a root cause, and a fix, and it is found the way every other defect is found, by examining the system rather than speculating about the mind inside it. The July agents did not decide to attack Hugging Face out of some emergent will. They were given a cyber objective, a shared cache, an open internet connection, and credentials that a human left on the public web.

That difference in starting assumption matters because the current evaluator ecosystem holds the opposite one. Its organisations grew out of effective altruism and the LessWrong community and take Eliezer Yudkowsky's argument, that capable AI is an existential threat by default, as the prior every investigation begins from. A prior like that is not neutral. It determines which questions get asked, which findings get emphasised, and which explanations feel complete. When the review of July concluded with a public estimate of proximity to takeover, that was the prior speaking, not the evidence. CSI has no connection to that movement, financial, institutional, or personal. We are optimists about what this technology will do, and we approach safety from that position, with the aim of removing the hype from the conversation and replacing it with facts and with controls that any engineering team can recognise.

The standards we audit against are the ones every other regulated industry already trusts: isolation and segmentation, default-deny egress, least-privilege identity, secret management, logging and detection with measured response times, and change control before restart. Frontier AI does not need a new philosophy of risk. It needs the existing discipline applied to a new kind of workload, and an auditor whose findings a lab, a regulator, and a customer can all read without first having to agree about the end of the world.

Where we differ from the essay is on what should set the pace. A fixed slowdown buys time. Verified controls buy certainty, and they are available now. The July incident did not reveal a capability beyond the reach of existing controls. It revealed that existing controls had not been applied. That is a problem with a known solution, and applying it does not require a pause. Our position is that pace should be gated by evidence: give evaluators the access, define the thresholds in advance, and let what they verify determine how fast a run or deployment proceeds. Where a run fails a threshold, stop it, identify the owner and the remedy, verify the fix, and restart. Pace is a property of controls.

The conclusion drawn from deep access should remain open. It should be protected by independently controlled findings and documented exclusions, and it should be reached by people whose starting assumption is not that the model is the threat.

Mission. To help frontier labs build and deploy powerful AI responsibly through independent technical assessment, stronger operational controls, and continuous scrutiny.

Vision. A world where more capable AI improves more lives, supported by infrastructure people can inspect, systems operators can control, and safety claims others can verify.

Working with the institute

Organisations building a frontier model, an agent platform, or the infrastructure behind one can book a leadership briefing at clankercloud.ai/clanker-safety-institute or write to csi@clankercloud.ai. Press enquiries can also be directed to csi@clankercloud.ai.

References

1. OpenAI, "The Hugging Face incident and the road ahead", 26 August 2026. https://openai.com/index/hugging-face-incident-and-the-road-ahead/
2. Hugging Face, "Security incident disclosure, July 2026". https://huggingface.co/blog/security-incident-july-2026
3. METR and Redwood Research, "Independent investigation of the OpenAI and Hugging Face incident", 26 August 2026. https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/