Field-Advance Paper Map | Technical AI Governance Explorer

TAIG Field-Advance Paper Map

Purpose: link each TAIG problem to specific papers/reports that show where the field advanced. This is not a replacement for official legal/product sources; regulatory, standards, and deployment claims still need the non-paper sources listed in the draft.

Method: 38 topic-specific paper-finding agents produced candidates; independent group reviewers kept only papers they judged real, clickable, and directly tied to the claimed advance. The original “Open Problems in Technical AI Governance” paper is treated as baseline problem framing, not an advance paper.

Summary: 144 deduplicated advance-paper links across 38 topics; 81 dropped/needs-verification candidates; 74 non-paper evidence gaps/notes.

3.1.1 Identification of Problematic Data

Croissant: A Metadata Format for ML-Ready Datasets — confidence: high

Supports: Machine-readable ML dataset metadata standardization has progressed through Croissant, which improves discoverability, portability, interoperability, and reproducibility across tools and repositories.
Why link it: Verified arXiv record 2403.19546 is live, lists NeurIPS 2024 Datasets and Benchmark Track publication, and its abstract directly states Croissant is a shared dataset metadata format supported by popular repositories spanning hundreds of thousands of datasets.
Do not overclaim: The paper supports the standard and adoption claim, but exact field-level schema details and responsible-AI vocabulary should be cited to MLCommons specifications, not inferred solely from the paper.

The Common Pile v0.1: An 8TB Dataset of Public Domain and Openly Licensed Text — confidence: high

Supports: Open-license/public-domain corpus construction has progressed through an 8TB corpus validated by 7B-parameter models trained on 1T and 2T tokens.
Why link it: Verified arXiv record 2506.05209 is live and its abstract states the 8TB openly licensed corpus, 30 sources, two 7B Comma models trained on 1T/2T tokens, competitive performance, and released corpus/code/mixtures/checkpoints.
Do not overclaim: Does not solve general problematic-data identification, prove licensing judgments in all jurisdictions, or show that open-license-only training scales to frontier systems.

The Data Provenance Initiative: A Large Scale Audit of Dataset Licensing & Attribution in AI — confidence: high

Supports: Open text-dataset provenance/licensing auditing has progressed: DPI audited 1,800+ text datasets, traced lineage, creator/source/license/use metadata, and found high license omission/error rates.
Why link it: Verified arXiv record 2310.16787 is live and its abstract directly states the 1,800+ dataset audit, lineage tracing, license omission above 70%, license error rates above 50%, and Data Provenance Explorer release.
Do not overclaim: Supports open/public text and fine-tuning dataset provenance auditing, not complete provenance for closed frontier corpora, automatic legal judgments, or no-access identification of problematic data.

3.1.2 Infrastructure and Metadata to Analyze Large Datasets

Bridging the Data Provenance Gap Across Text, Speech and Video — confidence: high

Supports: DPI extended provenance auditing beyond text by auditing nearly 4,000 public text, speech, and video datasets across languages, sources, organizations, and countries.
Why link it: Verified arXiv record 2412.17847 is live, marked ICLR 2025, and its abstract states the longitudinal audit across popular text, speech, and video datasets from 1990-2024 with 608 languages, 798 sources, 659 organizations, and 67 countries.
Do not overclaim: Audits popular public datasets, not arbitrary closed/private/proprietary/continuously updated training corpora; does not establish universal dashboard coverage.

Croissant: A Metadata Format for ML-Ready Datasets — confidence: high

Supports: Croissant standardizes machine-readable metadata for ML-ready datasets, improving discoverability, portability, interoperability, and reproducible loading across repositories and frameworks.
Why link it: Verified arXiv record 2403.19546 is live and directly describes Croissant as a metadata format shared across ML tools, frameworks, and platforms, with support from popular dataset repositories.
Do not overclaim: Does not prove metadata completeness or accuracy for legacy, closed, or proprietary corpora; normative schema fields require the Croissant specification.

DataComp-LM: In search of the next generation of training sets for language models — confidence: high

Supports: DataComp-LM provides a standardized 240T-token Common Crawl corpus, OpenLM pretraining recipes, 53 evaluations, and a benchmark for data-curation strategies at 412M-7B model scales.
Why link it: Verified arXiv record 2406.11794 is live and its abstract directly states the standardized corpus, recipes, 53 evaluations, and curation experiments over deduplication, filtering, and data mixing at 412M to 7B parameters.
Do not overclaim: A controlled benchmark/testbed, not universal governance audit infrastructure or a macro-scale suitability metric for arbitrary proprietary or continually changing datasets.

The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale — confidence: high

Supports: FineWeb demonstrates a large open web-text curation pipeline with documented filtering/deduplication choices, ablations, released datasets, curation code, and ablation models.
Why link it: Verified arXiv record 2406.17557 is live and its abstract states FineWeb is a 15T-token dataset from 96 Common Crawl snapshots, documents and ablates curation choices including filtering/deduplication, introduces FineWeb-Edu, and releases data/code/models.
Do not overclaim: Does not support later live dataset-card facts such as >18.5T tokens or 2025 crawl configurations, nor universal audit infrastructure for closed or arbitrary corpora.

The ROOTS Search Tool: Data Transparency for LLMs — confidence: high

Supports: Corpus-level transparency/search infrastructure has a concrete precedent in exact and fuzzy search over the entire 1.6TB ROOTS training corpus.
Why link it: Verified ACL Anthology page is live with DOI 10.18653/v1/2023.acl-demo.29; the abstract states ROOTS is a 1.6TB corpus and the paper presents an open-sourced search engine over the entire corpus with fuzzy and exact search.
Do not overclaim: Limited to ROOTS/BLOOM and predates the 2026 update; it is a precedent, not general infrastructure for arbitrary corpora.

3.1.3 Attribution of Model Behavior to Data

AI models collapse when trained on recursively generated data — confidence: high

Supports: Recursive training on model-generated content can cause model collapse and loss of distribution tails, making provenance of original/human data important.
Why link it: Verified Nature article page is live with DOI 10.1038/s41586-024-07566-y, publication date July 2024, and abstract/main text directly state that indiscriminate recursive use of generated content causes model collapse and disappearance of distribution tails.
Do not overclaim: Supports synthetic-data risk/provenance motivation, not a training-data attribution method; LLM demonstrations are proof-of-concept rather than frontier deployment evidence.

LoRIF: Low-Rank Influence Functions for Scalable Training Data Attribution — confidence: high

Supports: LoRIF reports scalable low-rank influence functions for training-data attribution on 0.1B-70B parameter models with up to 20x storage/query-time improvements over LoGRA.
Why link it: Verified arXiv record 2601.21929 is live and its abstract directly states the 0.1B-70B experiments, low-rank gradient/Hessian approximations, and up to 20x storage reduction/query-time speedup while matching or exceeding attribution quality.
Do not overclaim: A 2026 arXiv method paper; still depends on model/data access and selected experimental validation, so frontier-scale governance deployment should not be inferred.

STRIDE: Training Data Attribution via Sparse Recovery from Subset Perturbations — confidence: high

Supports: STRIDE reports a sparse-recovery/activation-space approach for LLM pretraining attribution, with 13x speedup and validation on data selection, contamination, and qualitative analysis.
Why link it: Verified arXiv record 2606.05165 is live and its abstract directly states the causal-intervention motivation, sparse recovery formulation, state-of-the-art LLM pretraining attribution claim, 13x speedup, and downstream validations.
Do not overclaim: Approximates causal intervention rather than providing full retraining-based proof at frontier scale and does not solve closed-weight/closed-data access barriers.

Studying Large Language Model Generalization with Influence Functions — confidence: high

Supports: EK-FAC influence functions scaled influence analysis to LLMs up to 52B parameters and were used to identify training examples contributing to selected behaviors and generalization patterns.
Why link it: Verified arXiv record 2308.03296 is live and its abstract states EK-FAC scales influence functions to LLMs up to 52B parameters and uses TF-IDF filtering/query batching to study math, programming, cross-lingual, and role-playing behavior.
Do not overclaim: An approximate research method; not legally or audit-grade causal attribution through full proprietary pretraining/post-training pipelines.

TRAK: Attributing Model Behavior at Scale — confidence: high

Supports: TRAK improves tractable training-data attribution by tracing predictions back to training data across ImageNet classifiers, CLIP, BERT, and mT5 using only a handful of trained models.
Why link it: Verified arXiv record 2303.14186 is live and its abstract directly defines data attribution, introduces TRAK, claims tractability/efficacy, and reports demonstrations across the named vision and language models with released code.
Do not overclaim: Does not solve attribution for closed frontier models without weight/data/training-artifact access and is not a governance-grade causal proof.

3.2.1 Definition of Chip and Cluster Specifications for Model Training

DiLoCo: Distributed Low-Communication Training of Language Models — confidence: high

Supports: Low-communication decentralized language-model training is feasible in research settings: DiLoCo matched fully synchronous optimization on C4 with 8 workers while communicating 500x less.
Why link it: Verified arXiv record 2311.08105 is live and its abstract directly states training on poorly connected islands of devices, the 8-worker C4 result, fully synchronous parity, and 500x less communication.
Do not overclaim: Does not prove parity with centralized frontier training clusters or that chip/export controls are obsolete.

OpenDiLoCo: An Open-Source Framework for Globally Distributed Low-Communication Training — confidence: high

Supports: OpenDiLoCo shows follow-on globally distributed low-communication training, including an open implementation across two continents and three countries with 90-95% compute utilization and billion-parameter scaling.
Why link it: Verified arXiv record 2407.07852 is live and its abstract directly states an open-source DiLoCo replication using Hivemind, training across two continents/three countries, 90-95% utilization, scalability ablations, and billion-parameter models.
Do not overclaim: Research-scale/billion-parameter evidence, not frontier-scale equivalence or regulatory evidence about chip/cluster definitions.

3.2.2 Classification of Workloads

Detecting Hidden ML Training With Zero-Overhead Telemetry — confidence: high

Supports: Privacy-preserving, content-agnostic NVIDIA NVML telemetry can detect many hidden ML training workloads in a binary research classification setting, including adversarial monitor/evader evaluation.
Why link it: Verified arXiv record 2606.19262 is live and its abstract directly states zero-overhead privacy-preserving NVML telemetry, 98.2% binary training-workload accuracy, 20 evasion-strategy families, 5 monitor-evader rounds, and 9 GPU models across 4 generations.
Do not overclaim: NVIDIA/NVML-specific binary training detection; does not establish cross-vendor, production, multi-class, pretraining-vs-fine-tuning, or large multi-node governance deployment.

OpenDiLoCo: An Open-Source Framework for Globally Distributed Low-Communication Training — confidence: medium

Supports: Geographically distributed low-communication LLM training is technically feasible, supporting concerns that training can be split across locations/providers in ways relevant to workload reporting regimes.
Why link it: Verified arXiv record 2407.07852 is live and directly reports globally distributed low-communication training across two continents and three countries with high utilization.
Do not overclaim: Indirect for workload classification: it does not test telemetry classifiers, reporting rules, or evasion of monitoring systems.

3.3.1 Reliable Evaluations

Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study — confidence: high

Supports: SWE-bench/SWE-bench Verified validity remains imperfect because plausible test-passing patches can still fail broader tests or diverge behaviorally from ground-truth patches.
Why link it: Verified arXiv record 2503.15223 is live and its abstract directly reports 7.8% of plausible patches failing developer-written tests, 29.6% inducing behavioral differences, and 6.2 percentage-point resolution-rate inflation.
Do not overclaim: An audit of benchmark validity and differential patch testing, not a general solution to reliable evaluation.

FrontierMath: A Benchmark for Evaluating Advanced Mathematical Reasoning in AI — confidence: high

Supports: FrontierMath advances expert-crafted, contamination-minimizing mathematical reasoning evaluation through original unpublished problems, expert vetting, and automated verification.
Why link it: Verified arXiv record 2411.04872 is live and its abstract directly states hundreds of original expert-crafted/vetted math problems, new unpublished items, automated verification, and under-2% solve rates at publication.
Do not overclaim: A math benchmark, not a general reliable-evaluation solution; it minimizes contamination risk rather than eliminating it.

LiveBench: A Challenging, Contamination-Limited LLM Benchmark — confidence: high

Supports: LiveBench advances contamination-limited evaluation using frequently updated recent-source questions, objective ground-truth scoring, monthly updates, and broad task coverage.
Why link it: Verified arXiv record 2406.19314 is live and its abstract directly states the recent-source, objective-scoring, monthly-updated benchmark design and task coverage across math, coding, reasoning, language, instruction following, and data analysis.
Do not overclaim: Mitigates contamination but does not eliminate it or prove full evaluation validity/coverage.

SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — confidence: high

Supports: SWE-bench operationalized real-world software-engineering evaluation through GitHub issue/PR tasks where models edit codebases and are assessed in execution environments.
Why link it: Verified arXiv record 2310.06770 is live and its abstract directly states 2,294 real GitHub issue/PR tasks across 12 repositories, codebase editing, and practical autonomous software-engineering evaluation beyond code generation.
Do not overclaim: Does not support SWE-bench Verified release details, OpenAI audit statistics, or Docker harness claims, which require project/blog documentation.

Inspect AI: Framework for Large Language Model Evaluations — confidence: medium

Supports: Inspect AI provides paper-like/software-record support for reusable evaluation infrastructure across coding, reasoning, knowledge, agentic, behavior, and multimodal tasks with prebuilt benchmarks and visualization tooling.
Why link it: Verified Zenodo record 18434279 is live, has DOI 10.5281/zenodo.18434279, includes an inspect_white_paper PDF, and describes Inspect as an open-source extensible evaluation framework with over 100 prebuilt benchmarks.
Do not overclaim: A software/white-paper record, not peer-reviewed empirical validation; current feature counts such as >200 prebuilt evals require official docs.

3.3.2 Efficient Evaluations

A StrongREJECT for Empty Jailbreaks — confidence: high

Supports: StrongREJECT improves jailbreak/harmful-request evaluation and shows prior automated evaluation methods can substantially overstate jailbreak effectiveness versus human judgments.
Why link it: Verified arXiv record 2402.10260 is live and its abstract directly states StrongREJECT's benchmark/evaluator, state-of-the-art agreement with human judgments, and overstatement by existing methods.
Do not overclaim: Specific to jailbreak/harmful-request evaluation; also cautions that automated graders can distort risk estimates.

HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal — confidence: high

Supports: HarmBench standardizes automated red-team evaluation by comparing many attack methods, target models, and defenses, and supporting attack/defense co-development within its scope.
Why link it: Verified arXiv record 2402.04249 is live and its abstract directly states HarmBench compares 18 red-teaming methods and 33 target LLMs/defenses and introduces a standardized evaluation framework.
Do not overclaim: Does not prove comprehensive red-team coverage, production monitoring, or validity outside its behavior/model/defense/scoring scope.

JailbreakBench: An Open Robustness Benchmark for Jailbreaking Large Language Models — confidence: high

Supports: JailbreakBench standardizes reproducible jailbreak evaluation with open adversarial prompts, behavior dataset, threat model, system prompts, chat templates, scoring functions, and leaderboard.
Why link it: Verified arXiv record 2404.01318 is live and its abstract directly lists the 100-behavior dataset, evolving jailbreak artifacts, standardized evaluation framework, threat model, system prompts, chat templates, scoring functions, and leaderboard.
Do not overclaim: A scoped jailbreak benchmark, not proof that jailbreak evaluation is solved or deployed in production.

PyRIT: A Framework for Security Risk Identification and Red Teaming in Generative AI System — confidence: high

Supports: PyRIT advances open-source, model- and platform-agnostic red-team tooling for probing generative AI systems for harms, risks, and jailbreaks across multimodal models.
Why link it: Verified arXiv record 2410.02828 is live and its abstract directly describes PyRIT as an open-source, model/platform-agnostic risk-identification and red-teaming framework with reusable composable building blocks.
Do not overclaim: Does not prove PyRIT finds all risks or that any current repository state/deployment claim is true; current software status needs repository documentation.

