Crucible · Pare-feu d'évaluation des modèles
Un modèle synthétique passe la référence PickleScan, puis tente d'ouvrir une base de données lors du chargement. Crucible enregistre et bloque cet effet configuré, renvoyant QUARANTINE avec les preuves jointes.
23/23 vs 19/23
Détection d'événements bloqués vs signalements PickleScan
Mêmes 23 fixtures synthétiques malveillantes et d'évasion
4/4 vs 0/4
Quatre variantes d'évasion construites
Détection comportementale vs PickleScan 1.0.4
2/2
Fixtures d'abstention orientées vers REVIEW
Preuves supplémentaires requises ; aucune signature émise
Les fiches rapportent une exécution de référence de pipeline direct synthétique figée de 33 artefacts le 6 octobre 2026 avec avis déterministe. Elles n'estiment pas la détection sur des modèles inconnus. La vidéo capture séparément de nouvelles vérifications configurées dans l'application locale : la console principale utilise l'avis Codex mis en cache, et le benchmark utilise l'avis déterministe. Aucune inférence de modèle nouvelle n'est capturée.
Lorsqu'une équipe de sécurité approuve un modèle sérialisé, la question pertinente s'étend au-delà de son identité déclarée : quelle opération le chargement tente-t-il, et quelles preuves demeurent non résolues ?
Python avertit que des données pickle forgées peuvent exécuter du code lors du dépicklage. La documentation de scan de pickle de Hugging Face décrit également les limites de l'inspection des imports et des opcodes. Documentation du pickle Python; Documentation de scan de pickle de Hugging Face.
Notre fixture SQLite synthétique rend cette distinction inspectable : une référence sans indicateur d'infection côtoie une tentative bloquée d'ouverture de base de données. Le registre d'admission préserve les deux constats au lieu de traiter le champ de scanner sain comme une autorisation.
Le service consultatif utilise les rôles d'analyste et de challenger dans une seule requête combinée. La console principale enregistrée utilise des avis mis en cache ; le benchmark utilise des avis déterministes. Ces vérifications configurées ne garantissent pas que chaque fichier malformé, format non pris en charge ou erreur d'analyse soit orienté vers REVIEW.
Tous les artefacts, noms de modèles et hf:// libellés de source ci-dessous sont des fixtures locales synthétiques, non des modèles clients ou des enregistrements de registre vérifiés. Les trois premières captures d'écran saisissent de nouvelles vérifications configurées avec avis Codex mis en cache ; la capture de benchmark distincte utilise un avis déterministe. Aucune inférence de modèle nouvelle n'est présentée.
Le fichier généré trusted-looking/finetune-safe pickle tente d'ouvrir une base de données SQLite lors de la désérialisation. Son nom est un libellé de fixture créé pour le test, non une preuve de confiance. La question utile est de savoir si le constat du scanner et le comportement de chargement observé corroborent la même décision d'admission.
Résultat configuré
PickleScan : CLEAN. Opération observée : sqlite3.connect, tentée et bloquée. Verdict final : QUARANTINE. Signature : aucune.

