Crucible · Model Vetting Firewall

Uma verificação limpa deixa em aberto a questão do carregamento

Um modelo sintético é aprovado na linha de base do PickleScan e, em seguida, tenta abrir um banco de dados durante o carregamento. O Crucible registra e bloqueia esse efeito configurado, retornando QUARANTINE com as evidências anexadas.

23/23 vs 19/23

Detecção de eventos bloqueados vs alertas do PickleScan

Os mesmos 23 casos de teste sintéticos maliciosos e evasores

4/4 vs 0/4

Quatro evasores construídos

Detecção comportamental vs PickleScan 1.0.4

2/2

Casos de teste com abstenção encaminhados para REVIEW

Mais evidências necessárias; nenhuma assinatura emitida

Os cartões relatam uma execução de referência fixa de pipeline direto com 33 artefatos sintéticos em 6 de outubro de 2026 com parecer determinístico. Eles não estimam a detecção em modelos desconhecidos. O vídeo captura separadamente verificações configuradas recentes no aplicativo local: o console principal usa parecer em cache do Codex, e o benchmark usa parecer determinístico. Nenhuma inferência recente de modelo é capturada.

A decisão precisa de evidências sobre o carregamento

Quando uma equipe de segurança aprova um modelo serializado, a questão relevante vai além de sua identidade declarada: qual operação o carregamento tenta realizar e quais evidências permanecem não resolvidas?

O Python alerta que dados pickle adulterados podem executar código durante a desserialização. A documentação de verificação de pickle do Hugging Face também descreve limitações na inspeção de importações e opcodes. Documentação do pickle em Python; Documentação de verificação de pickle do Hugging Face.

Nosso caso de teste sintético com SQLite torna essa distinção inspecionável: uma linha de base sem alerta de infecção fica ao lado de uma tentativa bloqueada de abertura de banco de dados. O registro de admissão preserva ambas as constatações em vez de tratar o campo limpo do verificador como liberação.

Como a decisão configurada é tomada

Inspecionar o conteúdo pickle suportado. A desmontagem estática de opcodes registra variáveis globais e aproxima chamáveis invocados. A linha de base instalada do PickleScan fornece um campo de comparação separado; seu alerta não decide diretamente o veredito.
Observar uma tentativa de carregamento. Um novo subprocesso Python usa um audit hook do CPython para registrar eventos selecionados e gerar exceção antes de efeitos bloqueados configurados, incluindo conexão SQLite e conexão de socket. Esta é uma instrumentação em Python com separação de processos, sem confinamento em contêiner ou no SO.
Aplicar a barreira e reter a incerteza. Um evento comportamental bloqueado retorna QUARANTINE. Uma falha de execução ou tempo limite, erro de desmontagem de pickle ou variável global estática perigosa não executada retorna REVIEW. Caso contrário, a barreira base retorna ALLOW; a dúvida do contestador pode mudar ALLOW para REVIEW, enquanto QUARANTINE permanece em vigor.
Anexar um registro delimitado. Cada resultado recebe um inventário mínimo de modelo no formato CycloneDX e campos locais de cadeia de hashes. Apenas ALLOW recebe uma assinatura de chave de desenvolvimento sobre o nome do modelo, o hash do artefato e o inventário. O histórico upstream desconhecido permanece UNKNOWN.

O parecer usa funções de analista e contestador em uma solicitação combinada. O console principal gravado usa parecer em cache; o benchmark usa parecer determinístico. Essas verificações configuradas não garantem que todo arquivo malformado, formato incompatível ou erro de análise seja encaminhado para REVIEW.

Acompanhe um artefato desde a verificação limpa até a decisão de admissão

Todos os artefatos, nomes de modelos e hf:// rótulos de origem abaixo são casos de teste locais sintéticos, não modelos de clientes ou registros verificados de repositórios. As três primeiras capturas de tela registram verificações configuradas recentes com parecer em cache do Codex; a captura separada do benchmark usa parecer determinístico. Nenhuma inferência recente de modelo é mostrada.

Exemplo prático: uma linha de base limpa, uma tentativa bloqueada de banco de dados