Red-Teaming for Generative AI: Silver Bullet or Security Theater? — confidence: high

Supports: AI red-teaming remains under-specified: practices vary across purpose, artifact, setting, resources, methods, reporting/disclosure, and mitigation decisions, limiting claims of comprehensive coverage.
Why link it: Verified arXiv record 2401.15897 is live, marked AIES 2024, and its abstract directly states that AI red-teaming remains ill-defined and divergent across the named dimensions, with overclaiming risking security theater.
Do not overclaim: Survey/analysis rather than a benchmark or deployed monitoring system; it bounds interpretation of red-teaming advances rather than replacing them.

3.3.3 (Multi-)Agent Evaluations

AgentHarm: A Benchmark for Measuring Harmfulness of LLM Agents — confidence: high

Supports: AgentHarm advances harmful tool-agent misuse evaluation through malicious multi-step agent tasks across harm categories, measuring refusal, jailbreak robustness, and post-jailbreak task capability.
Why link it: Verified arXiv record 2410.09024 is live and its abstract directly states 110 malicious agent tasks, 440 with augmentations, 11 harm categories, external tools, multi-stage tasks, and public release.
Do not overclaim: Misuse benchmark for agents, not benign multi-agent coordination or responsibility attribution.

MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits — confidence: high

Supports: MCP tool-agent ecosystem safety evaluation advanced through an audit demonstrating malicious code execution, remote access, and credential-theft risks and introducing an agentic MCP safety scanner.
Why link it: Verified arXiv record 2504.03767 is live and its abstract directly states MCP tool-security risks, demonstrated attacks, and MCPSafetyScanner as an agentic tool for arbitrary MCP server safety assessment.
Do not overclaim: MCP-specific security audit, not a general multi-agent benchmark or causal responsibility-attribution method.

OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments — confidence: high

Supports: OSWorld advances real-computer-use agent evaluation with real desktop/web apps, per-task setup configurations, and execution-based evaluation scripts for open-ended computer-use agents.
Why link it: Verified arXiv record 2404.07972 is live and its abstract directly states OSWorld's real computer environments, 369 real web/desktop app tasks, setup configs, execution-based evaluation scripts, and public release.
Do not overclaim: Primarily single-agent computer-use evaluation, not distributed multi-agent dynamics or responsibility attribution.

RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts — confidence: high

Supports: RE-Bench advances realistic ML R&D agent evaluation by comparing agents and human experts in open-ended research-engineering environments with task scoring and released trajectories/data/code.
Why link it: Verified arXiv record 2411.15114 is live and its abstract directly states 7 ML research-engineering environments, 71 eight-hour attempts by 61 human experts, human-vs-agent comparisons, and open-sourced environments/data/code/trajectories.
Do not overclaim: Only 7 environments and primarily single-agent/agent-scaffold R&D evaluation, not mature multi-agent organization evaluation.

τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — confidence: high

Supports: τ-bench advances tool-agent-user interaction evaluation through dynamic simulated-user conversations, domain APIs, policy rules, database-state goal scoring, and pass^k reliability.
Why link it: Verified arXiv record 2406.12045 is live and its abstract directly states simulated user interactions, API tools, policy guidelines, database goal-state scoring, pass^k, and <50% success for state-of-the-art function-calling agents.
Do not overclaim: A single-agent-with-tools/user benchmark; does not solve multi-agent evaluation or causal responsibility attribution.

3.4.1 Downstream Impact Evaluations

Holistic Evaluation of Language Models — confidence: high

Supports: HELM demonstrates standardized multi-metric proxy evaluation infrastructure, measuring accuracy, calibration, robustness, fairness, bias, toxicity, and efficiency under dense standardized conditions while noting missing coverage.
Why link it: Verified arXiv record 2211.09110 is live and its abstract directly states HELM's taxonomy, multi-metric evaluation, dense evaluation of 30 models, public raw prompts/completions, and living-benchmark intent.
Do not overclaim: Supports proxy benchmark infrastructure, not validated prediction of downstream societal impact or the live 2026 HELM Safety dashboard.

Sociotechnical Safety Evaluation of Generative AI Systems — confidence: high

Supports: Sociotechnical safety evaluation extends beyond model-only capability tests by adding human-interaction and systemic-impact layers because deployment context determines whether capabilities cause harm.
Why link it: Verified arXiv record 2310.11986 is live and its abstract directly states a three-layered sociotechnical framework spanning capability evaluation, human interaction, and systemic impacts, plus a survey of evaluation gaps.
Do not overclaim: Framework and survey, not validated quantitative prediction of downstream societal impacts across contexts.

Toward an Evaluation Science for Generative AI Systems — confidence: high

Supports: The field is moving toward an evaluation science emphasizing real-world performance, iterative metric refinement, and evaluation institutions/norms because static benchmarks and ad hoc audits are insufficient.
Why link it: Verified arXiv record 2503.05336 is live and its abstract directly states the real-world performance imperative, insufficiency of static benchmarks/ad hoc audits, and the three lessons about metrics, iterative refinement, and institutions/norms.
Do not overclaim: Programmatic methodology paper, not evidence that a mature predictive science already exists.

Evaluation Framework for AI Systems in "the Wild" — confidence: medium

Supports: In-the-wild GenAI evaluation frameworks emphasize diverse evolving inputs, holistic/dynamic/ongoing assessment, outcome orientation, human plus automated assessment, transparency, fairness, and ethics for real-world systems.
Why link it: Verified arXiv record 2504.16778 is live and its abstract directly targets the lab-to-real-world gap and proposes dynamic, ongoing, holistic, outcome-oriented real-world evaluation with policy relevance for societal impacts.
Do not overclaim: White paper/framework, not a validated predictive model of societal impacts across all contexts, languages, modalities, or deployment dynamics.

4.1.1 Privacy-Preserving Third-Party Access to Datasets

Opaque: An Oblivious and Encrypted Distributed Analytics Platform — confidence: high

Supports: Encrypted enclave-backed analytics can support query processing over sensitive data with encryption, authentication, computation verification, and access-pattern protections.
Why link it: The USENIX NSDI page is real and states that Opaque is a distributed analytics platform for sensitive cloud data using hardware enclaves, oblivious relational operators, encryption, authentication, and computation verification.
Do not overclaim: It is a systems research prototype for distributed analytics, not a governance solution for copyright, trade secrets, or production-scale frontier-model training-data audits.

OpenSAFELY: A platform for analysing electronic health records designed for reproducible research — confidence: high

Supports: Healthcare secure research environments can let approved researchers run code against sensitive health records while withholding patient-level data and limiting access to disclosure-controlled outputs.
Why link it: The DOI resolved to a Wiley journal article with matching title, authors, 2024 publication metadata, and an abstract describing OpenSAFELY as a secure, transparent, open-source platform for reproducible EHR research with audit trails, standardized workflows, and code sharing in secure analysis environments.
Do not overclaim: Use it only for the health/EHR secure-research-environment mechanism. It does not establish a general third-party right to inspect frontier-model training corpora or proprietary lab datasets.

Ryoan: A Distributed Sandbox for Untrusted Computation on Secret Data — confidence: high

Supports: TEE/sandbox systems can run untrusted computation over secret data with hardware isolation and confinement, supporting one technical building block for privacy-preserving third-party computation.
Why link it: The USENIX OSDI page is clickable, gives the exact title, authors, venue, PDF, and abstract-like summary, and states that Ryoan uses hardware enclaves such as SGX to protect secret data while untrusted services process it.
Do not overclaim: It is a 2016 systems prototype with a request-oriented model; it is not evidence of a modern AI-training-corpus audit standard or of side-channel-complete protection.

Syft 0.5: A Platform for Universally Deployable Structured Transparency — confidence: high

Supports: Structured-transparency/PET systems can support approved computations and selected outputs without giving external parties unconstrained access to protected data or systems.
Why link it: The arXiv abstract directly describes Syft 0.5 as a framework combining privacy-enhancing technologies for structured-transparency systems and demonstrates a privacy-preserving inference flow using homomorphically encrypted activation signals through a split neural network.
Do not overclaim: It supports the technical pattern, not current OpenMined product status, broad deployments, or legally compelled access to proprietary frontier-model data.

4.1.2 Preservation of Evaluation Data Integrity

A Meta-Analysis of Overfitting in Machine Learning — confidence: high

Supports: Kaggle-style public-leaderboard/private-final-test workflows have empirical evidence of limited overfitting in many historical competitions, adding nuance to adaptive-leakage concerns.
Why link it: The NeurIPS proceedings page is real and its abstract states that the authors analyzed over 100 Kaggle competitions with public holdout leaderboards and separate once-used final test sets, finding little evidence of substantial overfitting.
Do not overclaim: It is empirical evidence from Kaggle competitions, not a guarantee for adversarial frontier-model evaluations or unlimited API probing.

Hashmarks: Privacy-Preserving Benchmarks for High-Stakes AI Evaluation — confidence: high

Supports: Cryptographic answer-hiding can support open evaluation without publishing human-readable reference answers.
Why link it: The arXiv abstract directly proposes hashmarking, where benchmark reference solutions are cryptographically hashed before publication, and analyzes traditional and generative-model-specific attacks.
Do not overclaim: It hides answers, not prompts, and remains a proposed protocol rather than a universal deployed integrity standard.

LiveBench: A Challenging, Contamination-Limited LLM Benchmark — confidence: high

Supports: Frequently updated, objectively graded live benchmarks can reduce stale-public-test contamination risk while preserving automatic scoring.
Why link it: The arXiv abstract directly says LiveBench is designed to resist test-set contamination, uses frequently updated questions from recent sources, objective ground-truth scoring, monthly updates, and releases questions, code, and model answers.
Do not overclaim: It narrows the contamination window but does not prove non-contamination, especially after public release of questions and answers.

The Ladder: A Reliable Leaderboard for Machine Learning Competitions — confidence: high

Supports: Adaptive leaderboard reuse can cause holdout overfitting, motivating leaderboard designs, rate limits, precision limits, and score-disclosure rules.
Why link it: The PMLR page is real, clickable, and its abstract explicitly discusses sequential adaptive leaderboard evaluation, overfitting to holdout data, existing heuristics, and the Ladder algorithm with theoretical guarantees.
Do not overclaim: It is about ML competition leaderboards, not pretraining-corpus contamination or arbitrary frontier-LLM benchmark secrecy.

4.2.1 Addressing Compute Inequities

The Compute Divide in Machine Learning: A Threat to Academic Contribution and Scrutiny? — confidence: high

Supports: A compute divide is constraining academic and non-industry participation in compute-intensive ML research and scrutiny, especially for foundation models.
Why link it: The arXiv abstract directly states that industry and academia differ in compute use, that the divide coincides with reduced academic-only representation in compute-intensive topics, and recommends nationally sponsored compute infrastructure, structured access, open science, and auditing.
Do not overclaim: It diagnoses the divide and proposes policy directions; it does not evaluate whether NAIRR, EuroHPC, or any 2026 allocation program is sufficient or equitable.

The De-democratization of AI: Deep Learning and the Compute Divide in Artificial Intelligence Research — confidence: high

Supports: Unequal access to compute can de-democratize AI research by advantaging large firms and elite universities over non-elite institutions.
Why link it: The arXiv abstract describes an analysis of 171,394 papers across 57 computer-science conferences and explicitly links post-2012 divergence among firms, elite universities, and non-elite universities to the compute divide.
Do not overclaim: It is older and diagnostic; it does not evaluate current public compute programs or frontier-scale allocation mechanisms.

The Grand Illusion: The Myth of Software Portability and Implications for ML Progress — confidence: high

Supports: Software/hardware portability is a real barrier for shared public compute because ML frameworks can lose functionality or suffer severe slowdowns when moved across hardware stacks.
Why link it: The arXiv abstract directly reports a large-scale study of ML framework portability across hardware types, with more than 40% key-function loss and severe slowdowns when functions remain available.
Do not overclaim: It supports the interoperability concern, not proof that NAIRR or EuroHPC has solved portability.

Strengthening and Democratizing the U.S. Artificial Intelligence Innovation Ecosystem: An Implementation Plan for a National Artificial Intelligence Research Resource — confidence: medium

Supports: A national AI research resource was studied as a feasible federated cyberinfrastructure with compute, data, software, support, allocation, privacy/civil-rights safeguards, NAIRR-Open/NAIRR-Secure zones, and sustainability planning.
Why link it: The NSF-hosted PDF is real and contains the NAIRR Task Force final report to the President and Congress, including the federated resource model, allocation mechanism, NAIRR-Open/NAIRR-Secure zones, privacy/civil-rights controls, and implementation roadmap.
Do not overclaim: It is a government implementation-plan report, not a peer-reviewed paper and not evidence that later NAIRR operations achieved sufficient or equitable frontier-scale access.

4.3.1 Facilitation of Third-Party Access to Models

Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments — confidence: high

Supports: TEE-mediated confidential audits are a plausible technical prototype for verifying AI safety benchmarks while protecting both model-provider IP and auditor benchmark data.
Why link it: The arXiv abstract directly proposes audits inside TEEs, says the design protects sensitive data where model provider and auditor do not trust each other, and reports a prototype on typical audit benchmarks against Llama-3.1.
Do not overclaim: It is a prototype/workshop paper; it does not establish production deployment, complete side-channel resistance, or standardization across frontier labs.

Black-Box Access is Insufficient for Rigorous AI Audits — confidence: high

Supports: Black-box/API-only audits can be insufficient; rigorous audits may require white-box access to weights, activations, gradients, and outside-the-box information about training and deployment.
Why link it: The arXiv/FAccT record is real and its abstract directly defines black-box, white-box, and outside-the-box access, explains why deeper access enables stronger audits, and discusses safeguards for these audits.
Do not overclaim: It argues for deeper access and safeguards; it does not show broad deployment or legal mandates for white-box third-party access.

Structured Access for Third-Party Research on Frontier AI Models: Investigating Researchers’ Model Access Requirements — confidence: high

Supports: Structured research APIs can be designed around minimally sufficient access, including sampling, logits/probabilities, fine-tuning, model internals, model information, model families, and version stability.
Why link it: The PDF is real and its abstract/executive summary directly introduces a taxonomy of model access, analyzes safety-research needs, and recommends research API features such as logits, fine-tuning, model families, model information, and version stability.
Do not overclaim: It is a whitepaper based on literature analysis and interviews; it does not prove frontier labs implemented these features as standard practice.

Third-party compliance reviews for frontier AI safety frameworks — confidence: high

Supports: Third-party compliance reviews are a concrete governance design for trusted external scrutiny of frontier-lab safety frameworks using potentially confidential information while managing infosec and disclosure risks.
Why link it: The arXiv abstract directly states that independent external parties could assess frontier AI company compliance with safety frameworks and addresses reviewer choice, information sources, disclosure, timing, cost, reputational, and information-security challenges.
Do not overclaim: It is a proposed review model, not evidence that major labs provide comprehensive near-white-box technical access.

4.4.1 Access to Downstream User Logs and Data

Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference — confidence: high

Supports: Crowdsourced user prompts and pairwise preference data can form open evaluation infrastructure for LLM assessment.
Why link it: The arXiv abstract describes an operational open platform using pairwise comparisons from a diverse user base, with over 240K votes, and analyzes the collected data for LLM ranking credibility.
Do not overclaim: It supports public preference-evaluation infrastructure, not independent access to downstream production logs or full provider/deployer telemetry.

Enabling External Scrutiny of AI Systems with Privacy-Enhancing Technologies — confidence: high

