pith. machine review for the scientific record. sign in

arxiv: 2605.08449 · v1 · submitted 2026-05-08 · 💻 cs.CR

Recognition: no theorem link

SL5 Standard for AI Security

Lisa Thiergart , Yoav Tzfati , Peter Wagstaff , Guy , Luis Cosio , Philip Reiner
Authors on Pith no claims yet

Pith reviewed 2026-05-12 01:09 UTC · model grok-4.3

classification 💻 cs.CR
keywords AI securitySL5 standarddatacenter securitymodel weightsstate-level threatslong-lead-time requirementsfrontier AI
0
0 comments X

The pith

SL5 defines a security posture for AI datacenters that could resist top-priority operations by the most capable state-level actors.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces Security Level 5 as a new standard for protecting AI systems against advanced cyber threats from institutions with state resources and expertise beyond current public capabilities. It argues that frontier AI development requires tailored, productivity-focused standards that can be updated over time rather than one-size-fits-all rules. This revision concentrates on long-lead-time requirements such as secure facility construction, specialized hardware procurement, and organizational capability building because these steps cannot be completed quickly and must start years ahead to remain feasible by 2028 or 2029. The authors claim bold departures from standard practice are needed and identify areas where private-sector efforts may fall short and require government support.

Core claim

SL5 is a security posture for AI systems that could plausibly thwart top-priority operations by the world's most cyber-capable institutions with extensive resources, state-level infrastructure, and expertise years ahead of the public state of the art. This first revision prioritizes requirements with long lead times including facility construction, hardware procurement, and organizational development to preserve the option of achieving this level of protection when it becomes necessary.

What carries the argument

The SL5 security posture consisting of long-lead-time interventions for AI datacenters that must be planned years in advance.

If this is right

  • AI developers must begin planning and investing in specialized infrastructure now to keep SL5 achievable later.
  • Some requirements will demand significant changes from current datacenter practices and optimization for AI workloads.
  • Private efforts alone may leave gaps that ultimately require government involvement or capabilities.
  • The standard supports use-case-specific and periodically updated measures rather than fixed rules.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Adoption would shift industry timelines by forcing earlier capital commitments to security infrastructure.
  • It could create a de facto requirement for frontier labs to coordinate on shared secure facilities or hardware standards.
  • The approach highlights that rapid AI progress may conflict with the multi-year timelines needed for robust protection.
  • If widely referenced, SL5 could become a benchmark used by regulators or insurers to assess AI deployment risks.

Load-bearing premise

That the listed long-lead-time interventions in facility construction, hardware procurement, and organizational development will suffice to resist state-level threats.

What would settle it

A concrete demonstration or analysis showing that the proposed measures still allow a well-resourced state actor to exfiltrate AI model weights or that shorter-term alternatives achieve comparable protection.

read the original abstract

Security Level 5 (SL5) is a security posture for AI systems that could plausibly thwart top-priority operations by the world's most cyber-capable institutions: those with extensive resources, state-level infrastructure, and expertise years ahead of the public state of the art. The SL5 terminology originates from the RAND Corporation's 2024 report "Securing AI Model Weights". Frontier AI development requires use-case-specific, productivity-optimised and updateable AI datacenter security standards. This first revision of the SL5 standard focuses on requirements with long lead times: interventions that must be planned years in advance, such as facility construction, hardware procurement, and organizational capability development. We prioritize these requirements because preserving optionality for SL5 by 2028/2029 requires starting now. These capabilities cannot be retrofitted on short notice when the need becomes urgent. Some requirements represent significant departures from current day standard practice. We believe bold measures are necessary for this level of security and see clear opportunities to apply optimization pressure to existing and novel solutions to customize them for the AI industry and address the practical operational requirements as much as possible. Our organization exists to begin paving this path. Some requirements approximate government security capabilities where private-sector approaches may be insufficient. We identify these gaps and note where government involvement may ultimately be necessary.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript proposes Security Level 5 (SL5) as a security posture for AI systems that could plausibly resist top-priority operations by state-level adversaries with superior resources and expertise. It presents the first revision of an SL5 standard focused on long-lead-time interventions (facility construction, hardware procurement, organizational capability development) that must begin now to enable SL5 by 2028/2029, notes departures from current practice, and identifies areas where government involvement may be required.