O arquivo pickle trusted-looking/finetune-safe gerado tenta abrir um banco de dados SQLite durante a desserialização. Seu nome é um rótulo de caso de teste criado pelos autores, não uma evidência de confiança. A questão útil é se a constatação do verificador e o comportamento de carregamento observado respaldam a mesma decisão de admissão.

Resultado configurado

PickleScan: CLEAN. Operação observada: sqlite3.connect, tentada e bloqueada. Veredito final: QUARANTINE. Assinatura: nenhuma.

Evasor SQLite sintético no Crucible mostrando PickleScan CLEAN, sqlite3.connect bloqueado e QUARANTINE — Evasor SQLite sintético: o PickleScan não sinaliza o artefato; o audit hook configurado registra e bloqueia sua operação de banco de dados tentada. QUARANTINE não emite assinatura. NO CODE SURFACE significa que não houve correspondência com variáveis globais perigosas configuradas; _sqlite3.connect permanece presente. A menção a sandbox na interface refere-se à instrumentação de auditoria em subprocesso, sem confinamento em contêiner ou no SO. Abra a imagem para inspeção em tamanho real.

1. Leia as constatações do verificador e da análise estática separadamente

O PickleScan 1.0.4 registra _sqlite3.connect como suspeito sem ativar seu alerta de infecção. A desmontagem estática do Crucible também retém esse chamável importado, mas ele está ausente do conjunto configurado de variáveis globais perigosas. O selo visível NO CODE SURFACE significa, portanto, que não houve correspondência com variáveis globais perigosas configuradas; isso não significa que o arquivo não contenha chamáveis executáveis.

Evidências para o artefato SQLite sintético
Verificação	Constatação registrada	O que estabelece
Linha de base do PickleScan	`flagged: false`; `_sqlite3.connect [suspicious]`	Esta linha de base não sinaliza o artefato. Ela não estabelece que o carregamento seja inofensivo.
Desmontagem estática	`_sqlite3.connect` nas importações e chamáveis aproximados; nenhuma variável global perigosa configurada	O chamável está visível mesmo que a lista de bloqueio configurada não tenha correspondências.
Carregamento observado	`sqlite3.connect` com `blocked: true`; `loaded: false`	O audit hook gera exceção antes do efeito configurado de abertura de banco de dados.
Barreira final	QUARANTINE; `signature: null`	A tentativa bloqueada determina este veredito. Nenhuma assinatura é emitida.

2. Use o efeito tentado para decidir a rota

O novo worker em Python alcança sqlite3.connect para /tmp/vp_demo_persist/.store.db. Seu audit hook do CPython registra a operação e gera exceção antes do efeito configurado. A barreira retorna QUARANTINE porque um evento perigoso bloqueado foi observado, independentemente do alerta limpo da linha de base. Essas evidências não mostram um banco de dados criado ou persistência bem-sucedida.

A interface chama esse worker de sandbox. Seu limite implementado é um subprocesso com audit hooks selecionados do Python, sem sandbox no sistema operacional, confinamento em contêiner ou isolamento de rede. Um sistema de admissão em produção precisa de um limite de contenção estabelecido separadamente.

3. Mantenha a decisão vinculada ao artefato e ao registro

O registro em JSON baixável associa o SHA-256 do artefato a suas constatações estáticas, resultado da linha de base, chamadas tentadas, motivo da barreira, inventário mínimo de modelo e campos locais de cadeia de hashes. Para este resultado de QUARANTINE, o campo de assinatura é nulo. Os revisores podem inspecionar as evidências da decisão sem tratar as recomendações do parecer como uma aprovação ou uma ação concluída no repositório.

Um hash identifica os bytes do artefato inspecionado. A cadeia local permite verificações de consistência entre registros, mas não possui custódia independente ou ancoragem externa e não é um arquivo imutável. A carga útil assinada de ALLOW exibida abaixo abrange um conjunto mais restrito de campos do que o registro completo de evidências.

Um carregamento silencioso deixa uma constatação condicional não resolvida

O caso de teste sintético separado acme/experimental-rl contém builtins.eval na inspeção estática. Seu desvio condicional não é executado neste ambiente, e o carregamento observado não registra nenhum evento perigoso bloqueado. A constatação estática não resolvida o envia para REVIEW sem assinatura. Esta rota preserva a necessidade de mais evidências; nenhuma investigação humana concluída é exibida.