Supports: OpenMined-style PET infrastructure can enable external scrutiny of AI systems while reducing exposure of sensitive data, proprietary systems, and user information.
Why link it: The arXiv abstract directly states that OpenMined infrastructure combines PETs into privacy-preserving audit setups and describes real-world governance case studies involving the Christchurch Call and UK AISI frontier-model evaluation.
Do not overclaim: It supports mediated privacy-preserving scrutiny infrastructure, not broad third-party access to raw frontier-AI user-interaction logs.

LMSYS-Chat-1M: A Large-Scale Real-World LLM Conversation Dataset — confidence: high

Supports: Public, crowdsourced real-world LLM interaction datasets can support safety and evaluation research, including moderation, safety benchmarking, instruction following, and hard benchmark creation.
Why link it: The arXiv abstract directly introduces one million real-world conversations with 25 LLMs from 210K unique IP addresses and lists safety/evaluation use cases plus public dataset availability.
Do not overclaim: It is not broad access to raw production logs from a major frontier-model provider; it is a curated release from LMSYS-operated public demos/Arena.

5.1.1 Verification of Training Data

Auditing unauthorized training data from AI generated content using information isotopes — confidence: high

Supports: InfoTracer/information isotopes provide a black-box/output-only research method for tracing selected textual training data, with experiments over 13 AI models and six datasets and reported up-to-99% accuracy using about 4,000 words of evidence.
Why link it: The Nature Communications page is real, open, and directly states the information-isotope framework, black-box setting, 13 models, six datasets, p<0.01, about 4,000 words of evidence, and an open-source tool release.
Do not overclaim: This supports selective textual data tracing, not universal all-and-only declared-corpus verification, legal license semantics, online/RL streams, or robust production compliance auditing.

Membership Inference Test: Auditing Training Data in Object Classification Models — confidence: high

Supports: MINT demonstrates membership-inference tests for object-recognition/classification models, using three public image databases totaling over 174K images and reporting 70-80% precision depending on detection-layer input.
Why link it: The arXiv record is real and its abstract directly names MINT, object recognition, object detection model plus embedding extractor plus MINT module, three public databases, over 174K images, and 70-80% precision.
Do not overclaim: Domain-specific membership inference for object classification; not proof of exact declared corpus use, non-image modalities, closed compliance settings, or small poisoned/backdoor additions.

5.2.1 Verification of Chip Location

Location Verification for AI Chips — confidence: high

Supports: Delay/RTT-based chip-location verification with trusted landmarks and chip identity/attestation is a concrete technical-report agenda for anti-smuggling/export-control checks, but not regulator-scale deployment.
Why link it: The PDF is real and directly studies AI-chip location verification, comparing asset-reported, topology-based, and delay-based methods, and states delay-based schemes appear most promising for AI-chip governance and export-control enforcement.
Do not overclaim: It is an initial report/proposal. It does not prove regulator-scale deployment, an accepted landmark-network standard, successful adversarial red-teaming, or the later H100 demo/product claims.

Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing — confidence: high

Supports: Remote attestation, TEEs, security modules, and on-chip governance primitives are plausible enabling primitives for chip governance and need hardening for adversarial settings.
Why link it: The CNAS PDF is real and explicitly discusses on-chip governance mechanisms, TEEs, remote attestation, operating licenses, existing chip-security features, and the need to harden them for adversarial settings such as export-control enforcement.
Do not overclaim: This is a policy/technical report about enabling primitives, not proof of geographic location verification or a deployed regulator system.

5.2.2 Verification of Compute Workloads

Creating the First Confidential GPUs — confidence: high

Supports: NVIDIA's confidential-GPU architecture is a real paper-like source for confidentiality and integrity primitives in accelerated computing.
Why link it: The DOI resolves through Crossref as an ACM Queue journal article by NVIDIA authors, published 2023-08-31, and directly concerns creating confidential GPUs.
Do not overclaim: It predates later Confidential Containers/Kubernetes/KBS architecture and does not prove workload accounting or geographic/workload compliance verification.

Machine Learning with Confidential Computing: A Systematization of Knowledge — confidence: high

Supports: Confidential computing/TEE-assisted ML can provide confidentiality and integrity assurances for ML workloads, while full-pipeline guarantees and ML-specific TEE limits remain open.
Why link it: The arXiv record is real and its abstract directly systematizes confidential-computing-assisted ML, including confidentiality guarantees, integrity assurances, limitations of existing TEE systems for ML, and future work on full-pipeline guarantees.
Do not overclaim: Does not establish NVIDIA's 2026 Confidential Containers architecture, regulatory FLOP accounting, or exact distributed training workload verification.

Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing — confidence: high

Supports: On-chip governance mechanisms including remote attestation and TEEs could enable privacy-preserving verification claims about computation or training runs, but need hardening before adversarial enforcement.
Why link it: The report is real and explicitly describes verification of computation or datasets/training runs using TEEs and remote attestation while warning current technologies need hardening for adversarial contexts.
Do not overclaim: Not evidence of aggregate FLOP accounting, exact distributed training execution verification, or production regulatory workload verification.

What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring — confidence: high

Supports: Compute monitoring for large-scale neural-network training is a proposed governance framework using on-chip firmware snapshots, training-run records, and supply-chain monitoring to help verify rules on large training runs.
Why link it: The arXiv record is real and its abstract directly states the government-compliance motivation, on-chip firmware snapshots, information sufficient to prove details of the training run, privacy/confidentiality goals, and supply-chain monitoring.
Do not overclaim: Proposal/framework only; not a deployed low-overhead frontier-cluster verifier, and not a broad non-AI workload-exemption mechanism.

5.3.1 Verification of Model Properties

Beta-CROWN: Efficient Bound Propagation with Per-neuron Split Constraints for Complete and Incomplete Neural Network Robustness Verification — confidence: high

Supports: Beta-CROWN/alpha-beta-CROWN provides GPU-parallel bound-propagation and branch-and-bound methods for complete/incomplete neural-network robustness verification, including VNN-COMP 2021 winning tool support.
Why link it: The arXiv record is real, NeurIPS-accepted, and the abstract directly states beta-CROWN's per-neuron split constraints, GPU parallelizability, speedups, and alpha-beta-CROWN VNN-COMP 2021 link.
Do not overclaim: Background method for bounded neural-network verification; not a July 2026 frontier LLM semantic verifier.

Scalable Neural Network Verification with Branch-and-bound Inferred Cutting Planes — confidence: high

Supports: BICCOS introduces neural-network-specific branch-and-bound inferred cutting planes that improve verifiable instance counts and scale beyond generic MIP-generated cuts in alpha,beta-CROWN.
Why link it: The arXiv record is real, marked accepted by NeurIPS 2024, and its abstract directly states BICCOS, constraint strengthening, multi-tree search, benchmark improvements, scalability to large networks, and alpha-beta-CROWN/VNN-COMP 2024 inclusion.
Do not overclaim: Bounded neural-network verifier improvement only; not formal verification of open-ended language behavior, training procedures, architecture lineage, or regulatory compliance.

Scaling Neural Network Verification with Tensor Parallelism and Fully Sharded Data Parallelism — confidence: high

Supports: Tensor parallelism and fully sharded data parallelism have been adapted to auto_LiRPA/alpha,beta-CROWN to reduce verifier GPU memory on bounded-verification benchmarks.
Why link it: The arXiv record is real and its abstract directly reports TP and FSDP adaptations, memory reductions, VNN-COMP benchmark checks, bitwise-identical FSDP bounds, and the CIFAR-100 ResNet-large result.
Do not overclaim: Recent arXiv preprint; results are bounded benchmark verification, not semantic verification of frontier LLMs or compliance claims.

5.3.2 Verification of Dynamic Systems

Trustless Audits without Revealing Data or Models — confidence: high

Supports: ZkAudit uses cryptographic commitments and zero-knowledge proofs to allow trustless audits of selected model/data properties without revealing model weights or data.
Why link it: The arXiv record is real and the abstract directly describes commitments to datasets/model weights, ZK proof of training-derived commitments, audit-request outputs with ZK proofs, and empirical DNN audits.
Do not overclaim: Narrower than hosted frontier AI services; does not verify prompt stacks, external tools, retrieval corpora, routing, safety filters, or continuous deployment changes.

Verifiable evaluations of machine learning models using zkSNARKs — confidence: high

Supports: zkSNARKs can support verifiable evaluation attestations for fixed private model weights over public inputs, enabling selected closed-model benchmark/fairness/safety claims to be checked without revealing weights.
Why link it: The arXiv record is real and its abstract directly states zkSNARK-based verifiable model evaluations, fixed private weights, public inputs, and attestations of performance or fairness metrics.
Do not overclaim: Fixed-model evaluation primitive only; not live hosted API verification or full dynamic system verification.

Instructional Fingerprinting of Large Language Models — confidence: medium

Supports: Instructional fingerprinting gives a narrow model-identity/ownership primitive for LLMs by implanting private-key-triggered behavior through lightweight instruction tuning.
Why link it: The arXiv record is real, notes NAACL 2024 acceptance, and its abstract directly reports confidential-key instruction backdoors, 11 LLMs, and robustness/ownership-authentication goals.
Do not overclaim: Fingerprints model behavior/weights for ownership/license contexts; it does not verify prompts, tools, retrieval data, routing, safety filters, or frequent hosted API updates.

Reward Reports for Reinforcement Learning — confidence: medium

Supports: Reward Reports propose living documentation for deployed and iteratively updated reinforcement-learning systems, tracking optimization objectives, assumptions, and update-relevant dynamic phenomena.
Why link it: The arXiv record is real and the abstract directly describes Reward Reports as living documents for deployed, iteratively updated learning systems and post-deployment dynamics.
Do not overclaim: Documentation/governance framework only; not cryptographic verification of served model identity or full AI pipeline state.

5.3.3 Proof-of-Learning

PoLO: Proof-of-Learning and Proof-of-Ownership at Once with Chained Watermarking — confidence: high

Supports: PoLO combines proof-of-learning and proof-of-ownership through chained watermarking, with author-reported 99% watermark detection accuracy, verification costs of 1.5-10% of traditional methods, forgery costs of 1.1-4x honest proof generation, and over-90% detection after attacks.
Why link it: The arXiv record is real and its abstract directly reports the numeric claims for PoLO's watermark detection, verification cost, forgery cost, and post-attack detection.
Do not overclaim: Recent arXiv prototype; attack model/evaluation-limited, and the low-end 1.1x forgery margin should not be overstated as robust governance security.

PoTS: Proof-of-Training-Steps for Backdoor Detection in Large Language Models — confidence: high

Supports: PoTS proposes proof-of-training-steps for LLM backdoor/deviation detection by checking declared data batches, architecture, and hyperparameters, with verification steps reported as 3x faster than training steps.
Why link it: The arXiv record is real and its abstract directly states the independent-auditor protocol, declared recipe elements, backdoor/deviation detection target, and 3x faster verification steps.
Do not overclaim: Recent arXiv preprint focused on backdoor/deviation detection; not universal proof of honest frontier LLM training under fully adversarial conditions.

Proof-of-Learning is Currently More Broken Than You Think — confidence: high

Supports: Classical/current proof-of-learning is fragile: spoofing strategies can generate apparently valid proofs across configurations for less than honest proof generation, so robust PoL remains unsolved.
Why link it: The arXiv record is real, published in IEEE EuroS&P 2023, and its abstract directly states current PoL verification is not robust to adversaries and introduces reproducible spoofing strategies across configurations.
Do not overclaim: Critiques classical/current PoL formulations; it does not evaluate later PoLO/PoTS systems or prove all future PoL-like mechanisms impossible.

Proof-of-Learning with Incentive Security — confidence: high

Supports: Proof-of-learning can be framed for blockchain proof-of-useful-work with incentive-security guarantees for rational provers and improved computational overhead.
Why link it: The arXiv record is real and the abstract directly describes PoL for proof-of-useful-work, incentive security, rational provers, security against two attacks, and overhead improvement from Theta(1) to O(log E / E).
Do not overclaim: Rational-prover incentive security is narrower than Byzantine/adversarial robustness; no production blockchain or model-governance deployment is shown.

5.4.1 Verifiable Audits

Confidential Inference: Systems Design principles and security risks — confidence: high

Supports: Confidential-inference designs can use TEEs, cryptographic attestation of expected workloads, and KMS/key-release policies to protect user data and/or model weights in AI inference.
Why link it: The PDF is real and directly describes confidential inference for generative AI, including TEEs, signed attestation documents, expected code/workloads, KMS policy-gated decryption, and CPU/GPU accelerator trust-boundary designs.
Do not overclaim: Design/security-risks report, not proof that major LLM services provide user-facing live attestation or audit binding for every generation.

GPT-4o System Card — confidence: high

Supports: GPT-4o's system card is a public frontier-model audit-like report covering capabilities, limitations, safety evaluations, Preparedness Framework evaluations, mitigations, and third-party dangerous-capability assessments.
Why link it: The arXiv record is real and its abstract directly describes the GPT-4o system card, safety evaluations, limitations, measures implemented, third-party dangerous-capability assessments, and societal-impact discussion.
Do not overclaim: Vendor transparency report, not independent cryptographic verification that particular deployed generations come from the evaluated pipeline state.

Model Cards for Model Reporting — confidence: high

Supports: Model cards provide a mature documentation basis for audit-like transparency artifacts, covering intended use, benchmarked performance, evaluation procedures, and limitations.
Why link it: The arXiv record is real and the abstract directly proposes model cards with intended-use disclosures, benchmarked evaluations across relevant conditions/groups, evaluation procedures, and other transparency information.
Do not overclaim: Documentation artifact only; not cryptographic attestation or binding of live outputs to deployed model states.

zkLLM: Zero Knowledge Proofs for Large Language Models — confidence: high

Supports: zkLLM demonstrates research-scale zero-knowledge proofs for LLM inference authenticity, including reported 13B-parameter full-inference proof generation in under 15 minutes and proof size under 200 kB.
Why link it: The arXiv record is real, notes ACM CCS 2024 acceptance, and its abstract directly states zkLLM, tlookup, zkAttn, 13B-parameter full-inference proof generation under 15 minutes, and proof size under 200 kB.
Do not overclaim: Research prototype; under-15-minute proving is not routine low-latency production inference, and it does not create an end-to-end public audit registry.

5.4.2 Verification of AI-generated Content

RAID: A Shared Benchmark for Robust Evaluation of Machine-Generated Text Detectors — confidence: high

Supports: RAID provides a large independent benchmark showing general machine-generated-text detectors are brittle under adversarial attacks, sampling-strategy variations, repetition penalties, and unseen generators.
Why link it: The arXiv record is real, notes ACL 2024, and its abstract directly states over 6 million generations, 11 models, 8 domains, 11 attacks, 4 decoding strategies, and poor robustness of evaluated detectors.
Do not overclaim: Text-detector benchmark only; does not evaluate image/audio/video verification or generator-side watermarking as a compliance mechanism.

Scalable watermarking for identifying large language model outputs — confidence: high

Supports: SynthID-Text shows production-scale text watermarking for participating generators, preserving text quality with low latency and probabilistic detection, including a live experiment over nearly 20 million Gemini responses.
Why link it: The Nature article is real, open, and directly states SynthID-Text, sampling-only watermarking, efficient detection without the underlying LLM, low latency, preserved quality, and the nearly-20-million-response Gemini live experiment.
Do not overclaim: Applies to participating/watermarked generation under suitable conditions; not a detector for arbitrary unwatermarked text, and not foolproof against heavy rewriting/translation or key compromise.

SynthID-Image: Image watermarking at internet scale — confidence: high

Supports: SynthID-Image documents large-scale invisible watermarking for AI-generated imagery, reporting use on over ten billion images and video frames across Google services and benchmarking an external variant for robustness and visual quality.
Why link it: The arXiv record is real and its abstract directly states SynthID-Image, internet-scale deployment desiderata/threat models, over ten billion watermarked images/video frames, trusted-tester verification service, and external-variant benchmarking.
Do not overclaim: Author-reported deployment for participating Google/partner workflows; not universal detection of arbitrary open-web images/videos or nonparticipating generators.