PickleScan 1.0.4 enregistre _sqlite3.connect comme suspect sans activer son indicateur d'infection. Le désassemblage statique de Crucible conserve également cet appelable importé, mais il est absent de l'ensemble de globales dangereuses configuré. Le badge visible NO CODE SURFACE signifie donc qu'aucune globale dangereuse configurée n'a été atteinte ; il ne signifie pas que le fichier ne contient aucun appelable exécutable.
| Vérification | Constat enregistré | Ce que cela établit |
|---|---|---|
| Référence PickleScan | flagged: false; _sqlite3.connect [suspicious] | Cette référence ne signale pas l'artefact. Elle n'établit pas un chargement inoffensif. |
| Désassemblage statique | _sqlite3.connect dans les imports et appelables approximés ; aucune globale dangereuse configurée | L'appelable est visible même si la liste de blocage configurée ne compte aucune correspondance. |
| Chargement observé | sqlite3.connect avec blocked: true; loaded: false | L'audit hook lève une exception avant l'effet d'ouverture de base de données configuré. |
| Porte finale | QUARANTINE; signature: null | La tentative bloquée détermine ce verdict. Aucune signature n'est émise. |
Le nouveau worker Python atteint sqlite3.connect pour /tmp/vp_demo_persist/.store.db. Son audit hook CPython enregistre l'opération et lève une exception avant l'effet configuré. La porte renvoie QUARANTINE car un événement dangereux bloqué a été observé, indépendamment de l'indicateur de référence sain. Cette preuve ne montre pas de base de données créée ni de persistance réussie.
L'interface utilisateur qualifie ce worker de bac à sable. Sa frontière mise en œuvre est un sous-processus doté d'audit hooks Python sélectionnés, sans bac à sable au niveau du système d'exploitation, confinement par conteneur ni isolation réseau. Un système d'admission en production nécessite une frontière de confinement établie séparément.
L'enregistrement JSON téléchargeable associe le SHA-256 de l'artefact à ses constats statiques, au résultat de référence, aux appels tentés, au motif de la porte, à l'inventaire minimal du modèle et aux champs locaux de chaîne de hachage. Pour ce résultat QUARANTINE, le champ de signature est null. Les réviseurs peuvent inspecter les preuves de décision sans traiter les recommandations consultatives comme une approbation ou une action de registre finalisée.
Un hash identifie les octets de l'artefact inspecté. La chaîne locale prend en charge les contrôles de cohérence entre enregistrements, mais elle ne dispose d'aucune garde indépendante ni d'ancrage externe et ne constitue pas une archive immuable. La charge utile ALLOW signée présentée ci-dessous couvre un ensemble de champs plus restreint que le registre de preuves complet.
L'artefact synthétique distinct acme/experimental-rl fixture contient builtins.eval en inspection statique. Sa branche conditionnelle n'est pas exécutée dans cet environnement, et le chargement observé n'enregistre aucun événement dangereux bloqué. Le constat statique non résolu l'oriente vers REVIEW sans signature. Ce routage préserve la nécessité de preuves supplémentaires ; aucune investigation humaine achevée n'est présentée.

Le fichier généré acme/sentiment-mlp dictionnaire de poids suit le chemin sain : aucun événement dangereux bloqué n'est enregistré, les vérifications configurées renvoient ALLOW et une signature Ed25519 est émise. Son inventaire mentionne l'artefact et le hash, le format de sérialisation, le framework déduit et la source déclarée. La provenance des données d'entraînement et l'historique d'ajustement fin demeurent UNKNOWN.

La signature authentifie le nom canonique du modèle, le hash de l'artefact et la charge utile minimale d'inventaire au format CycloneDX par rapport à une clé de développement locale. Elle ne signe pas chaque verdict ni l'intégralité du registre, ne complète pas l'historique amont, n'établit pas les droits d'entraînement et ne prouve pas qu'un modèle arbitraire est sûr. Le texte de référence réglementaire visible est une métadonnée de fixture configurée, non une conformité validée.
Une exécution de référence de pipeline direct figée le 6 octobre 2026 utilise un avis déterministe, PickleScan 1.0.4, des clés de développement temporaires et un registre temporaire. Ses 33 artefacts générés comprennent 8 fixtures bénignes, 19 malveillantes, 4 variantes d'évasion construites et 2 d'abstention. La comparaison malveillantes et d'évasion comptabilise les mêmes 23 artefacts dans les deux colonnes.
| Mesure | Résultat observé | Périmètre |
|---|---|---|
| Détection des malveillants et d'évasion | Comportementale 23/23 ; PickleScan 19/23 | Détection d'événements bloqués comparée à l'indicateur d'infection de référence sur les mêmes 23 fixtures. |
| Variantes d'évasion construites | Comportementale 4/4 ; PickleScan 0/4 | Quatre fixtures conçues pour illustrer la différence entre ces vérifications. |
| Décisions bénignes | 0/8 ayant reçu un verdict autre que ALLOW | Huit fixtures bénignes, non une estimation des faux positifs sur des modèles inconnus. |
| Signatures ALLOW | 8/8 émises et vérifiées | La vérification utilise la fonction incluse et la clé de développement locale. |
| Routage d'abstention | 2/2 REVIEW | Les fixtures non résolues restent non signées ; l'investigation n'est pas finalisée. |
| Verdicts attendus et chaîne locale | 33/33 correspondances ; liens de hachage intacts | Attentes de fixtures rédigées et contrôle de cohérence locale, sans ancrage externe. |
La capture d'écran ci-dessous est une exécution de benchmark HTTP/SSE achevée distincte dans l'application locale, avec avis déterministe. Elle montre la même comparaison sur ensemble figé et 33/33 correspondances de verdict attendues. Elle n'est pas la source de la mesure de référence de pipeline direct figée ci-dessus ; les durées affichées appartiennent à cette exécution capturée.