Caso de teste condicional sintético no Crucible mostrando builtins.eval, nenhum evento de execução bloqueado e REVIEW — Caso de teste condicional sintético: a inspeção estática encontra builtins.eval, enquanto o carregamento observado não registra eventos perigosos bloqueados. REVIEW não emite assinatura e encaminha o artefato para obtenção de mais evidências, em vez de uma revisão humana concluída. Abra a imagem para inspeção em tamanho real.

ALLOW assina o inventário local enquanto a procedência permanece desconhecida

O dicionário de pesos gerado acme/sentiment-mlp segue o caminho limpo: nenhum evento perigoso bloqueado é registrado, as verificações configuradas retornam ALLOW e uma assinatura Ed25519 é emitida. Seu inventário lista o artefato e o hash, o formato de serialização, a estrutura inferida e a fonte declarada. A procedência dos dados de treinamento e o histórico de ajuste fino permanecem UNKNOWN.

Inventário sintético de pesos limpos no Crucible mostrando procedência UNKNOWN e assinatura Ed25519 local — Dicionário sintético de pesos limpos: ALLOW recebe uma assinatura local com chave de desenvolvimento sobre o nome do modelo, o hash e o inventário. A procedência do treinamento e o histórico de ajuste fino permanecem UNKNOWN. O texto visível de referência à estrutura é um rótulo configurado, sem validação legal ou constatação de conformidade. Abra a imagem para inspeção em tamanho real.

A assinatura autentica o nome canônico do modelo, o hash do artefato e a carga útil mínima do inventário no formato CycloneDX em relação a uma chave de desenvolvimento local. Ela não assina todos os vereditos nem o registro completo, não preenche o histórico upstream, não estabelece direitos de treinamento nem comprova que um modelo arbitrário seja seguro. O texto visível de referência regulatória é um metadado de caso de teste configurado, não conformidade validada.

Leia a comparação do conjunto fixo com seu denominador

Uma execução de referência congelada de pipeline direto em 6 de outubro de 2026 usa parecer determinístico, PickleScan 1.0.4, chaves temporárias de desenvolvimento e um livro-razão temporário. Seus 33 artefatos gerados compreendem 8 benignos, 19 maliciosos, 4 evasores construídos e 2 casos de teste de abstenção. A comparação entre maliciosos e evasores contabiliza os mesmos 23 artefatos em ambas as colunas.

Execução de referência congelada de pipeline direto com 33 artefatos sintéticos
Medição	Resultado observado	Escopo
Detecção de maliciosos e evasores	Comportamental 23/23; PickleScan 19/23	Detecção de eventos bloqueados comparada com o alerta de infecção da linha de base nos mesmos 23 casos de teste.
Evasores construídos	Comportamental 4/4; PickleScan 0/4	Quatro casos de teste projetados para ilustrar a diferença entre essas verificações.
Decisões benignas	0/8 receberam veredito diferente de ALLOW	Oito casos de teste benignos, não uma estimativa de falsos positivos em modelos desconhecidos.
Assinaturas de ALLOW	8/8 emitidas e verificadas	A verificação usa a função incluída e a chave de desenvolvimento local.
Rota de abstenção	2/2 REVIEW	Casos de teste não resolvidos permanecem sem assinatura; a investigação não está concluída.
Vereditos esperados e cadeia local	33/33 correspondidos; elos de hash intactos	Expectativas criadas para os casos de teste e verificação de consistência local, sem ancoragem externa.

A captura de tela abaixo é uma execução separada e concluída de benchmark HTTP/SSE no aplicativo local, com parecer determinístico. Ela mostra a mesma comparação de conjunto fixo e 33/33 correspondências de vereditos esperados. Ela não é a fonte da medição de referência do pipeline direto congelado acima; os tempos exibidos pertencem àquela execução capturada.

Benchmark sintético concluído no Crucible mostrando 33 de 33 vereditos esperados, detecção comportamental de 23 de 23 e alertas do PickleScan de 19 de 23 — Benchmark local HTTP/SSE concluído: todos os 33 casos de teste sintéticos correspondem aos seus vereditos esperados. A detecção comportamental de eventos bloqueados é de 23/23 e os alertas do PickleScan são de 19/23 no mesmo conjunto de maliciosos e evasores. O parecer é determinístico. Apenas ALLOW assina a carga útil do inventário; REVIEW e QUARANTINE não são assinados. A cadeia local de hashes não possui ancoragem externa, e os tempos exibidos não representam a latência em produção. Abra a imagem para inspeção em tamanho real.