Verifying Provenance of Digital Media: Why the C2PA Specifications Fall Short — confidence: medium

Supports: Independent C2PA security analysis argues current C2PA specifications fail claimed and necessary provenance-security goals and should not yet be relied on for high-stakes uses.
Why link it: The arXiv record is real and its abstract directly states a comprehensive independent security/formal-methods analysis of C2PA, finding failures of claimed security goals and warning against premature high-stakes reliance.
Do not overclaim: Short 2026 whitepaper summary of a technical study, not the normative source for what C2PA specifies; use official C2PA specs for standards claims.

6.1.1 Detection and Prevention of Training Data Extraction

Deduplicating Training Data Mitigates Privacy Risks in Language Models — confidence: high

Supports: Training-data duplication is a major driver of language-model extraction risk; deduplication improves resistance to the studied privacy attacks but does not eliminate risk.
Why link it: The arXiv page is real and clickable; its abstract reports a superlinear relation between sequence duplication and regeneration, near-chance memorization detection on non-duplicated sequences for existing methods, and improved security after deduplication.
Do not overclaim: The result is specific to duplication-driven and studied privacy attacks; it does not prove deduplication removes extraction risk or handles all non-verbatim leakage.

Differentially Private Fine-tuning of Language Models — confidence: high

Supports: Differentially private fine-tuning of pretrained language models can achieve useful privacy/utility tradeoffs on narrower NLP tasks, but it is not a generic extraction-proofing solution for frontier-scale pretraining.
Why link it: The arXiv page is real and clickable; its abstract reports simpler, faster DP fine-tuning methods, improved utility/privacy/compute tradeoffs, and concrete NLP results such as RoBERTa-Large MNLI accuracy at a stated privacy budget.
Do not overclaim: It supports DP fine-tuning/adaptation, not practical differentially private frontier pretraining or broad protection against all extraction attacks.

Extracting Training Data from Diffusion Models — confidence: high

Supports: Training-data extraction is not limited to text models: diffusion models can memorize and emit individual training images, and generate-and-filter attacks extracted over a thousand examples.
Why link it: The arXiv page is real and clickable; its abstract states that diffusion models memorize individual images and emit them at generation time, and that the authors extracted over a thousand training examples from state-of-the-art models.
Do not overclaim: It concerns image diffusion models and does not provide a detector or generic prevention method for LLM extraction or non-verbatim semantic leakage.

Scalable Extraction of Training Data from (Production) Language Models — confidence: high

Supports: Scalable black-box extraction can recover large amounts of memorized training text from open, semi-open, and closed/production language models, and alignment does not eliminate memorization.
Why link it: The arXiv page is real and clickable; its abstract says the authors extract gigabytes of training data from Pythia/GPT-Neo, LLaMA/Falcon, and ChatGPT, and that their divergence attack makes ChatGPT emit training data 150x more often than normal behavior.
Do not overclaim: It supports scalable verbatim/extractable memorization attacks, not a universal claim that every deployed model is equally vulnerable or that semantic leakage detection is solved.

6.2.1 Use of Hardware Mechanisms for AI Security

AccShield: A New Trusted Execution Environment with Machine-Learning Accelerators — confidence: high

Supports: Research prototypes can extend TEEs to cloud ML accelerators with isolation, multi-tenancy, link encryption, partitioning, and memory-encryption design choices.
Why link it: The IBM Research page is real and clickable; it lists the DAC 2023 conference paper and DOI, and its abstract says AccShield extends TEEs to cloud accelerators, considers isolation and multi-tenancy, demonstrates feasibility on an FPGA board, and evaluates link encryption, partitioning, and memory encryption.
Do not overclaim: It is a research prototype, not deployed GPU confidential computing or governance-grade assurance in production AI clusters.

Confidential Computing within an AI Accelerator — confidence: high

Supports: AI accelerators can incorporate confidential-computing features such as a hardware root of trust, attestation, encrypted model/data handling, and low-overhead trusted execution for DNN workloads.
Why link it: The Microsoft Research/USENIX ATC page is real and clickable; it describes Graphcore IPU Trusted Extensions with workload isolation, encrypted data/models except inside the chip, hardware root of trust, attestation, on-chip authenticated encryption, and evaluation on standard DNN training workloads with under 5% overhead.
Do not overclaim: It is Graphcore IPU research, not NVIDIA H100 evidence, and it does not solve multi-accelerator governance or production datacenter assurance.

Hardware-Enabled Mechanisms for Verifying Responsible AI Development — confidence: high

Supports: Hardware-enabled mechanisms could verify AI training compute, cluster configuration, location, and policy enforcement while preserving privacy/IP, but robust scalable implementation remains a research problem.
Why link it: The arXiv page is real and clickable; its abstract explicitly says HEMs can enable verifiable reporting of compute used, training-cluster configuration or location, and policy enforcement, and identifies open implementation questions for robust scalable solutions.
Do not overclaim: It is a workshop/research-agenda paper, not validation of a specific deployed AI-security hardware stack or complete cluster-wide attestation system.

S2TAR-Cloud: Shared Secure Trusted Accelerators with Reconfiguration for Machine Learning in the Cloud — confidence: high

Supports: Fine-grained attestation and secure partitioning for reconfigurable ML accelerators are active research advances toward multi-tenant accelerator confidentiality and governance.
Why link it: The IBM Research page is real and clickable; it lists the IEEE CLOUD 2024 conference paper and DOI, and its abstract describes a secure reconfigurable TPU design with confidential-computing support, partition-level remote attestation, and separate host/accelerator TEE reports.
Do not overclaim: It is a TPU-style research design/evaluation, not evidence of robust cluster-wide attestation for deployed frontier AI datacenters.

6.2.2 Anti-Tamper Hardware

Hardware Trojan Attacks on the Reconfigurable Interconnections of Field-Programmable Gate Array-Based Convolutional Neural Network Accelerators and a Physically Unclonable Function-Based Countermeasure Detection Technique — confidence: high

Supports: PUF-based detection has been applied to FPGA-based CNN accelerator hardware-Trojan attacks, showing directly AI-accelerator-related hardware tampering research at small scale.
Why link it: The PMC page is real and clickable; the abstract reports FPGA-based CNN accelerator interconnection Trojan attacks, 8.93% to 86.20% accuracy degradation, and successful detection/location using an arbiter-PUF on a Xilinx Zynq XC7Z100 platform.
Do not overclaim: It addresses FPGA CNN accelerator interconnect Trojans, not physical package tampering or rack-scale frontier GPU/TPU anti-tamper systems.

Hardware-Enabled Mechanisms for Verifying Responsible AI Development — confidence: high

Supports: Physical tampering is a cross-cutting unresolved challenge for robust, scalable hardware-enabled AI governance mechanisms.
Why link it: The arXiv paper is real and clickable and directly supports the surrounding HEM governance claim; the TAIG paper also cites this line of work for physical-tamper implementation challenges. It is useful evidence that the anti-tamper issue is tied to responsible-AI compute verification, not only generic hardware security.
Do not overclaim: Its public abstract establishes the HEM/open-implementation framing more strongly than the detailed tamper discussion; do not cite it as a completed anti-tamper mechanism.

Secure Physical Enclosures from Covers with Tamper-Resistance — confidence: high

Supports: General secure-enclosure research demonstrates tamper-resistant cover/mesh-style structures, integrity checks, capacitance measurements, and PUF-derived secrets that can underpin tamper-evident or tamper-resistant modules.
Why link it: The DOI resolves to a real IACR Transactions on Cryptographic Hardware and Embedded Systems article; the bibliographic page confirms the title, authors, journal, pages, and DOI.
Do not overclaim: It is general hardware-security work, not AI-accelerator-specific, and does not address HBM/NVLink-class packaging, liquid cooling, or cloud AI deployment.

Technical Options for Flexible Hardware-Enabled Guarantees — confidence: high

Supports: A concrete AI-accelerator governance architecture has been proposed that pairs an auditable Guarantee Processor with a Secure Enclosure for physical tamper protection.
Why link it: The arXiv page is real and clickable; its abstract states that flexHEG is integrated with AI accelerator hardware and consists of a Guarantee Processor plus a Secure Enclosure providing physical tamper protection.
Do not overclaim: It is a proposal/technical-options report, not a validated GB200/H100/TPU package-level secure enclosure or deployed rack-scale anti-tamper system.

6.2.3 Enforcement of Compute Usage Restrictions

Blueprint, Bootstrap, and Bridge: A Security Look at NVIDIA GPU Confidential Computing — confidence: high

Supports: Independent research has reconstructed and analyzed NVIDIA GPU confidential-computing building blocks relevant to attestation and secure AI workloads, but not export-control enforcement.
Why link it: The arXiv page is real and clickable; its abstract says the paper reconstructs GPU-CC architecture, analyzes the bootstrap process, and experimentally checks protected data-transfer paths under the GPU-CC threat model, with responsible disclosure to NVIDIA PSIRT.
Do not overclaim: It studies GPU-CC security architecture and data protection, not cluster-size caps, export-control policy enforcement, or prevention of non-cooperative accelerator aggregation.

Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 — confidence: high

Supports: Hardware-enabled governance mechanisms have been proposed for export-control-related limits on 3A090/4A090-class advanced-computing items using roots of trust, remote attestation, threat modeling, and protection measures.
Why link it: The RAND page is real and clickable; it identifies the working paper, authors, document number, DOI, and abstract, which says it explores export-control policy objectives, threats, attack vectors, and protection measures for HEMs that could limit uses of U.S.-designed high-performance chips.
Do not overclaim: RAND labels it a working paper approved for circulation but not formally edited or peer reviewed; it is a proposal/analysis, not deployed enforcement.

Near-Term Enforcement of AI Chip Export Controls Using A Firmware-Based Design for Offline Licensing — confidence: high

Supports: Firmware-based offline licensing is a concrete near-term proposal for partially enforcing AI-chip export controls by disabling chips unless they hold a regulator-issued license, assuming secure boot, rollback protection, and secure non-volatile storage.
Why link it: The arXiv page is real and clickable; its abstract describes offline licensing, regulator-issued licenses, firmware delivery, required hardware security features, H100 public-documentation support for prerequisites, and vulnerability to physical hardware attacks without additional modifications.
Do not overclaim: It is a design proposal and explicitly only a partial solution; it does not prove reliable prevention of accelerator aggregation or adoption by regulators or manufacturers.

Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing — confidence: high

Supports: On-chip governance mechanisms could support export-control enforcement and compute governance through TEEs, remote attestation, operating licenses, and hardened security modules, but commercial features need hardening for adversarial settings.
Why link it: The CNAS page is real and clickable; it states that on-chip governance mechanisms could aid export-control enforcement, privacy-preserving verification, operating licenses, TEEs, remote attestation, and hardened security modules, while warning that existing technologies must be hardened for adversarial settings.
Do not overclaim: It is a policy/technical report, not a deployed implementation or independent validation of current chips enforcing compute restrictions.

6.3.1 Prevention of Model Theft

Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models — confidence: high

Supports: Frontier-model weight security has advanced into a concrete defense-in-depth framework with attack vectors, attacker-capability tiers, security levels, benchmark systems, and recommendations such as centralized weight storage, reduced access, hardened interfaces, insider-threat programs, red teaming, and confidential computing.
Why link it: The RAND page is real and clickable; it identifies the research report, authors, DOI, and recommendations. It says the authors identify 38 attack vectors, analyze attacker capacities, define five security levels, and recommend controls including centralized copies, reduced authorized access, hardened interfaces, insider-threat programs, defense-in-depth, red teaming, and confidential computing.
Do not overclaim: It is a framework/report, not an audit proving frontier labs have implemented the controls or that model theft is solved against insiders or top nation-state actors.

Stealing Part of a Production Language Model — confidence: high

Supports: Black-box production language-model APIs can leak precise internal model information, supporting continued API-level model-extraction risk and the need to harden model-access interfaces.
Why link it: The arXiv page is real and clickable; its abstract says the authors extract precise, nontrivial information from black-box production language models, recover projection matrices for OpenAI Ada/Babbage for under $20, recover gpt-3.5-turbo hidden dimension, and estimate full projection-matrix recovery under $2,000 in queries.
Do not overclaim: It does not demonstrate full theft of all frontier-model weights or a complete defense; it supports API-extraction risk and interface-hardening, not broad current vulnerability claims.

Confidential Inference Systems: Design Principles and Security Risks — confidence: medium

Supports: Confidential inference is a concrete design direction for protecting model weights during inference using TEEs, attestation, encrypted weights, restricted operator access, and accelerator-aware confidential boundaries.
Why link it: The PDF is real and clickable; it is a Pattern Labs/Anthropic whitepaper that defines confidential inference, model-weight confidentiality requirements, TEE/attestation properties, restricted operator access, and approaches for including AI accelerators in confidential boundaries. It also ties confidential computing to RAND SL4/SL5 model-weight security.
Do not overclaim: It is a design-principles whitepaper, not a peer-reviewed security proof or audited deployment, and its scope is mainly inference rather than the full model lifecycle.

6.3.2 Shared Model Governance

Exploring the Relevance of Data Privacy-Enhancing Technologies for AI Governance Use Cases — confidence: high

Supports: Privacy-enhancing technologies are relevant substrates for AI governance information flows, including external scrutiny, auditing, and source verification, but this is a governance-framing/interoperability claim rather than a deployed shared-control mechanism.
Why link it: The arXiv page is real and the abstract explicitly connects privacy-enhancing technologies to AI-governance uses such as structured transparency, external scrutiny, auditing, source verification, information flows, and interoperable software stacks.
Do not overclaim: It does not implement shared model governance, benchmark frontier-model HE/SMPC governance, or show all-party authorization of training or inference operations.

Scaling shared model governance via model splitting — confidence: high

Supports: Model splitting is the most direct paper-backed technical proposal for shared model governance: split a deep-learning model across parties and empirically study model-completion difficulty from partial parameters.
Why link it: The arXiv page is real and its title and abstract directly mention shared model governance. The abstract proposes splitting deep learning models between multiple parties and evaluates the model-completion problem on ImageNet, Atari, and DeepMind Lab.
Do not overclaim: The evidence is empirical and setting-dependent. It suggests feasibility in some expensive-training settings, but does not demonstrate cryptographic co-authorization, frontier-scale LLM training/inference governance, or production deployment.

6.3.3 Model Disgorgement and Machine Unlearning

AI model disgorgement: Methods and choices — confidence: high

Supports: Model disgorgement is a concrete technical/legal-governance concept: eliminating or reducing improperly used data and its effects on model components without retraining from scratch, including for protected/private content and responsible IP use.
Why link it: The DOI resolves to a real PNAS journal article. The abstract defines model disgorgement, motivates it with protected/private content and intellectual property, and surveys/taxonomizes disgorgement methods for modern ML systems.
Do not overclaim: It surveys methods and choices; it does not validate a general-purpose method, prove legal sufficiency, or show reliable removal of copyrighted/private data effects from frontier LLMs.

Eight Methods to Evaluate Robust Unlearning in LLMs — confidence: high

Supports: Robust unlearning evaluation advanced through stress tests showing that apparent unlearning can fail under extraction, Q&A, latent-knowledge, and collateral-effect evaluations.
Why link it: The arXiv page is real. The abstract says unlearning evaluation lacks standardized methods, surveys evaluation techniques, and applies comprehensive tests to the Who's Harry Potter model, finding extractable knowledge, Q&A performance on par with the original, comparable latent knowledge, and collateral unlearning.
Do not overclaim: The main empirical target is the Who's Harry Potter model. It is strong evidence for evaluation weaknesses, not proof that all unlearning methods fail or that a final standard exists.