Ces observations sur fixtures construites n'estiment pas la détection sur des modèles inconnus, la latence de production ou la réduction des brèches. ALLOW décrit le résultat des vérifications configurées sur le chargement observé ; il n'établit pas une sécurité exhaustive du modèle.
| Couche | Preuves dans cette démonstration | Frontière à retenir |
|---|---|---|
| Inspection statique et PickleScan | Globales, appelables approximés et indicateur de référence | Un indicateur sain seul ne résout pas le comportement au chargement |
| Observation comportementale | Effets tentés sélectionnés sur un chargement observé | Un chargement silencieux peut laisser un comportement conditionnel non résolu |
| Inventaire signé | Nom de modèle local, hash et charge utile d'inventaire pour ALLOW | La signature n'atteste pas l'historique amont inconnu |
| Registre local à chaîne de hachage | Liens de hachage prenant en charge les contrôles de cohérence locale | Aucune garde indépendante ni ancrage externe |
Crucible est une démonstration locale sur des artefacts synthétiques. Elle ne comporte aucun connecteur de registre public, application d'admission en entreprise, bac à sable au niveau de l'OS, infrastructure de clés de production ou reconstruction complète des dépendances. Elle n'évalue pas la qualité du modèle, la sécurité de l'inférence ou l'empoisonnement des données d'entraînement, et ses libellés de référence de framework n'établissent pas la conformité.
Python avertit que les audit hooks ne conviennent pas pour implémenter un bac à sable. Documentation des audit hooks de Python. Les déploiements en production doivent établir le confinement, les frontières de confiance et une garde contrôlée au-delà de cette démonstration locale.
Un résultat PickleScan sain signifie que cette référence n'a pas signalé l'artefact inspecté. Dans l'exemple SQLite synthétique de Crucible, l'audit hook configuré enregistre et bloque une tentative d'opération de base de données lors du chargement tandis que la référence reste saine. Un résultat de scanner à lui seul n'établit pas un chargement exempt d'effets secondaires.
Crucible oriente une globale statique dangereuse configurée vers REVIEW lorsque le chargement observé n'exerce pas d'événement dangereux bloqué. La fixture conditionnelle synthétique contient builtins.eval et emprunte cette voie sans signature. REVIEW requiert des preuves supplémentaires ; cela ne signifie pas qu'une investigation humaine est achevée.
Seul ALLOW reçoit une signature Ed25519 sur le nom canonique du modèle, le hash de l'artefact et la charge utile d'inventaire, à l'aide d'une clé de développement locale. Elle authentifie cette charge utile par rapport à cette clé. Elle n'établit pas la garde en amont, l'authenticité de la source ou une provenance complète.
L'inventaire de modèle minimal au format CycloneDX enregistre la provenance des données d'entraînement et l'historique d'ajustement fin sous la mention UNKNOWN. Il comprend le hash de l'artefact, le format de sérialisation, le framework déduit et la source déclarée. Un verdict ALLOW et une signature locale valide ne complètent pas l'historique manquant.
Le worker est un nouveau sous-processus Python disposant d'un répertoire de travail temporaire et d'un audit hook CPython qui enregistre les événements sélectionnés et bloque les effets configurés. Il ne comporte aucun conteneur ni bac à sable de système d'exploitation et ne constitue pas un environnement isolé du réseau. Cette démonstration n'établit pas de confinement de production ni de sécurité exhaustive.
La démonstration lit les artefacts générés à partir d'un registre synthétique local. Ses chaînes sources hf:// sont des libellés de fixtures, et elle ne comporte aucun connecteur de registre public ni application d'admission en entreprise. Une intégration en production exigerait des frontières de confiance de registre, un confinement, une gestion des clés et un stockage d'audit contrôlé de manière indépendante.
Explorez les recherches associées pour un contexte plus large sur cette démonstration.
Solution complète
Découvrez la solution AI Supply Chain Security & Model Integrity →Échangez sur votre flux d'ingestion de modèles avec notre équipe.
Nous utilisons ces distinctions démontrées pour structurer une discussion d'évaluation ou d'implémentation autour de votre registre, de votre frontière de chargement et de vos exigences de preuves.