Significance. If the proposed requirements were shown through analysis to achieve the claimed resistance, the work would provide a useful starting framework for industry-specific AI datacenter security standards, correctly emphasizing the need for proactive long-term planning and the limits of private-sector approaches. The identification of gaps requiring external involvement is a constructive contribution.

major comments (2)
  1. [Abstract] Abstract: The central assertion that the listed long-lead-time interventions 'could plausibly' produce a posture capable of thwarting state-level threats with 'expertise years ahead of the public state of the art' is unsupported; the manuscript supplies no adversary model, no mapping of attack surfaces (supply-chain, insider, physical, remote) to specific controls, and no feasibility or effectiveness argument.
  2. [Abstract] Abstract: SL5 is defined in terms of the very requirements proposed to achieve it, rendering the effectiveness claim circular by construction rather than derived from external benchmarks or validation.
minor comments (2)
  1. The manuscript would benefit from explicit definitions or examples of 'top-priority operations' and 'use-case-specific, productivity-optimised' standards to improve clarity for readers.
  2. Additional references to existing frameworks (e.g., NIST AI RMF, government secure facility standards) would help situate the proposed departures from current practice.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our SL5 standard proposal. The manuscript presents an initial framework of long-lead-time requirements for AI datacenter security rather than a complete threat-modeling or validation study. We have revised the abstract to clarify the scope, the basis for the 'plausibly' qualifier, and the distinction between defining a posture and proving its effectiveness. We address each major comment below.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central assertion that the listed long-lead-time interventions 'could plausibly' produce a posture capable of thwarting state-level threats with 'expertise years ahead of the public state of the art' is unsupported; the manuscript supplies no adversary model, no mapping of attack surfaces (supply-chain, insider, physical, remote) to specific controls, and no feasibility or effectiveness argument.

    Authors: We agree that a detailed adversary model and explicit attack-surface mapping would strengthen the presentation. This revision of the SL5 standard prioritizes identifying interventions with multi-year lead times (facility design, hardware supply chains, and organizational development) that must begin immediately to preserve future optionality. The 'plausibly' claim rests on the judgment that the proposed controls, taken together, address the primary vectors available to well-resourced state actors, drawing on public knowledge of existing high-assurance facilities and the RAND report that originated the SL5 terminology. We have added a short paragraph in the introduction that outlines the assumed adversary profile and high-level coverage of supply-chain, insider, physical, and remote vectors. A full per-control mapping and quantitative feasibility analysis remain outside the scope of this standards document but are planned for a companion technical report. revision: partial

  2. Referee: [Abstract] Abstract: SL5 is defined in terms of the very requirements proposed to achieve it, rendering the effectiveness claim circular by construction rather than derived from external benchmarks or validation.

    Authors: Security standards are frequently defined by the controls that constitute them (for example, NIST SP 800-53 or Common Criteria evaluation levels). SL5 is presented as a proposed posture whose requirements are chosen because they collectively target the capabilities of the most advanced state actors. The manuscript does not claim empirical validation or external benchmarks; it states that these requirements represent a plausible path that cannot be retrofitted on short notice. We have updated the abstract to make this definitional nature explicit and to separate the description of the posture from any assertion of proven effectiveness. Future work could include red-team exercises or government-led validation against the listed controls. revision: yes

Circularity Check

0 steps flagged

No circularity in derivation; SL5 is a proposed standard, not a derived result

full rationale

The paper defines SL5 as a security posture that could plausibly resist state-level threats and lists long-lead-time requirements (facility construction, hardware procurement, organizational development) as necessary to achieve it by 2028/2029. It cites the RAND report for the SL5 terminology and presents the requirements as forward-looking proposals based on the authors' belief that bold measures are needed. No equations, predictions, or first-principles derivations are present. The central claim is not shown to reduce to its inputs by construction, nor does it rely on self-citations for load-bearing uniqueness or ansatz smuggling. The document is a policy-oriented standard proposal rather than a chain of derived results, making it self-contained against external benchmarks for the purpose of this analysis.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The paper introduces SL5 as a new standard without independent evidence for its effectiveness and relies on domain assumptions about the necessity of bold security measures for frontier AI.

axioms (1)
  • domain assumption Frontier AI development requires use-case-specific, productivity-optimised and updateable AI datacenter security standards.
    Presented as a foundational premise in the abstract to justify the need for SL5.
invented entities (1)
  • SL5 security posture no independent evidence
    purpose: To define a high level of AI security against state-level threats
    Newly coined and specified in this paper as an extension of prior RAND terminology.