MUSE: Machine Unlearning Six-Way Evaluation for Language Models — confidence: high

Supports: MUSE operationalized broader LLM unlearning evaluation with six practical properties and found common failures in privacy leakage, utility preservation, scalability, and sequential unlearning.
Why link it: The arXiv page is real. Its abstract enumerates six evaluation properties, benchmarks eight unlearning algorithms on 7B-parameter LMs for Harry Potter books and news articles, and reports privacy leakage, utility degradation, scalability, and sequential-request failures.
Do not overclaim: The benchmark covers specific 7B LM settings and selected content-removal scenarios, not all frontier models, languages, modalities, or legally sufficient deletion/disgorgement.

TOFU: A Task of Fictitious Unlearning for LLMs — confidence: high

Supports: TOFU made LLM unlearning evaluation more concrete with a public fictitious-author benchmark and metrics, and found that tested baselines did not make models behave as if never trained on the forget data.
Why link it: The arXiv record is real. Its abstract describes 200 synthetic author profiles, 20 question-answer pairs per profile, forget sets, holistic metrics, and the finding that none of the considered baselines showed effective unlearning in the intended sense.
Do not overclaim: TOFU uses synthetic/fictitious author data and tested baselines. It does not establish real-world legal, privacy, copyright, multilingual, multimodal, or regulator-grade disgorgement.

The WMDP Benchmark: Measuring and Reducing Malicious Use With Unlearning — confidence: high

Supports: WMDP/RMU established a public hazardous-knowledge proxy benchmark and representation-based unlearning method that reduces benchmark performance while preserving selected general capabilities.
Why link it: The arXiv page is real. Its abstract states that WMDP contains 3,668 multiple-choice questions for biosecurity, cybersecurity, and chemical-security hazardous-knowledge proxies, and that RMU controls model representations to reduce WMDP performance while maintaining selected general capabilities.
Do not overclaim: WMDP is a hazardous-knowledge proxy benchmark, not proof of general legal/privacy/copyright unlearning or bounded side effects across all model behavior.

6.4.1 Detection of Adversarial Attacks

Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems — confidence: high

Supports: Current prompt-injection and jailbreak guardrail detectors can be evaded, supporting the claim that detection is operationalized but not solved.
Why link it: The arXiv page is real and says the work is to be published in LLMSec 2025. The abstract reports character-injection and AML evasion attacks against six protection systems, including Azure Prompt Shield and Meta Prompt Guard, with in some instances up to 100% evasion success.
Do not overclaim: It covers tested systems and attack settings. It should not be generalized to every current or proprietary detector, nor used to claim guardrails are always bypassable.

Embedding-based classifiers can detect prompt injection attacks — confidence: high

Supports: Prompt-injection detection has research prototypes using embedding-based ML classifiers over malicious and benign prompts.
Why link it: The arXiv page is real. Its abstract proposes embedding-based ML classifiers using three embedding models and traditional classifiers such as Random Forest and XGBoost to predict whether an input prompt is malicious, with reported improvements over open-source classifier baselines.
Do not overclaim: It is a research prototype. It does not establish production deployment, adaptive-evasion robustness, coverage of all prompt-injection styles, or end-to-end prevention of harmful tool use.

Improved Large Language Model Jailbreak Detection via Pretrained Embeddings — confidence: high

Supports: Jailbreak detectors can be built as input guardrails using pretrained text embeddings paired with traditional ML classifiers.
Why link it: The arXiv page is real. Its abstract is directly about detecting jailbreak prompts and proposes pairing retrieval-suited pretrained embeddings with traditional ML classifiers, reporting better performance than publicly available open-source LLM security application methods.
Do not overclaim: It does not prove NVIDIA's NemoGuard deployment or performance, and it does not establish robustness against adaptive obfuscation or all adversarial AI techniques.

Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations — confidence: high

Supports: Prompt and completion safety classifiers can be implemented as input/output safeguards using an LLM-based taxonomy-driven classifier for both prompts and model responses.
Why link it: The arXiv page is real. Its abstract introduces Llama Guard as an LLM-based input-output safeguard with prompt classification, response classification, a safety taxonomy, multi-class outputs, binary decision scores, and customizable taxonomies/output formats.
Do not overclaim: It evaluates content-moderation-style safety classification, not universal detection of all adversarial attacks, all prompt-injection styles, or provider-specific ASL-3 deployment safeguards.

NeMo Guardrails: A Toolkit for Controllable and Safe LLM Applications with Programmable Rails — confidence: high

Supports: Programmable guardrail stacks can be added as a runtime control layer around LLM applications using user-defined, model-independent, interpretable rails.
Why link it: The arXiv record is real and says the paper was accepted at EMNLP 2023 Demo Track. The abstract describes NeMo Guardrails as an open-source toolkit for programmable rails around LLM conversational systems, independent of the underlying LLM and inspired by dialogue-management runtime control.
Do not overclaim: It supports the toolkit concept and initial results, not current NVIDIA product features, Jailbreak Detection NIM, third-party integrations, production microservice status, or robust adversarial-detection guarantees.

6.4.2 Modification-Resistant Models

Representation Noising: A Defence Mechanism Against Harmful Finetuning — confidence: high

Supports: Representation Noising can reduce recoverability of harmful representations so harmful capabilities or unsafe behaviors are harder to restore during fine-tuning, including when attackers have weight access, while retaining harmless-task training and general capabilities in evaluated settings.
Why link it: The arXiv page is real and reports NeurIPS 2024 publication. The abstract directly describes harmful fine-tuning risks, a defense operating even when attackers have weight access, removal of information about harmful representations, retained harmless-task training, and preserved general capability.
Do not overclaim: The paper itself notes ineffective areas. It does not show complete resistance to unlimited-compute attacks, architecture changes, re-pretraining from base checkpoints, or all model-modification methods.

Tamper-Resistant Safeguards for Open-Weight LLMs — confidence: high

Supports: Open-weight LLM safeguards can be made empirically resistant to fine-tuning-based tampering for hundreds of fine-tuning steps while preserving benign capabilities, making tamper-resistance a concrete open-weight release-risk research direction.
Why link it: The arXiv page is real. Its abstract directly addresses open-weight LLM safeguard tampering, says refusal and unlearning safeguards can be removed with a few fine-tuning steps, proposes TAR, and reports greatly improved tamper-resistance after hundreds of fine-tuning steps while preserving benign capabilities.
Do not overclaim: It supports evaluated fine-tuning tamper resistance, not arbitrary modification resistance against all full-weight attacks, unlimited compute, architecture surgery, re-pretraining, or ecosystem-wide deployment practice.

Vaccine: Perturbation-aware Alignment for Large Language Models against Harmful Fine-tuning Attack — confidence: high

Supports: Research prototypes can make aligned LLMs more robust to harmful fine-tuning by identifying harmful embedding drift and training hidden embeddings to be more invariant under perturbations while preserving benign reasoning in evaluated open-source models.
Why link it: The arXiv page is real and reports NeurIPS 2024 acceptance. The abstract directly describes harmful fine-tuning, harmful embedding drift, perturbation-aware alignment, invariant hidden embeddings, and evaluations on Llama2, OPT, and Vicuna preserving benign reasoning.
Do not overclaim: It is bounded to evaluated harmful fine-tuning settings and model choices. It does not prove general deployed modification resistance or robustness to arbitrary full-weight attackers.

6.4.3 Detection and Authorization of Dual-Use Capability at Inference Time

A Content-Based Framework for Cybersecurity Refusal Decisions in Large Language Models — confidence: high

Supports: For cybersecurity dual-use requests, research progress exists toward content-based refusal/allowance frameworks that evaluate offense-defense tradeoffs rather than relying only on stated intent or broad offensive labels.
Why link it: The arXiv page is real. Its abstract explicitly concerns dual-use cybersecurity tasks and proposes five content-grounded dimensions—Offensive Action Contribution, Offensive Risk, Technical Complexity, Defensive Benefit, and Expected Frequency for Legitimate Users—grounded in request substance rather than stated intent.
Do not overclaim: It is a framework for designing/auditing cyber refusal policies, not public evidence of a deployed reliable classifier, identity-verification system, trusted-user exemption, or cross-domain authorization standard.

Constitutional Classifiers: Defending against Universal Jailbreaks across Thousands of Hours of Red Teaming — confidence: high

Supports: Classifier-guard approaches have concrete technical evidence in a narrow high-risk setting: Anthropic's Constitutional Classifiers use natural-language rules and synthetic data for input/output guarding against universal jailbreaks, with red-team and deployment-cost evidence.
Why link it: The arXiv page is real. Its abstract reports safeguards trained on synthetic data generated from natural-language rules, more than 3,000 estimated hours of red teaming, robust automated evaluations against held-out domain-specific jailbreaks, a 0.38% absolute increase in production-traffic refusals, and 23.7% inference overhead.
Do not overclaim: It supports classifier guards against jailbreaks and harmful-process extraction in high-risk domains. It does not prove identity/trust-based authorization, reliable defensive-versus-malicious cyber intent classification, or a general dual-use access-governance standard.

7.1 Translation of Governance Goals into Policies and Requirements

Artificial Intelligence Risk Management Framework (AI RMF 1.0) — confidence: high

Supports: NIST operationalized AI risk management into a voluntary framework using GOVERN, MAP, MEASURE, and MANAGE functions, while explicitly acknowledging that robust, verifiable, consensus risk metrics remain difficult and context-dependent.
Why link it: Verified via DOI/Crossref and the NIST PDF as NIST AI 100-1, January 2023. The report states that it is voluntary, rights-preserving, non-sector-specific, and use-case-agnostic, and its core is organized around GOVERN, MAP, MEASURE, and MANAGE. Its risk-measurement section states that lack of consensus on robust and verifiable measurement methods and applicability across use cases is an AI risk measurement challenge.
Do not overclaim: It is voluntary guidance and does not prove reduced harms, legal conformity, or objective cross-domain measurement; live RMF ecosystem and revision-status claims still need NIST web pages.

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — confidence: high

Supports: For generative AI, NIST translated the AI RMF into a profile mapping GAI-specific risk categories and suggested actions to RMF functions, while noting that risk estimation is hard because visibility into training data is limited and AI measurement and safety science are immature.
Why link it: Verified via DOI/Crossref and the NIST PDF as NIST AI 600-1, approved 25 July 2024. The report describes itself as a cross-sectoral profile and companion resource for the AI RMF; it lists GAI risks including CBRN information/capabilities, confabulation, dangerous content, privacy, environmental impacts, harmful bias/homogenization, human-AI configuration, information integrity/security, IP, abusive content, and value-chain/component integration, and maps suggested actions to RMF functions.
Do not overclaim: It is a voluntary profile, not a validated conformity-testing method or proof that the suggested actions are sufficient in all domains.

The Measure and Mismeasure of Fairness — confidence: high

Supports: Fairness requirements cannot be reduced to one universally correct metric; formal fairness definitions can conflict with policy goals and require context-specific judgment.
Why link it: Verified as a JMLR 2023 paper, 24(312):1-117. The abstract states that the paper categorizes formal fairness definitions, shows analytically and empirically that common definitions can produce strongly Pareto-dominated policies, and argues that equitable algorithm design requires grappling with context-specific consequences, directly supporting the caveat that objective fairness conformity tests are unsettled.
Do not overclaim: It addresses fairness specifically, not all AI Act or NIST conformity requirements, and does not provide a universal replacement metric.

AI Risk-Management Standards Profile for General-Purpose AI Systems (GPAIS) and Foundation Models — confidence: medium

Supports: Risk-management standards for general-purpose AI and foundation models have been translated into more detailed practices and controls by adapting general frameworks such as NIST AI RMF and ISO/IEC 23894 to GPAI-specific risks.
Why link it: Verified as a real UC Berkeley Center for Long-Term Cybersecurity white paper page with a downloadable profile. The page states that the document provides risk-management practices or controls for identifying, analyzing, and mitigating GPAIS risks and is tailored to complement the NIST AI RMF and ISO/IEC 23894; it also notes extensive stakeholder feedback and an updated v1.1 profile in January 2025.
Do not overclaim: It is a white paper/profile, not an official harmonised EU standard, not a legal presumption-of-conformity source, and not empirical proof that the controls are sufficient or objectively testable.

7.2 Deployment Corrections

Deployment Corrections: An incident response framework for frontier AI models — confidence: high

Supports: Deployment corrections are a concrete incident-response framework for frontier AI models, including user-based restrictions, access-frequency limits, capability/feature restrictions, use-case restrictions, and model shutdown, plus preparation, monitoring, execution, and recovery/follow-up processes.
Why link it: Verified as a real arXiv paper/report submitted 30 September 2023. The full text explicitly lists the five categories of deployment corrections and describes a four-part process inspired by cybersecurity incident response: preparation, monitoring and analysis, execution, and recovery/follow-up. It also recommends retaining access control, establishing dedicated incident-response processes, and making corrections permissible with downstream users.
Do not overclaim: It is a proposed framework, not evidence that providers have validated these corrections in real incidents; it explicitly limits applicability to controllable interfaces and says the discussed restrictions are largely unenforceable for open-source/open-weight models.

International AI Safety Report: Second Key Update: Technical Safeguards and Risk Management — confidence: medium

Supports: By late 2025, frontier AI risk-management and technical-safeguard practices had advanced, but expert synthesis still found major gaps: attackers could bypass current defenses and real-world safeguard effectiveness remained uncertain.
Why link it: Verified as a real International AI Safety Report / DSIT key update dated 25 November 2025, with a downloadable report and citation. The page states that the number of companies publishing Frontier AI Safety Frameworks more than doubled, while sophisticated attackers can often bypass current defences and the real-world effectiveness of many safeguards is uncertain; the report also cites the Open Problems paper and agent-deployment attack work.
Do not overclaim: It is an expert/government synthesis using research and industry evidence, not a primary paper validating any provider's deployment-correction mechanism or cross-provider incident playbook.

Security Challenges in AI Agent Deployment: Insights from a Large Scale Public Competition — confidence: medium

Supports: Current safeguards for deployed/agentic AI systems can be bypassed in realistic deployment-like scenarios, supporting the need for post-deployment monitoring and correction rather than confidence in static safeguards.
Why link it: Verified as a real arXiv paper submitted 28 July 2025. Its abstract reports a public red-teaming competition across 22 frontier AI agents and 44 realistic deployment scenarios, with 1.8 million prompt-injection attacks and more than 60,000 successful policy-violation attacks; it concludes that current AI agents have critical persistent vulnerabilities and require additional defenses.
Do not overclaim: It studies attacks and safeguard bypasses, not deployment corrections, rollback, shutdown, deactivation, incident recovery, or legal obligations.

8.1 Clarification of Associated Risks

A taxonomic system for failure cause analysis of open source AI incidents — confidence: high

Supports: Causal/failure-cause analysis of open-source AI incidents advanced through a taxonomy and expert workflow for inferring likely incident factors from AIID reports.
Why link it: The arXiv record is real and clickable; its abstract states that, because mandatory AI incident reporting is absent, analyses rely on public incidents and presents a taxonomy/workflow covering system goals, methods/technologies, and likely technical failure causes.
Do not overclaim: It is early and inference-based; it does not provide internal model/version/guardrail details or validated causal truth for non-public incidents.

Preventing Repeated Real World AI Failures by Cataloging Incidents: The AI Incident Database — confidence: high

Supports: Public AI-incident monitoring has a research lineage in the AI Incident Database, a searchable public collection of real-world AI failures.
Why link it: The arXiv record is real and clickable; its abstract introduces the AI Incident Database as an incident collection for avoidance and mitigation with faceted/full-text search over more than 1,000 incident reports.
Do not overclaim: It supports the AIID lineage only; it does not substantiate later MIT tracker counts/classifications or solve public-source sampling bias and non-public reporting.

The AI risk repository: A meta-review, database, and taxonomy of risks from artificial intelligence — confidence: high