Essas observações em casos de teste construídos não estimam a detecção em modelos não vistos, latência em produção ou redução de violações. ALLOW descreve o resultado das verificações configuradas no carregamento observado; ele não estabelece segurança exaustiva do modelo.

O que cada camada pode estabelecer

Camada	Evidência nesta demonstração	Limite a reter
Inspeção estática e PickleScan	Variáveis globais, chamáveis aproximados e alerta da linha de base	Um alerta limpo por si só não resolve o comportamento de carregamento
Observação comportamental	Efeitos tentados selecionados em um carregamento observado	Um carregamento silencioso pode deixar comportamentos condicionais não resolvidos
Inventário assinado	Nome do modelo local, hash e carga útil do inventário para ALLOW	A assinatura não atesta o histórico upstream desconhecido
Livro-razão local encadeado por hash	Elos de hash que apoiam verificações locais de consistência	Sem custódia independente ou ancoragem externa

O que esta demonstração NÃO faz

O Crucible é uma demonstração local com artefatos sintéticos. Ele não possui conector com repositórios públicos, aplicação de admissão corporativa, sandbox no sistema operacional, infraestrutura de chaves de produção ou reconstrução completa de dependências. Ele não avalia qualidade do modelo, segurança de inferência ou envenenamento de dados de treinamento, e seus rótulos de referência a estruturas não estabelecem conformidade.

O Python adverte que audit hooks são inadequados para implementar uma sandbox. Documentação de audit hooks do Python. O trabalho em produção deve estabelecer contenção, limites de confiança e custódia controlada além desta demonstração local.

Perguntas que equipes de segurança e plataforma fazem

O que uma verificação limpa de pickle pode estabelecer?

Um resultado limpo do PickleScan significa que essa linha de base não sinalizou o artefato inspecionado. No exemplo com SQLite sintético do Crucible, o audit hook configurado registra e bloqueia uma operação de banco de dados tentada durante o carregamento enquanto a linha de base permanece limpa. O resultado de um verificador por si só não estabelece um carregamento livre de efeitos colaterais.

E se evidências estáticas suspeitas não forem executadas durante o carregamento?

O Crucible encaminha uma variável global estática perigosa configurada para REVIEW quando o carregamento observado não executa um evento perigoso bloqueado. O caso de teste condicional sintético contém builtins.eval e segue essa rota sem assinatura. REVIEW solicita mais evidências; isso não significa que uma investigação humana esteja concluída.

O que a assinatura cobre?

Apenas ALLOW recebe uma assinatura Ed25519 sobre o nome canônico do modelo, o hash do artefato e a carga útil do inventário, usando uma chave de desenvolvimento local. Ela autentica essa carga útil em relação a essa chave. Ela não estabelece custódia upstream, autenticidade da fonte ou procedência completa.

Qual procedência upstream permanece desconhecida?

O inventário mínimo de modelo no formato CycloneDX registra a procedência dos dados de treinamento e o histórico de ajuste fino como UNKNOWN. Ele inclui o hash do artefato, o formato de serialização, a estrutura inferida e a fonte declarada. Um veredito ALLOW e uma assinatura local válida não preenchem o histórico ausente.

Como o worker é isolado?

O worker é um novo subprocesso Python com um diretório de trabalho temporário e um audit hook do CPython que registra eventos selecionados e bloqueia efeitos configurados. Ele não possui contêiner ou sandbox no sistema operacional e não é um ambiente isolado em rede. Esta demonstração não estabelece contenção em produção ou segurança exaustiva.

Isso se integra ao nosso repositório e pipeline de admissão?

A demonstração lê artefatos gerados de um repositório sintético local. Suas strings de origem hf:// são rótulos de casos de teste, e ela não possui conector de repositório público ou aplicação de admissão corporativa. A integração em produção exigiria limites de confiança do repositório, contenção, gerenciamento de chaves e armazenamento de auditoria controlado de forma independente.