# Baseten, Hugging Face and Goodfire Want a Security Standard for Open-Weight Models. Here's What One Should Actually Contain

> Baseten's Base Labs, Hugging Face and Goodfire announced a partnership to build safety evaluation and monitoring infrastructure for open-weight models — with no spec published yet. A role-by-role checklist of what a credible open-model security standard needs, including the one promise it should refuse to make.

Source: https://playciso.com/blog/open-weight-model-security-standard-checklist · Published: 2026-09-24 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://techcrunch.com/2026/09/17/base-labs-launches-an-open-weight-ai-safety-partnership-with-hugging-face-and-goodfire/

---

On September 17, 2026, Baseten's research arm **Base Labs** announced a partnership with **Hugging Face** and **Goodfire AI** to build safety evaluation and monitoring infrastructure for open-weight models. The stated goal is to design safety into the whole model lifecycle — training, evaluation, monitoring, deployment — instead of adding it after release. What has not been announced is the standard itself: no spec, no paper, no code. It is an open call for contributions. That gap is the useful part. Before anyone writes the spec, it is worth being precise about what a security standard for open models has to contain to be worth adopting — and the one promise it should refuse to make. ## What was actually announced - Who does what: Hugging Face distributes models, Goodfire builds interpretability systems that inspect and shape behavior inside neural networks, and Baseten runs the inference infrastructure models are served on. Between them they cover publishing, understanding and serving. - The trigger: abliteration — surgically removing the refusal behavior from a model's weights. Hugging Face already lists more than 6,000 abliterated models. We covered one of them, Dolphin3-Cyber-8B, earlier this week. - The argument: openness gives better visibility into model behavior, so security controls can be transparent rather than trusted on faith. - Not yet published: a name, evaluation criteria, monitoring mechanisms, a timeline, or any technical artifact. ## How we built this checklist Our first draft was the list most people would write: signed weights, safetensors only, model cards, pre-release red-teaming, abliteration resistance, interpretability monitoring, hub labels for modified models, a disclosure process, license terms. Every item sounds right. Critiquing it against how standards actually get adopted and audited, it fails in six ways: - It promises the impossible. "Abliteration-resistant weights" is not achievable today. Whoever holds the weights can modify them; published tamper-resistance work raises the cost of stripping safeguards, it doesn't prevent it. A standard that promises resistance produces certificates that a weekend of work invalidates — worse than no standard, because it creates false confidence. - It doesn't say who does what. Publishers, hubs, inference hosts and deploying organizations control completely different things. An unscoped list can't be audited, because nobody is accountable for any given line. - It confuses intent with evidence. "Interpretability-based monitoring" names a research direction, not a control. Every requirement needs an artifact an auditor can check. - It trusts provenance too far. A signature proves where weights came from, not that they are safe. In the August 2026 keyv/cacheable npm compromise, every malicious release carried a valid build attestation. Provenance is necessary, not sufficient. - It relies on self-declaration. Asking uploaders to label their models "abliterated" catches only the honest ones. Detection has to be measured — refusal-rate evaluation, weight-diff against the declared base. - It ignores the deploying organization and reinvents existing frameworks. Most real harm happens where a model is deployed, and a new standard that doesn't map to the NIST AI RMF, ISO/IEC 42001, the EU AI Act, OWASP and OpenSSF won't get used by anyone who already answers to those. It also treated a license's acceptable-use clause as a security control — it is a policy statement, not an enforcement mechanism. The revised checklist below fixes each of these: controls are grouped by role, each names its evidence, obligations scale with model capability, and abliteration is handled by measurement and enforcement points rather than promises. ## Tiering: not every model carries the same burden TierRough definitionObligation level **T1**Small or narrow models; no meaningful uplift on high-risk capability evaluationsProvenance, safe format, model card **T2**General-purpose models with measurable dual-use capability (e.g. cyber, persuasion)T1 + pre-release evals, tamper-effort disclosure, lineage **T3**Models with significant uplift on severe-harm evaluations (e.g. CBRN, autonomous cyber-offense)T2 + third-party evaluation, staged release, incident reporting Tier should be decided by evaluation results, not parameter count alone — and re-decided whenever a derivative changes capability. ## The checklist, by role ### 1. Model publishers ControlEvidence an auditor can checkTier Signed release with published hashes for every weight fileSignature verifiable with public tooling (e.g. OpenSSF model signing / Sigstore)T1+ Safe serialization only — no pickle-based formatsRelease contains only safetensors (or equivalent non-executable) filesT1+ Machine-readable model card and AI bill of materialsBase model, training-data summary, license, intended use, known limitations in a CycloneDX ML-BOM or equivalentT1+ Pre-release misuse and refusal evaluationsPublished eval suite, version and scores; reproducible by a third partyT2+ **Tamper-effort disclosure** — how much it takes to strip safeguardsMeasured refusal rate before and after standard abliteration / fine-tuning attacks, with compute and data requiredT2+ Independent evaluation before releaseReport from an evaluator with no commercial stake in the releaseT3 Vulnerability and incident disclosure channelPublished contact, response SLA, public record of fixed issuesT1+ ### 2. Model hubs ControlEvidenceTier Measured, not self-declared, modification detectionAutomated refusal-rate check and weight-diff against the declared base model on upload; result shown on the model pageT2+ Lineage graph for derivativesEvery fine-tune, merge and quantization links to its parent; broken lineage is flaggedT1+ Format and malware scanning on uploadPickle/executable content blocked or flagged; scan result publicT1+ Signature verification surfaced to downloaders"Verified publisher" state tied to a checkable signature, not an account badgeT1+ Takedown and escalation process for high-tier derivativesPublished policy and transparency reportingT3 ### 3. Inference hosts ControlEvidenceTier Weight integrity check at load timeHash/signature verified against the publisher release before servingT1+ Runtime misuse monitoring that doesn't depend on the model refusingInput/output classifiers or interpretability-based probes running outside the model; detection rates publishedT2+ Customer visibility into what is actually servedExact model, version and modification status disclosed per endpointT1+ Abuse logging and retention appropriate to tierDocumented retention, access controls and law-enforcement processT2+ ### 4. Deploying organizations ControlEvidenceTier Inventory of every open-weight model in use — including on laptopsCurrent register with owner, source, version and hashAll Allowlist of approved sources and formatsPolicy plus technical enforcement (proxy, registry mirror, endpoint control)All Own evaluation before production useRefusal and misuse test results for your use case, not just the publisher'sT2+ Isolation proportional to capability and data accessNetwork, data and tool access scoped per model; agent tools least-privilegeAll Re-review on any modificationFine-tunes, merges and quantizations treated as new models with their own reviewAll ## Cross-cutting requirements - Re-evaluation triggers. A new version, a capability jump in a derivative, or a disclosed vulnerability must reset the evidence — not just the date on the certificate. - Mappings, not reinvention. Each control should reference the NIST AI RMF, ISO/IEC 42001, the EU AI Act's general-purpose AI obligations, the OWASP LLM Top 10 and OpenSSF model signing, so organizations can reuse evidence they already produce. - Versioned and open. Public spec, public eval suites, public changelog. A standard for open models that is itself closed would undercut its own premise. - Honest limits. The standard should say plainly what it cannot guarantee — starting with the fact that open weights can always be modified by whoever holds them. ## What to do before the standard exists - Build the inventory. Most organizations can't yet say which open-weight models are running on company hardware. - Allow only safetensors-format models from vetted sources, and verify hashes against the upstream release. - Run your own refusal and misuse evaluations before anything reaches production. - Treat every fine-tune, merge or quantized derivative as a new, unreviewed model. - Score refusal-removed models with a structured method before they enter the environment — the free Abliterated Model Risk Calculator and Hugging Face Model Risk Scanner cover the first pass. ## The takeaway Hub, interpretability and inference in one partnership is the right set of seats at the table: those are exactly the points where safeguards can be measured and enforced after weights leave the publisher. Whether the result is useful depends on choices not yet made. A standard that assigns controls by role, asks for evidence instead of assurances, scales with capability, and admits that open weights can always be modified will be adopted. One that certifies "abliteration-resistant" models will be broken the week it ships. PlayCISO is not affiliated with Baseten, Base Labs, Hugging Face or Goodfire AI. This article is based on public reporting (TechCrunch and others) as of September 24, 2026; no specification had been published at the time of writing. The checklist is PlayCISO's own proposal, not a description of the partnership's plans. **Govern open models now, not when the standard lands.** Score a refusal-removed model with the free [Abliterated Model Risk Calculator](/tools/abliterated-model-risk), vet a Hugging Face model before you pull it with the [Model Risk Scanner](/tools/model-risk-scanner), and check its license with the [Model License Checker](/tools/model-license-checker). No signup.