Supports: Broad AI-risk taxonomy work consolidated many scattered risk frameworks into a unified repository/taxonomy for developers, policymakers, and auditors.
Why link it: The arXiv page is real and clickable; its abstract says the authors systematically analyzed 74 AI-risk frameworks containing 1,725 distinct risks and organized them into a unified system with two classification systems and practical tools.
Do not overclaim: It supports risk-taxonomy consolidation, not incident reporting, causal attribution, non-public incident capture, or severity calibration.

Towards a common reporting framework for AI incidents — confidence: high

Supports: OECD proposed structured common criteria for AI incident reporting across jurisdictions and sectors.
Why link it: The DOI resolves to an OECD Artificial Intelligence Papers report published 28 February 2025; OECD metadata and the report describe a common reporting framework with 29 incident-reporting criteria.
Do not overclaim: It is a reporting framework/proposal, not proof that all jurisdictions adopted mandatory reporting or that organizations submit complete non-public technical metadata.

Trends in AI incidents and hazards reported by the media — confidence: high

Supports: OECD analyzed media-reported AI incidents and hazards from AIM, supporting the claim that public incident monitoring produces analyzable but media-limited trend data.
Why link it: The DOI resolves to an OECD Artificial Intelligence Papers report published 10 February 2026; OECD materials describe analysis of AIM media reports from January 2022 through September 2025 and thematic trend groupings.
Do not overclaim: It measures media-reported incidents/hazards and media attention, not true incident prevalence, complete coverage, or validated causal responsibility.

8.2 Prediction of Future Developments and Impacts

Artificial Intelligence Index Report 2026 — confidence: high

Supports: AI progress tracking became more data-rich through the 2026 Stanford AI Index’s measurement of technical performance, economics, labor effects, science/medicine applications, governance, and evaluation gaps.
Why link it: The arXiv page is real and clickable; its abstract identifies the ninth AI Index report and states that it tracks reasoning, safety, real-world task execution, economic value, labor-market effects, AI sovereignty, science, and medicine while warning that measurement is increasingly difficult to rely on.
Do not overclaim: It is a measurement synthesis, not a validated forecasting model or proof of policy-grade prediction.

International AI Safety Report 2026 — confidence: high

Supports: General-purpose AI risks, capabilities, impacts, scenarios, forecasts, and risk-management approaches received a major international scientific synthesis for policymakers in 2026.
Why link it: The official report page is real and clickable; it identifies the report as a February 2026 comprehensive review of scientific research on general-purpose AI capabilities and risks, led by Yoshua Bengio, authored by over 100 experts, and backed by over 30 countries/international organisations.
Do not overclaim: It is a synthesis and scenario/forecast assessment, not a single validated predictive model or deployed monitoring system.

Measuring AI Ability to Complete Long Software Tasks — confidence: high

Supports: Forecast-relevant capability measurement advanced via 50%-task-completion time horizons for AI agents on software tasks, with reported frontier time horizons doubling roughly every seven months since 2019.
Why link it: The arXiv page is real and clickable; its abstract defines the 50%-task-completion time horizon, reports Claude 3.7 Sonnet around a 50-minute horizon, and reports approximately seven-month doubling since 2019.
Do not overclaim: The paper is mainly about software/reasoning tasks and explicitly discusses external-validity limits; it does not forecast broad social, economic, or catastrophic impacts.

Energy and AI — confidence: medium

Supports: AI energy-demand and energy-system impact forecasting became more data-rich through global/regional modelling of AI electricity consumption, energy sources, security, emissions, innovation, and affordability.
Why link it: The official IEA report page is real and clickable; it states that the report uses new global and regional modelling and datasets, includes projections of AI electricity consumption over the next decade, and analyzes energy security, emissions, innovation, and affordability.
Do not overclaim: This is an institutional analytical report rather than an academic paper, and it forecasts energy-system implications rather than overall AI capability or societal impact trajectories.

8.3 Assessment of Environmental Impacts

EcoLogits: Evaluating the Environmental Impacts of Generative AI — confidence: high

Supports: Inference-impact tooling advanced through a citable open-source software paper for estimating environmental impacts of generative-AI inference requests.
Why link it: The DOI resolves to a Journal of Open Source Software article published 9 July 2025, with the title, authors, journal, and DOI metadata verified.
Do not overclaim: The JOSS paper establishes the software, but current method scope/exclusions such as training, networking, end-user devices, and end-of-life should be cited to EcoLogits documentation.

Estimating the Carbon Footprint of BLOOM, a 176B Parameter Language Model — confidence: high

Supports: Lifecycle-style carbon accounting for large language models can include dynamic training energy, embodied equipment emissions, operational consumption, and inference deployment energy.
Why link it: The arXiv page is real and clickable; its abstract states that the paper quantifies BLOOM’s carbon footprint across its life cycle, including equipment manufacturing, operational consumption, and real-time API inference.
Do not overclaim: It is a single-model carbon case study and does not provide universal lifecycle, water, raw-mineral, or data-center construction accounting.

Making AI Less "Thirsty": Uncovering and Addressing the Secret Water Footprint of AI Models — confidence: high

Supports: Water footprint is a distinct AI environmental-impact dimension that varies with data-center cooling, electricity generation, time, and location and should be assessed alongside carbon.
Why link it: The arXiv page is real and clickable; its abstract provides a methodology to estimate AI water footprint, discusses spatial-temporal diversity in runtime water efficiency, and argues that water must be addressed holistically with carbon.
Do not overclaim: It does not provide a deployed universal water label and relies on estimates where providers do not disclose operational data.

Power Hungry Processing: Watts Driving the Cost of AI Deployment? — confidence: high

Supports: Inference energy/emissions vary strongly by task and model architecture, supporting task-specific ratings rather than one universal per-model environmental number.
Why link it: The arXiv page is real and clickable; its abstract reports a systematic comparison of energy/carbon for 1,000 inferences across task-specific and general-purpose models and finds multi-purpose generative architectures orders of magnitude more expensive than task-specific systems for many tasks.
Do not overclaim: It does not establish a regulator-recognized label, complete lifecycle accounting, or coverage of arbitrary providers/deployment configurations.

Quantifying the Carbon Emissions of Machine Learning — confidence: high

Supports: Training/experiment carbon estimation was operationalized through a calculator using training location, grid, duration, and hardware details.
Why link it: The arXiv page is real and clickable; its abstract presents the Machine Learning Emissions Calculator and identifies location/grid, training duration, and hardware make/model as key variables for estimating ML training emissions.
Do not overclaim: It estimates training/experiment emissions and is not a complete lifecycle assessment for arbitrary model-task-provider combinations.

8.4 Supply Chain Mapping

AI Chips: What They Are and Why They Matter — confidence: high

Supports: Hardware supply-chain mapping is supported by reports showing that state-of-the-art AI chips are essential for cost-effective frontier AI and that chip design, fabs, EDA, and semiconductor manufacturing equipment are geographically concentrated chokepoints.
Why link it: The CSET report page is real and clickable; it states that leading-edge specialized AI chips are essential for cost-effective AI at scale and that key supply-chain capabilities are concentrated among U.S. and allied firms.
Do not overclaim: It supports hardware chokepoint mapping, not individual chip tracking, diversion prevention, customer due diligence, or an end-to-end auditable AI supply-chain log.

AIBoMGen: Generating an AI Bill of Materials for Secure, Transparent, and Compliant Model Training — confidence: high

Supports: Prototype tooling can automatically generate signed/verifiable AIBOMs during model training using captured datasets, model metadata, environment details, hashes, signatures, and in-toto attestations.
Why link it: The arXiv page is real and clickable; its abstract describes a proof-of-concept platform that captures datasets, model metadata, and environment details during training and uses cryptographic hashing, digital signatures, and in-toto attestations to detect tampering.
Do not overclaim: It is a proof of concept centered on model training artifacts, not production cross-organization end-to-end provenance from raw data/chips to deployment and outputs.

Datasheets for Datasets — confidence: high

Supports: Dataset documentation can standardize disclosure of dataset motivation, composition, collection process, recommended uses, and other provenance-relevant details.
Why link it: The arXiv page is real and clickable; its abstract proposes datasheets documenting dataset motivation, composition, collection process, recommended uses, and related information to improve transparency and accountability.
Do not overclaim: Datasheets are documentation artifacts; they do not automate verification, provide tamper evidence, or cover model weights, deployment infrastructure, chips, suppliers, or outputs.

FactSheets: Increasing Trust in AI Services through Supplier's Declarations of Conformity — confidence: high

Supports: AI service/system documentation can include supplier declarations of conformity covering purpose, performance, safety, security, lineage, and provenance.
Why link it: The arXiv page is real and clickable; its abstract proposes FactSheets for AI services containing purpose, performance, safety, security, and provenance information completed by AI service providers.
Do not overclaim: It is a documentation framework, not a cryptographic ledger, legal reporting regime, or proof that suppliers disclose accurate information.

Implementing AI Bill of Materials (AI BOM) with SPDX 3.0: A Comprehensive Guide to Creating AI and Dataset Bill of Materials — confidence: high

Supports: AI Bill of Materials research extends SBOM concepts to AI projects by documenting algorithms, data collection methods, frameworks/libraries, licensing, and standards compliance.
Why link it: The arXiv page is real and clickable; its abstract explicitly introduces AI-BOMs expanding SBOMs to include algorithms, data collection methods, frameworks/libraries, licensing information, and standards compliance.
Do not overclaim: It explains the AI-BOM concept but does not prove industry-wide adoption, tamper-proof completeness, SPDX 3.0.1 normative content, or physical hardware/mineral/chip coverage.

Non-paper evidence gaps and deployment/regulatory caveats