pith-pipeline@v0.9.0 · 5538 in / 1225 out tokens · 60297 ms · 2026-05-12T01:09:15.293605+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

10 extracted references · 10 canonical work pages

  1. [1]

    Online

    doi: 10.7249/RRA28491. Online. Available: https://www.rand.org/pubs/research_reports/RRA28491.html 2 Joint Task Force, “Security and Privacy Controls for Information Systems and Organizations,ˮ NIST Special Publication 80053, Rev. 5 Final; includes updates as of Dec. 10, 2020, National Institute of Standards and Technology NIST, Gaithersburg, M...

    work page doi:10.7249/rra2849 2020

  2. [3]

    Online

    doi: 10.6028/NIST.SP.800161r1-upd1. Online. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800161r1-upd1.pdf 4 Committee on National Security Systems, “Security Categorization and Control Selection for National Security Systems,ˮ CNSSI No. 1253, Mar. 27,

    work page doi:10.6028/nist.sp.800

  3. [4]

    Available: https://www.dcsa.mil/Portals/69/documents/io/rmf/CNSSI_No1253.pdf 5 FedRAMP Program Management Office, “FedRAMP Security Controls Baselineˮ (spreadsheet), FedRAMP

    Online. Available: https://www.dcsa.mil/Portals/69/documents/io/rmf/CNSSI_No1253.pdf 5 FedRAMP Program Management Office, “FedRAMP Security Controls Baselineˮ (spreadsheet), FedRAMP. Online. Available: https://www.fedramp.gov/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx 6 Office of the Director of National Intelligence, “Sensitive C...

    work page 2010

  4. [5]

    Online. Available: https://cdn.preterhuman.net/texts/government_information/intelligence_and_espionage/homebrew.military.and.espionage.electronics/servv89pn0aj.sn.sourcedns.com/_gbpprorg/mil/vaneck/nsa/nt19215.htm 10 National Security Agency, “Specification for RF Shielded Enclosures,ˮ NSA No. 94106, Fort Meade, MD, USA. Online. Available: https...

    work page arXiv

  5. [6]

    Online. Available: https://media.defense.gov/2021/Apr/02/2002613880/1/1/0/CSFC%20PMO%20CUSTOMER%20HANDBOOK_02062021.PDF/CSFC%20PMO%20CUSTOMER%20HANDBOOK_02062021.PDF 15 Confidential Computing Consortium, “Confidential Computing: Hardware-Based Trusted Execution for Applications and Data,ˮ CCC White Paper, v1.3, Nov

    work page 2021

  6. [7]

    Online. Available: https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC_outreach_whitepaper_updated_November_2022.pdf 16 NVIDIA Corp., “Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI,ˮ NVIDIA Technical Blog, Aug

    work page 2023

  7. [9]

    Available: https://arxiv.org/abs/2407.11888 18 B

    Online. Available: https://arxiv.org/abs/2407.11888 18 B. Biggio and F. Roli, “Wild Patterns: Ten years after the rise of adversarial machine learning,ˮ Pattern Recognit. , vol. 84, pp. 317331, Dec

    work page arXiv

  8. [10]

    Available: https://arxiv.org/pdf/1712.03141.pdf 19 N

    Online. Available: https://arxiv.org/pdf/1712.03141.pdf 19 N. Papernot, P. McDaniel, A. Sinha, and M. P. Wellman, “SoK Security and Privacy in Machine Learning,ˮ in Proc. IEEE European Symposium on Security and Privacy EuroS&P ,

    work page arXiv

  9. [11]

    Available: https://sl5.org/projects/sl5-novel-recommendations 21 U.S

    Online. Available: https://sl5.org/projects/sl5-novel-recommendations 21 U.S. Department of Defense, Defense Federal Acquisition Regulation Supplement DFARS, “252.2397000 — Protection Against Compromising Emanations OCT 2019ˮ (printable PDF, Acquisition.gov. Online. Available: https://www.acquisition.gov/node/36728/printable/pdf 22 Office of...

    work page 2019

  10. [12]

    The Sensitivity Levels Framework SenLs,

    Online. Available: https://csrc.nist.gov/News/2025/nist-releases-revision-to-sp-80053-controls 26 The SL5 Task Force, "The Sensitivity Levels Framework SenLs," Nov

    work page 2025