3 Assessment: Re-LAION-5B cleanup counts, safe diffs, gating, and final release mechanics require LAION operational/release sources, not the Stanford CSAM report alone.
3 Assessment: Croissant field-level schema claims such as JSON-LD, FileObject/FileSet, contentUrl, sha256, RecordSet/Field, and Croissant RAI traceability/regulatory vocabulary require MLCommons Croissant and Croissant RAI specifications.
3 Assessment: DPI live dashboards, AI Observatory status, and other 2026 deployment/site claims require Data Provenance Initiative website/dashboard sources.
3 Assessment: FineWeb live token counts beyond the paper, 2025 Common Crawl snapshot configurations, and current hosted dataset details require Hugging Face dataset cards or project documentation.
3 Assessment: Common Pile, DataComp-LM, ROOTS, TRAK, JailbreakBench, HarmBench, StrongREJECT, PyRIT, AgentHarm, RE-Bench, and similar artifact availability/current-maintenance claims require repositories, dataset cards, project pages, or benchmark pages when the claim is about current access rather than the paper result.
3 Assessment: BIS/EAR export-control claims about TPP, performance density, HBM bandwidth density, ECCNs, AI Diffusion Rule status, non-enforcement/rescission, GAO legal status, Data Center VEU, and May/June 2026 guidance/FAQ require Federal Register, BIS, GAO, or other official legal sources.
3 Assessment: Commerce IaaS/KYC/reporting, executive-order compute-threshold, and regulatory workload-classification demand claims require executive orders and Federal Register/Commerce materials, not workload-classifier papers.
3 Assessment: EU AI Act Article 27, Article 55, Article 72, application dates, AI Office/Commission templates, and legal obligations require official legal text or authoritative legal sources.
3 Assessment: NIST AI 600-1 risk-management/red-team/monitoring/impact-evaluation guidance is a standards/government source and should be treated as non-paper evidence.
3 Assessment: Anthropic Responsible Scaling Policy version/effective-date, ASL safeguards, Frontier Safety Roadmaps, Risk Reports, off-cycle review, and LTBT/external-review process claims require Anthropic official policy/report pages.
3 Assessment: OpenAI Evals/API productization, Evals deprecation dates, Datasets migration, SimpleQA implementation details, SWE-bench Verified human validation/audit statistics, and Docker harness claims require OpenAI/product/project documentation.
3 Assessment: Inspect AI current feature counts and exact current support for MCP/custom tools, sandboxing backends, multi-agent primitives, and external agent CLI bridges require official Inspect documentation/repository pages.
3 Assessment: HELM Safety live dashboard status, current safety categories, latest model results, and data explorer claims require Stanford CRFM HELM Safety pages, not the original HELM paper.
3 Assessment: AI Agent Index current database contents and update status require the live AI Agent Index website, not only the arXiv paper.
3 Assessment: Any claim that a frontier lab or regulator has deployed governance-grade training-data attribution, workload classifiers, automated red-teaming, multi-agent evaluation, or downstream-impact prediction in production requires official deployment documentation, regulator filings, audits, provider system/model cards, or procurement/enforcement records.
3 Assessment: Jurisdiction-sensitive copyright, fair-use, and licensing conclusions require legal authority, case law, or legal scholarship; technical papers can support uncertainty and operational metadata/provenance advances but not universal legal determinations.
4 Access: Current operational facts about OpenSAFELY project counts, liveness, access workflow, and NHS governance should be cited to official OpenSAFELY/NHS documentation, not papers.
4 Access: Current OpenMined AI-auditor product claims, CCIAO demonstrations, Dailymotion/LinkedIn deployments, and Syft workflow details should be cited to OpenMined documentation and official government/partner case studies, not Syft papers alone.
4 Access: Project Oak capabilities, attestation channels, release/provenance features, and sealed-computing architecture should be cited to the Project Oak repository and official documentation; Ryoan/Opaque only support the older technical class.
4 Access: NAIRR Secure pilot status, provider capacity, interagency demonstration projects, and 2026 updates should be cited to official NSF/DOE/NIH/NAIRR pages rather than workshop reports or papers.
4 Access: Hugging Face gated-dataset features, METR canary warnings, benchmark repository release status, and custom evaluation API/product workflows are platform/deployment facts requiring official docs or live pages.
4 Access: NAIRR Pilot project counts, allocation calls, allocation-management policy, NAIRR-OC transition, and EuroHPC AI Factories numbers/access modes are official program facts requiring NSF/NAIRR/EuroHPC sources.
4 Access: UK AISI evaluation practices, Seoul voluntary commitments, Anthropic RSP versions, OpenAI Preparedness Framework details, and OpenMined/AISI/Anthropic secure-enclave pilot details require official government/company/nonprofit documents or pilot reports.
4 Access: EU DSA Article 40 and EU AI Act log/access obligations are legal claims requiring primary legal texts and implementation guidance, not research papers.
4 Access: Any claim that no general mandated independent access regime exists for frontier-model training datasets, near-white-box model access, or raw user-interaction logs requires up-to-date legal, standards-body, and provider-policy review; no single paper can prove that negative institutional claim.
5 Verification: EU AI Act claims for Article 50, Article 53, Article 55, Annex XI, GPAI systemic-risk duties, application dates, exceptions, and the GPAI Code of Practice must be cited to EUR-Lex/Official Journal and European Commission/AI Office materials, not papers.
5 Verification: Training-data transparency/template claims under the EU AI Act need the official AI Office/Commission training-content summary template and explanatory materials.
5 Verification: InfoTracer's current open-source availability, license, maintenance status, and practical deployability need the author/institution repository or package/release page, even though the Nature paper states a tool was released.
5 Verification: Any claim of production-grade exact all-and-only training-corpus verification needs deployment documentation, audit standards, certification schemes, regulator guidance, or independently audited case studies; none of the approved papers establishes it.
5 Verification: NVIDIA/AMD/Caliptra chip attestation, confidential computing, SPDM/TCG-format reports, GPU confidential containers, KBS/key release, and AI factory workflows require vendor documentation, standards specifications, or project repositories; papers only support the underlying primitives.
5 Verification: Chip-location claims about an NVIDIA H100 demo, 100-500 landmark estimates, $25k/landmark/year costs, regulator-scale deployment, or absence of standards/adversarial red-team results require IAPS web/demo pages, regulator/standards sources, or deployment evidence beyond papers.
5 Verification: Hugging Face Hub version history, commits/revisions, UI diffs, and product versioning must be cited to Hugging Face product documentation, not dynamic-system papers.
5 Verification: Anthropic/OpenAI system cards are acceptable vendor reports for transparency practices, but public release dates, deployment process, and web-facing scorecards should be supported by provider pages/PDFs; they do not prove served-system identity.
5 Verification: C2PA normative capability claims need official C2PA specifications and guidance documents. The approved C2PA critique supports limitations, not what the standard officially defines.
5 Verification: Google SynthID product availability across text/image/audio/video, SynthID Detector access, developer tooling, detector states, and modality coverage need Google DeepMind / Google AI Developer documentation and announcements in addition to the Nature/arXiv papers.
5 Verification: NIST AI RMF Generative AI Profile and synthetic-content transparency recommendations are government framework sources; use NIST documents for official risk-management recommendations rather than forcing them into paper evidence.
5 Verification: Claims that PoL, PoLO, PoTS, ZkAudit, zkLLM, confidential inference, or proof-of-useful-work PoL are deployed in production governance/blockchain/model-audit systems require official deployment announcements, project documentation, audited protocol docs, standards, or regulator/lab filings.
7 Operationalization: EU AI Act obligations, implementation dates, Service Desk/tools, GPAI Code of Practice status, public-summary/transparency templates, and binding legal duties should be sourced to EUR-Lex Regulation (EU) 2024/1689 and official European Commission AI Act/GPAI pages, not papers.
7 Operationalization: CEN/CENELEC harmonised-standard development status, prEN 18286 public enquiry status, and any presumption-of-conformity claim require official European Commission standardisation pages, CEN/CENELEC JTC 21 materials, and Official Journal references when available.
7 Operationalization: NIST AI RMF live-resource claims beyond the reports themselves—Playbook, Roadmap, Crosswalks, Resource Center, Perspectives, revision status, and any 2026 critical-infrastructure profile concept note—need official NIST AI RMF pages.
7 Operationalization: NIST AI Consortium membership count, scope expansion, and measurement/standards work need official NIST Consortium pages and Federal Register notices rather than papers.
7 Operationalization: OECD Hiroshima AI Process Reporting Framework launch/status, rolling submissions, questionnaires, and 1 September 2026 review cutoff require the live OECD.AI reporting-framework page and linked materials.
7 Operationalization: Provider deployment-governance claims—OpenAI Preparedness Framework v2, Anthropic Claude Opus/Sonnet ASL determinations and incident-response protocols, Google DeepMind Frontier Safety Framework CCL/early-warning process, model-specific safeguards, monitoring, red-teaming, and bug bounties—need provider frameworks, system cards, model cards, or audit/assurance reports.
7 Operationalization: EU AI Act post-market monitoring, serious-incident reporting, corrective action, and GPAI/systemic-risk duties under Articles 55, 72, and 73 require the legal text and official regulatory guidance; papers can only contextualize them.
7 Operationalization: A finalized or revised 2026 ISO/IEC AI management-system or SC 42 status claim needs ISO/IEC catalogue/work-programme evidence or a published standard/press release.
7 Operationalization: No verified paper in the candidate set establishes a universal AI risk indicator or objective conformity test spanning compute, capability, deployment context, widespread use, and societal harm; the retained paper evidence supports the opposite, limiting claim.
7 Operationalization: No verified paper in the candidate set validates a cross-provider, field-tested deployment-correction playbook for disruption-minimizing rollback/shutdown across API ecosystems, open weights, fine-tuned derivatives, or third-party dependency chains.
8 Ecosystem: 8.1: OECD AIM current live monitor fields, deployment status, Azure/Event Registry notes, and dynamic examples require the official OECD.AI AIM page, not papers.
8 Ecosystem: 8.1: MIT AI Risk Initiative tool-suite claims, AI Incident Tracker dimensions/counts, and the June 2026 pilot validation should be cited to official MIT pages/blogs; no paper in the checked set supports those operational details.
8 Ecosystem: 8.1: NIST GenAI Profile risk categories and EU AI Act serious-incident duties/application dates require NIST and EUR-Lex/European Commission legal sources, not research papers.
8 Ecosystem: 8.1: A negative claim that no mandatory global non-public AI incident-reporting regime exists needs bounded legal/regulatory survey evidence; no single technical paper proves it.
8 Ecosystem: 8.2: OECD.AI live data, OpenAI Preparedness Framework, Google DeepMind Frontier Safety Framework, Anthropic Responsible Scaling Policy, and current METR release/version claims are non-paper dashboard/company/release sources.
8 Ecosystem: 8.3: CodeCarbon current workflows, ML CO2 Impact current UI/PUE caveat, EcoLogits current methodology exclusions, NIST AI 600-1 environmental-risk guidance, OECD compute-environment portal details, and Hugging Face AI Energy Score leaderboard/star ratings require official docs/pages.
8 Ecosystem: 8.3: No approved paper establishes a universal, regulator-recognized, end-to-end environmental label for arbitrary model-task-provider combinations as of July 2026; that absence must be stated as a bounded synthesis over standards and product-scope sources.
8 Ecosystem: 8.4: SPDX 3.0.1 profile/class/property details and C2PA AI/ML Content Credentials are normative standards claims requiring official SPDX/C2PA specs.
8 Ecosystem: 8.4: OECD HAIP participation/publication details and BIS advanced-computing guidance are live institutional/legal claims requiring official OECD/BIS pages.
8 Ecosystem: 8.4: No approved source establishes an end-to-end auditable log spanning raw data, minerals, chips, training, fine-tuning, deployment, and outputs; current paper support is limited to narrow digital documentation/provenance artifacts and hardware chokepoint mapping.
6 Security A: For 6.1.1, cite NIST AI 600-1 for standards/risk framing around generative-AI memorization/leakage; cite OpenAI, Azure AI Content Safety, and NVIDIA NeMo Guardrails official documentation for moderation, protected-material, PII, and guardrail product-scope claims.
6 Security A: For 6.2.1, use NVIDIA vendor documentation/whitepapers/attestation-suite docs for H100 confidential-computing features, NRAS/RIM/NDIS/OCSP validation paths, firmware/security claims, and SPDM details; no independent paper in the checked set verifies the full product workflow end to end.
6 Security A: For 6.2.1 and 6.2.3, use Caliptra official specification/repository/project pages for Caliptra identity, measured boot, and attestation capabilities; treat Caliptra as specification evidence, not a peer-reviewed paper or deployment proof.
6 Security A: For 6.2.1 and 6.2.2, use OpenTitan official project/deployment/certification documentation for Chromebook shipment, datacenter deployment, FIPS/Common Criteria positioning, and certification status; the OpenTitan papers only support technical root-of-trust/crypto-offload research.
6 Security A: For 6.2.2, use FIPS 140-3, ISO/IEC 19790/24759, NIST SP 800-140-series, and CMVP materials for cryptographic-module physical-security and validation requirements; do not infer AI accelerator anti-tamper deployment from those standards.
6 Security A: For 6.2.2, use NVIDIA GB200/NVL72/Blackwell product documentation for rack-scale liquid-cooling, HBM, NVLink, and density constraints relevant to anti-tamper feasibility; papers should not be used to source exact production hardware specs.
6 Security A: For 6.2.2 and 6.3.1, use OpenAI and Anthropic frontier-governance/security policy documents for company-stated physical security, model-weight safeguards, inspections, chain-of-custody, tamper-resistance roadmap items, and deployment-status claims; these are not independent audit papers.
6 Security A: For 6.2.3, use BIS May 2026 guidance, BIS June 2026 FAQ, EAR text, and the January 2025 Federal Register due-diligence rule for regulatory scope and operative licensing requirements.
6 Security A: For 6.2.3, use Google Cloud's remote-attestation documentation for production cooperative-cloud attestation workflows; it is product documentation and does not prove non-cooperative export-control enforcement.
6 Security A: For 6.2.3, cite TPM, DICE, DMTF SPDM, Redfish, and IETF RATS/RFC 9334 specifications for protocol and attester/verifier terminology where implementation details are discussed.
6 Security A: For 6.3.1, use Anthropic Responsible Scaling Policy pages for Anthropic-specific ASL safeguards and deployment/planned-status claims; use MITRE ATLAS directly for living threat-taxonomy entries such as AI Model Access, Extract AI Model, and AI IP Theft.
6 Security A: Across 6.2.1-6.2.3, no checked paper proves production, governance-grade, cluster-wide AI accelerator attestation with auditable model/data/workload identity, robust firmware rollback governance, and physical anti-tamper assurance at datacenter scale; any such claim needs vendor docs, independent audits, certification records, or regulator/hyperscaler deployment evidence.
6 Security B: 6.3.2: Use NVIDIA, Caliptra, OpenTitan, Confidential Containers/KBS, and Anthropic Responsible Scaling Policy documents only as infrastructure/product/policy sources; none of the approved papers establishes deployed frontier-model shared governance with independent technical co-authorization of every operation.
6 Security B: 6.3.3: Any claim of regulator-approved, legally sufficient, multilingual, multimodal, production, privacy-law, or copyright-law disgorgement/unlearning needs official legal/regulatory/product/audit evidence; the approved papers support research benchmarks, methods, and limitations only.
6 Security B: 6.4.1: Current NVIDIA NeMo/NemoGuard feature lists, Anthropic ASL-3 safeguard plans, OWASP LLM Top 10, and MITRE ATLAS technique lists require official product/policy/standards pages; papers only support guardrail concepts, classifier prototypes, and evasion evidence.
6 Security B: 6.4.2: Claims about OpenAI fine-tuning dataset screening or ecosystem-wide adoption of tamper-resistance evaluations require provider documentation/model release reports; the approved papers support bounded research prototypes only.
6 Security B: 6.4.3: OpenAI Trusted Access for Cyber, API-credit grants, identity verification, trusted-user access, Anthropic deployment exemptions, bug bounties, threat intelligence, NIST/OWASP guidance, and any positive claim of reliable inference-time authorization require provider or standards sources, not papers.

Dropped or needs-verification candidates

3 Assessment / 3.1.1: Identifying and Eliminating CSAM in Generative ML Training Data and Models — Real and clickable as a Stanford Internet Observatory report/PDF, but not a research paper; use as a non-paper source for LAION-5B CSAM identification and keep LAION Re-LAION cleanup facts separate to LAION operational sources.
3 Assessment / 3.1.3: DataComp-LM: In search of the next generation of training sets for language models — Real and strong for controlled data-curation experiments, but in 3.1.3 it supports dataset-curation effects rather than per-output/model-behavior attribution; already stronger fits 3.1.2.
3 Assessment / 3.1.3: Best Practices and Lessons Learned on Synthetic Data — Real survey/best-practices paper, but weaker than the Nature model-collapse paper for recursive synthetic-data risk and not itself an attribution method; not needed for a concise paper map.
3 Assessment / 3.1.3: Sketching the Readout of Large Language Models for Scalable Data Attribution and Valuation — Real and directly related, but redundant with stronger/clearer attribution-method entries LoRIF and STRIDE for a 2-5 paper map; keep only if more 2026 attribution-method breadth is needed.
3 Assessment / 3.1.3: Data Attribution in Large Language Models via Bidirectional Gradient Optimization — Real and directly related, but weaker/not needed relative to TRAK, EK-FAC, LoRIF, and STRIDE; its AAAI AIGOV workshop status and known-dataset setting warrant cautious use if added.
3 Assessment / 3.1.3: A Human-Centric Framework for Data Attribution in Large Language Models — Real and accepted at FAccT 2026, but it is a governance/stakeholder framework, not a technical attribution advance; useful as contextual framing, not core paper-backed technical progress.
3 Assessment / 3.2.1: Open Problems in Technical AI Governance as evidence for chip-definition operationalization — Real source paper for baseline framing, but it does not prove BIS/Federal Register chip, HBM, data-center, or export-control operationalization; those claims need official legal/regulatory sources.
3 Assessment / 3.2.2: Open Problems in Technical AI Governance as evidence for workload-classifier performance — Real baseline paper, but it is an open-problems/taxonomy source and does not validate a telemetry classifier; cite separately only for problem framing if needed.
3 Assessment / 3.3.1: Measuring short-form factuality in large language models / SimpleQA — Real and clickable; directly supports a narrow factuality benchmark, but less central than LiveBench, FrontierMath, SWE-bench, SWE-bench audit, and Inspect for a concise reliable-evaluations map.
3 Assessment / 3.3.1: Humanity's Last Exam — Real and clickable; broad expert-question benchmark, but redundant with FrontierMath/LiveBench for the retained concise set. Add if the topic specifically needs broad closed-ended academic expert coverage.
3 Assessment / 3.3.1: Developing and Maintaining an Open-Source Repository of AI Evaluations: Challenges and Insights — Real and useful for inspect_evals maintenance, but narrower and less foundational than the Inspect Zenodo record for framework existence; not needed unless repository-maintenance process is a separate claim.
3 Assessment / 3.3.3: The AI Agent Index — Real and clickable, but it documents deployed agentic systems and disclosure gaps rather than evaluating agent behavior; useful transparency source, not a core multi-agent evaluation paper.
3 Assessment / 3.3.3: Inspect AI: Framework for Large Language Model Evaluations — Real Zenodo software record, but already retained for 3.3.1; for 3.3.3, exact current agent/MCP/multi-agent feature claims require official Inspect documentation rather than the white paper alone.
3 Assessment / 3.3.3: Developing and Maintaining an Open-Source Repository of AI Evaluations: Challenges and Insights — Real but about maintaining inspect_evals, not agent/multi-agent benchmark validity or responsibility attribution; not needed in the core agent-evaluation map.
3 Assessment / 3.4.1: International AI Safety Report 2026 — Real and clickable evidence-synthesis report, but not a research paper or new method; classify as a non-paper/government-report source for evidence-gap and risk-management framing.
3 Assessment / 3.4.1: Evaluating the Social Impact of Generative AI Systems in Systems and Society — Do not use as an approved paper citation: the arXiv record is withdrawn/removed by administrators and has no PDF available, even though the abstract is relevant.
3 Assessment / 3.1.1-3.4.1: Open Problems in Technical AI Governance across repeated topic entries — Real and important as the original TAIG baseline/open-problems source, but it is generally not evidence of the later advances. Use it separately for problem framing/limitations, not as an advance-supporting paper unless the explicit claim is only that the problem remains open.
4 Access / 4.1.1: A generic framework for privacy preserving deep learning — Real and clickable, but early PySyft work is redundant with the stronger Syft 0.5 structured-transparency citation for this topic and is weaker evidence for third-party dataset access or audit workflows.
4 Access / 4.1.1: Final Report of the 2024 NSF/DOE Workshop on NAIRR Software — Real and clickable, but it is a workshop/government report about NAIRR software needs rather than a paper directly establishing privacy-preserving third-party dataset access; not needed beside OpenSAFELY, Syft, Ryoan, Opaque, and the open-problems source.
4 Access / 4.1.2: Humanity's Last Exam — Real and clickable, but it mainly supports benchmark difficulty, closed-ended questions, and automated grading. It does not directly preserve evaluation-data integrity after public release and is weaker than LiveBench, Hashmarks, and adaptive-leaderboard papers for this topic.
4 Access / 4.2.1: Computing Power and the Governance of Artificial Intelligence — Real and clickable, but it is a broad compute-governance paper. For compute inequity specifically, Besiroglu et al., Ahmed and Wahed, the NAIRR Task Force report, Open Problems, and the portability paper are more direct.
4 Access / 4.2.1: Governing Through the Cloud: The Intermediary Role of Compute Providers in AI Regulation — Real and clickable, but it supports compute-provider verification and workload classification rather than the central access/inequity claim. Use only if discussing intended-use assurance by providers.
4 Access / 4.2.1: Dominant Resource Fairness: Fair Allocation of Multiple Resource Types — Real and clickable, but it is a classic general systems allocation paper, not AI-specific public compute access evidence and not evidence that NAIRR or EuroHPC uses a fair-allocation algorithm.
4 Access / 4.3.1: Developing a Framework for Secure Third-Party Access to Frontier AI — Clickable RUSI research-paper page, but it is grey-literature framework evidence and not needed if keeping the stronger peer/arXiv sources on black-box insufficiency, structured access, compliance reviews, and TEE audit prototypes.
4 Access / 4.3.1: Confidential Inference Systems: Design principles and security risks — Real Anthropic/Pattern Labs whitepaper, but it is about confidential inference generally rather than third-party audit access, logits, fine-tuning, interpretability access, or hosted-model reproducibility.
4 Access / 4.4.1: RealityTest: How People Probe AI Identity and Whether Models Disclose It — Real and clickable, but it supports human-grounded evaluation data, not downstream production-log access or third-party access to provider/deployer interaction logs. It is adjacent rather than core.
4 Access / 4.4.1: Constitutional Classifiers: Defending against Universal Jailbreaks across Thousands of Hours of Red Teaming — Real and clickable, but it supports provider-side classifier safeguards and production-traffic refusal overhead, not external third-party access to downstream user logs.
4 Access / 4.4.1: Constitutional Classifiers++: Efficient Production-Grade Defenses against Universal Jailbreaks — Real and clickable, but it is still about internal/provider-side jailbreak defenses and production-grade classifiers, not access to logs or independent downstream-impact research.
5 Verification / 5.2.1: Physical Unclonable Functions — Real and clickable Nature Electronics review, but only supports a generic hardware-identity primitive. It is too indirect for the chip-location topic when the IAPS location report and CNAS secure-chips report already provide direct AI-chip governance support.
5 Verification / 5.2.1: Proofs of Work and Bread Pudding Protocols (Extended Abstract) — Real DOI/book chapter, but only background for proof-of-work generally. It does not directly support AI-chip location verification, trusted landmarks, attestation, export controls, or deployment.
5 Verification / 5.2.2: A Survey of Secure Computation Using Trusted Execution Environments — Real arXiv survey and relevant to TEEs, but too generic and redundant for this topic; the ML confidential-computing SOK, NVIDIA confidential-GPU article, Shavit compute-monitoring proposal, and CNAS report are more direct.
5 Verification / 5.2.2: DeepAttest: An End-to-End Attestation Framework for Deep Neural Networks — Real ACM DOI, but narrow DNN attestation and inference/IP-integrity work. It is not one of the strongest citations for compute-workload verification, regulatory FLOP accounting, or confidential GPU/Kubernetes operationalization.
5 Verification / 5.3.2: System Card: Claude Opus 4 & Claude Sonnet 4 — Real and useful vendor system card, but not a research paper proving dynamic-system verification. Keep as non-paper/vendor transparency evidence rather than a paper-backed advance.
5 Verification / 5.3.3: "Adversarial Examples" for Proof-of-Learning — Real and relevant critique, but redundant once "Proof-of-Learning is Currently More Broken Than You Think" is used as the stronger, broader fragility citation. Use only if an extra historical spoofing citation is needed.
5 Verification / 5.4.1: Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models — The RAND PDF URL was not fetchable through the reader due to HTTP 403, and the claim is a broader security-framework motivation rather than direct verifiable-audit evidence. Use a clickable RAND landing page if this report is needed.
5 Verification / 5.4.1: System Cards for AI-Based Decision-Making for Public Policy — Real arXiv paper and relevant to audit scorecards, but focused on public-policy decision-aiding systems. For TAIG verifiable audits, model cards, GPT-4o system card, zkLLM, and confidential inference are stronger/directer.
5 Verification / 5.4.2: A Practical Examination of AI-Generated Text Detectors for Large Language Models — Real arXiv paper and relevant, but redundant with RAID for the core claim that ex post AI-text detectors are brittle. Use only if a second detector-specific false-positive/TPR-at-fixed-FPR citation is desired.
5 Verification / 5.4.2: Reducing Risks Posed by Synthetic Content: An Overview of Technical Approaches to Digital Content Transparency — Real NIST report and good government synthesis, but it is best treated as a government framework/report source rather than a research paper. Use it for official risk-management framing, not as the primary paper evidence.
5 Verification / 5.2.1: NVIDIA H100 delay-based chip-location prototype/demo — Not supported by the 2024 IAPS report PDF itself. Needs the IAPS webpage/demo artifact or other non-paper deployment evidence.
5 Verification / 5.2.2: NVIDIA 2026 Confidential Containers / confidential AI factory reference architecture — The concrete Kubernetes/Kata/KBS/composite-attestation/product architecture is not a paper result. Needs NVIDIA documentation/blogs as non-paper product evidence.
7 Operationalization / 7.1: Model Cards for Model Reporting — Real and clickable, and relevant to standardized model documentation, but not needed in the trimmed 7.1 paper set because Open Problems already uses model cards as an example while the stronger retained sources cover the broader governance-to-requirements and measurement-limit claims. Reintroduce only if the map needs a separate documentation-artifacts mini-topic.
7 Operationalization / 7.1: Datasheets for Datasets — Real and clickable, and relevant to dataset documentation, but redundant for the trimmed operationalization topic. It does not itself verify current legal/reporting fields under the EU AI Act, OECD reporting, or NIST profiles, so it is weaker than the retained framework/profile and open-problems sources for this group.
7 Operationalization / 7.1: Fairness in Machine Learning: A Survey — Real and clickable, but weaker than The Measure and Mismeasure of Fairness for the specific claim that no single fairness metric should be treated as universally correct. It is useful background but not needed in a 2-5 strongest-paper map.
8 Ecosystem / 8.1: Defining AI incidents and related terms — Real OECD Artificial Intelligence Papers report, but not kept because the common-reporting-framework and AIM-trends OECD reports are stronger for the operational advance; use this only if the text specifically needs the incident/hazard/serious incident/disaster definitions.
8 Ecosystem / 8.1: International AI Safety Report 2026 as a 8.1 risk-clarification paper — Real and approved under 8.2 as a broad synthesis; for 8.1 it is broader than the incident/taxonomy advance and not needed if the Risk Repository, AIID, failure-cause, and OECD reporting/trends papers are cited.
8 Ecosystem / 8.2: Frontier lab preparedness/responsible-scaling frameworks — Useful for anticipatory monitoring claims, but these are company policy/framework documents rather than independent papers; cite official OpenAI, Google DeepMind, and Anthropic documents as non-paper sources.
8 Ecosystem / 8.2: OECD.AI live data dashboard — A strong official dashboard source for live indicators, but not a paper; cite the OECD.AI data page for deployment/current-field claims.
8 Ecosystem / 8.2: METR Time Horizon 1.1 current 2026 measurement/release claim — The arXiv paper supports the time-horizon method and trend; claims about the latest benchmark release, larger task suite, and public data/code links require METR’s release page rather than the paper alone.
8 Ecosystem / 8.3: Energy and AI as environmental-assessment evidence — Real IEA report and approved under 8.2 for energy-demand forecasting, but it is macro energy modelling rather than model/task/provider-level environmental assessment; not needed in the narrowed 8.3 paper set.
8 Ecosystem / 8.3: 2024 United States Data Center Energy Usage Report — Real DOE/LBNL report and useful for U.S. data-center electricity projections, but it is macro infrastructure modelling rather than AI lifecycle assessment for arbitrary systems; cite only for data-center demand, not end-to-end model environmental labels.
8 Ecosystem / 8.3: Light bulbs have energy ratings — so why can’t AI chatbots? — Real Nature Comment and useful for the energy-label proposal, but it is a comment/proposal and the deployed Hugging Face AI Energy Score claims need Hugging Face documentation/leaderboard pages.
8 Ecosystem / 8.3: CodeCarbon current tool behavior — No peer-reviewed CodeCarbon paper equivalent was verified here; current API/CLI behavior and the EcoLogits pointer should be sourced to CodeCarbon docs and software records, not relabeled as a research paper.
8 Ecosystem / 8.4: Model Cards for Model Reporting — Real and important for model transparency, but less directly tied to supply-chain provenance than AI-BOM/AIBoMGen, Datasheets, FactSheets, and AI-chip chokepoint reports in the constrained 8.4 set.
8 Ecosystem / 8.4: Data Statements for Natural Language Processing — Real TACL article, but NLP-specific and weaker for broad AI supply-chain mapping than the retained dataset/service/AIBOM sources.
8 Ecosystem / 8.4: Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI — Real FAccT/arXiv paper and a good secondary dataset-documentation citation, but redundant with Datasheets for the narrowed set; use if the text specifically discusses industry/research deployment of data-card templates.
8 Ecosystem / 8.4: Maintaining the AI Chip Competitive Advantage of the United States and its Allies — Real CSET report and useful for photolithography/SME chokepoints, but largely covered by the retained AI Chips report for the high-level hardware mapping claim; cite only if the text needs photolithography/deposition/etching/process-control detail.
8 Ecosystem / 8.4: Multilateral Controls on Hardware Chokepoints — Real CSET report/one-pager, but it is a policy recommendation about export-control coordination and enforcement, not an AI supply-chain mapping technology; weaker than the retained AI Chips report for paper-map purposes.
8 Ecosystem / 8.4: SPDX 3.0.1, C2PA AI/ML guidance, NIST GenAI Profile, OECD HAIP, and BIS 2026 guidance claims — These are standards, official guidance, reporting-framework, or legal/regulatory deployment claims, not papers; cite the official specifications/agencies directly.
6 Security A / 6.1.1: Extracting Training Data from Large Language Models — Real and canonical, but not kept in the trimmed set because the scalable 2023 production-language-model extraction paper now covers the stronger current attack-existence claim. Use only if a historical first-demonstration citation is needed.
6 Security A / 6.1.1: Deduplicating Training Data Makes Language Models Better — Real and directly supports the ten-times-less-memorized-text result, but it overlaps with the more privacy-focused Kandpal/Wallace/Raffel deduplication paper; keep Kandpal for this topic unless the exact ACL 2022 dataset-quality result is needed.
6 Security A / 6.2.1: Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models — Real and useful for model-weight security, but for the hardware-mechanisms topic it is a policy/security recommendation rather than direct accelerator/attestation architecture evidence. Kept under 6.3.1 instead.
6 Security A / 6.2.1: Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT) — The Caliptra specification is real and clickable, but it is a specification/project source rather than a research paper. Use it as a non-paper/source-of-truth for Caliptra capabilities, not as paper evidence for deployed AI accelerator governance.
6 Security A / 6.2.1: Unleashing OpenTitan's Potential: a Silicon-Ready Embedded Secure Element for Root of Trust and Cryptographic Offloading — Real and clickable, but it supports OpenTitan root-of-trust/cryptographic-offload research, not AI accelerator confidential computing or governance-grade cluster assurance. Keep only for OpenTitan-specific technical background.
6 Security A / 6.2.1: Assessing the Performance of OpenTitan as Cryptographic Accelerator in Secure Open-Hardware System-on-Chips — Real and clickable, but weaker than the selected accelerator-TEE/confidential-computing papers for this topic; it is performance analysis of OpenTitan crypto offload, not AI/GPU governance deployment.
6 Security A / 6.2.2: Building a High-Performance, Programmable Secure Coprocessor — Real DOI and historically relevant secure-coprocessor background, but too old and indirect for the AI-accelerator anti-tamper claim. It does not address modern accelerator packaging, cooling, interconnect, or rack-scale deployment constraints.
6 Security A / 6.2.2: Unleashing OpenTitan's Potential: a Silicon-Ready Embedded Secure Element for Root of Trust and Cryptographic Offloading — Real, but a silicon root of trust is not a physical anti-tamper enclosure. The paper does not support AI accelerator package integrity, HBM/NVLink tamper evidence, or production GPU tamper response.
6 Security A / 6.2.2: Physical security protection based on non-deterministic configuration of integrated microelectronic security features — Likely real as an ICMC 2013 conference/talk source, but public access is weaker and mostly via ResearchGate/program evidence. It is optional background and not needed because the TCHES secure-enclosure paper is stronger and cleaner.
6 Security A / 6.2.3: BIS licensing, due-diligence, and May/June 2026 guidance claims — These are regulatory claims, not paper claims. Cite BIS guidance, FAQ, EAR/Federal Register text, and official agency materials directly.
6 Security A / 6.3.1: Anthropic ASL safeguards and MITRE ATLAS model-theft taxonomy — Both are important but non-paper primary sources: Anthropic is company policy/safeguard text and MITRE ATLAS is a living threat matrix. They should not be cited as papers or as independent audits proving model theft defenses are deployed.
6 Security B / 6.3.2: SecureNN: 3-Party Secure Computation for Neural Network Training — Real and clickable, but too weakly connected for the retained paper map. It supports privacy-preserving neural-network training/inference primitives, not shared model governance or independent co-authorization of model operations.
6 Security B / 6.3.2: FALCON: Honest-Majority Maliciously Secure Framework for Private Deep Learning — Real and clickable, but redundant/indirect for this topic. It supports SMPC performance progress for private deep learning, not shared model governance deployment or co-authorized frontier-model operations.
6 Security B / 6.3.2: Crossing Shifted Moats: Replacing Old Bridges with New Tunnels to Confidential Containers — Real CCS 2024 paper, but only adjacent infrastructure/security analysis for Confidential Containers. It does not directly support shared model governance and should not be used as evidence for NVIDIA-style confidential AI key-release architectures.
6 Security B / 6.3.2: Security Verification of the OpenTitan Hardware Root of Trust — Real IEEE Security & Privacy article, but it supports hardware root-of-trust verification rather than shared model governance. Keep OpenTitan details as non-paper/spec documentation if needed.
6 Security B / 6.3.3: Open Problems in Technical AI Governance — Real source paper, but not needed among the strongest 2-5 papers for this topic once direct disgorgement/unlearning definition, benchmark, method, and evaluation papers are retained.
6 Security B / 6.3.3: Machine Unlearning: A Comprehensive Survey — Real and useful as a survey, but weaker than the retained primary papers for the map's concrete advances. Use only if the draft specifically needs a broad taxonomy of exact/approximate, verification, federated, graph, and privacy/security unlearning.
6 Security B / 6.4.1: MoJE: Mixture of Jailbreak Experts, Naive Tabular Classifiers as Guard for Prompt Attacks — Real, but redundant and weaker than the retained prompt-injection/jailbreak detector papers. Its reported 90% detection result should not be generalized to robust adversarial attack detection.
6 Security B / 6.4.1: Universal and Transferable Adversarial Attacks on Aligned Language Models — Real and important for jailbreak robustness limits, but not itself a detection or guardrail-detector paper. For this topic, Hackett et al. is more directly tied to detector/guardrail evasion.
6 Security B / 6.4.1: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations — Real NIST technical report, but not a research paper showing detection progress and not needed for the strongest paper set. Use it as standards/taxonomy context only if the paper map explicitly needs NIST terminology.
6 Security B / 6.4.2: OpenAI fine-tuning moderation / Moderation API screening claims — Not a paper and not model-intrinsic modification resistance. Source to OpenAI product/platform documentation if used.
6 Security B / 6.4.2: MITRE ATLAS model-modification threat taxonomy claims — Not a paper and not evidence that modification-resistant defenses work. Source to MITRE ATLAS if operational threat-taxonomy context is needed.
6 Security B / 6.4.3: OpenAI Trusted Access for Cyber, OpenAI Cybersecurity Grant Program, Anthropic ASL-3 deployment/access-control details, NIST AI 600-1, OWASP LLM Top 10 — These are provider program, policy, standards, or practitioner-taxonomy sources, not papers. They may be relevant non-paper evidence but should not be mixed into the paper-backed claim set.