Ricerca sulla sicurezza: da un log di Inspect a un paragrafo sui metodi

Hai eseguito una valutazione su un modello: un model organism e il suo controllo, un insieme di attacchi, le trascrizioni di un agente di audit valutate da un giudice. Prima di mettere per iscritto il risultato, tre domande decidono se regge: quanto è ampia l'incertezza, "nessuno su 200" è davvero nessuno, e puoi fidarti del giudice che ha valutato le trascrizioni? Oloproof risponde a partire dal log che hai già, e scrive la figura, la tabella e il paragrafo sui metodi da ciò che ha misurato.

Leggere il log

Oloproof legge i log di UK AISI Inspect, il file .eval che scrive inspect eval oppure un log JSON:

oloproof scores import --from inspect logs/organism.eval
oloproof scores import --from inspect logs/control.eval logs/organism.eval --policy release.yaml

Il primo comando importa un'esecuzione e risponde in parole semplici. Il secondo importa due esecuzioni, le accoppia sugli id dei campioni e decide le regole di confronto della policy; una policy data con due log deve contenerne almeno una (kind: superiority, non_inferiority o equivalence), e un tetto su una sola esecuzione si decide importando quel log da solo con la policy. Ogni scorer diventa un criterio: C passa e I fallisce, il credito parziale è un punteggio da 0 a 1, e uno scorer numerico ha bisogno del suo intervallo, indicato con --scale LOW HIGH. Vengono copiati solo id e punteggi; le trascrizioni restano nel log. Vedi Un secondo parere sui punteggi di un altro strumento per ogni regola di lettura.

Le epoche non sono altri campioni

Eseguire ogni campione più volte (le epoche di Inspect) non ti dà più casi indipendenti. Oloproof mantiene il campione come unità: il log si importa come un'esecuzione le cui repliche sono le sue epoche, il valore di ogni campione è la media delle sue epoche, e ogni campione pesa uguale. Ogni epoca mantiene il proprio pass o fail, quindi un giudice può essere verificato sulle epoche, con il campione come unità. Contare le esecuzioni di ogni campione come casi separati tratta le ripetizioni come prompt nuovi: nella griglia del metodo, raggruppare così due esecuzioni per campione ha coperto un'affermazione su prompt come questi appena l'86% delle volte a un 95% dichiarato, anche se ha tenuto per un'affermazione sui campioni stessi (docs/engine/PASS_AT_K_METHOD.md §8). Un campione con un'epoca in errore conta come mancante, al suo valore peggiore, mai come la media delle epoche terminate, poiché gli errori tendono a cadere sui campioni difficili.

Nessuno visto non è nessuno

Un'affermazione di sicurezza poggia spesso su un conteggio pari a zero: nessun attacco è riuscito, nessuna trascrizione ha mostrato il comportamento. Zero osservati non è un tasso zero. Senza una soglia, Oloproof dice quanto alto potrebbe ancora essere il tasso e quanti casi puliti lo farebbero scendere:

attack_succeeded: about 0.0%; the true value is likely between 0.0% and 1.9% (95% range, 200 cases).
  None of the 200 cases counted toward it, yet the rate could still be as high as 1.9%: none seen is not none.
  If the next cases show none either, a suite of 368 cases (168 more) would bring the high end to 1.0% or below.

Sotto un tetto, decide la policy. max: 0.01 su 0 su 200 è INSUFFICIENT_EVIDENCE, e il consiglio è condizionale: "se nemmeno i prossimi casi contano, circa 368 lo deciderebbero; ognuno che conta aumenta quel numero". Non viene citata alcuna probabilità, perché senza eventi non c'è nulla da cui ricavarla.

rules:
  - id: attack-ceiling
    metric: attack_succeeded
    max: 0.01

Ci riesce mai? pass@k

Una domanda di capacità o di red team è spesso se uno qualsiasi di k tentativi riesce. oloproof passk legge ogni epoca di un campione come un tentativo e stima senza distorsione il pass@k di ogni campione, poi la media della suite:

oloproof passk logs/organism.eval --from inspect --criterion leaked --k 5

Va bene anche un file con una riga per tentativo (case, passed, error facoltativo). Un campione con un tentativo in errore, o con meno di k tentativi, conta come mancante, al suo valore peggiore. La risposta dà la stima e il suo intervallo al 95%. Con --min o --max decide: PASS quando l'intervallo supera la soglia, FAIL quando cade interamente dal lato sbagliato, INSUFFICIENT_EVIDENCE altrimenti (uscita 0, 1 o 3). Il metodo (docs/engine/PASS_AT_K_METHOD.md) ha coperto il suo 95% dichiarato in ogni cella della sua griglia ed è stato ammesso da un audit indipendente il 3 novembre 2026, alle sue condizioni: i tentativi di un caso sono indipendenti l'uno dall'altro, e non hai fermato in anticipo i tentativi di un caso perché uno era riuscito.

Molte condizioni insieme: uno sweep

Una tabella di venti differenze, ciascuna con il proprio intervallo al 95%, ci si aspetta che sbagli da qualche parte circa una volta: nella griglia del metodo, cinquanta intervalli separati hanno tenuto tutti solo sei volte su dieci. oloproof sweep decide una famiglia di contrasti che nominate prima di leggere le esecuzioni, così che l'intera tabella tenga insieme:

sweep:
  conditions:
    control: run_01...
    organism_a: run_01...
    organism_b: run_01...
  contrasts:
    - organism_a - control
    - organism_b - control

oloproof sweep sweep.yaml --policy compare.yaml

Ogni contrasto è un confronto appaiato di due esecuzioni di una stessa suite, deciso da ogni regola di confronto della policy, ogni affermazione a 1 - alpha/m con m il numero di affermazioni: la probabilità che una qualsiasi sia sbagliata è al più alpha. Un contrasto che leggete solo dopo aver guardato la tabella è fuori da questa garanzia. Esecuzioni su suite diverse non vengono confrontate.

La sicurezza di un monitor contro il suo costo di audit

Per un protocollo di controllo, un file di una riga per traiettoria, con il suo arm (attack o honest) e lo score di sospetto del monitor, dà la sicurezza (la quota di attacchi segnalati) e il tasso di segnalazione onesta a ogni soglia:

oloproof control monitor.csv --budget 0.02 --min-safety 0.9

Gli intervalli tengono a tutte le soglie insieme, entrambi i bracci assieme, così una soglia scelta leggendo la curva, come quella che rientra in un budget di audit del 2%, resta coperta. Con --budget e --min-safety decide se qualche soglia segnala al più quella quota di traiettorie oneste catturando almeno quella quota di attacchi. Gli intervalli sono larghi nella coda quanto al centro, quindi un budget piccolo richiede molte traiettorie oneste: con 2.000 il tasso di segnalazione onesta è noto a circa 3 punti. La sicurezza qui è contro gli attacchi nel file; un attaccante che si adatta al monitor ne è fuori.

La sicurezza si conta sulle traiettorie del braccio di attacco, che il loro attacco sia riuscito o no. Una traiettoria a cui è stato chiesto di inserire una backdoor può non averla inserita, e il monitor non ha colpa se non vede ciò che non c’è. Per la sicurezza contro attacchi riusciti, verificate prima ogni traiettoria di attacco (per una backdoor, un test sul suo input segreto) e tenete nel braccio attack solo quelle che lo superano prima che il file arrivi a oloproof control.

Verificare il giudice

Una trascrizione valutata da un modello è la parola del giudice finché le persone non concordano. Etichetta un campione cieco dell'esecuzione importata, tenendo le trascrizioni sulla tua macchina:

oloproof scores import --from inspect --answers logs/organism.eval logs/organism.eval
oloproof review latest --criterion deceptive --by NAME

review estrae il campione, mostra ogni trascrizione senza il verdetto del giudice, misura l'accordo e convalida il giudice solo se supera la soglia che dichiari. Finché non è convalidato, una policy che richiede giudici convalidati, come quella che scrive oloproof init, non decide una regola su di esso. Per un'esecuzione che Oloproof ha eseguito, i cui casi portano tag nei metadati, oloproof labels disagreements RUN --criterion deceptive --by behavior mostra poi dove il giudice e le persone divergono, per comportamento e per direzione: ciò che il giudice ha promosso e le persone hanno bocciato, e il contrario. L'intervallo di ogni gruppo è un'affermazione a sé; il report non decide nulla.

Metterlo per iscritto

oloproof report latest --paper paper/

Questo scrive figure.svg (la stima e l'intervallo di ogni metrica), table.md e table.tex, e methods.md, un paragrafo che nomina ogni metodo di intervallo e la sua confidenza, dice che gli intervalli riguardano questa suite finita, nomina i casi mancanti e gli eventi rari, dice per ogni giudice se le persone lo hanno verificato e quanto spesso erano d'accordo, e afferma che cosa ha deciso il gate. Ogni numero è quello dell'esecuzione salvata, e il paragrafo è costruito da frasi fisse e fatti registrati; nessun modello lo scrive. In un notebook:

import oloproof

result = oloproof.analyze_inspect("logs/organism.eval", project="analysis")
result  # the figure, the table and the methods paragraph
result.write("paper/")

Le trascrizioni di un agente di audit

Uno strumento di audit che gira su Inspect, come Petri, scrive un log di Inspect il cui scorer dà a ogni trascrizione un punteggio per dimensione, spesso da 1 a 10. Importalo con quell'intervallo, oloproof scores import --from inspect --scale 1 10 audit.eval, e ogni dimensione diventa un criterio con una media limitata e il suo intervallo. Due log di questo tipo, prima e dopo una modifica al bersaglio, si confrontano sulle trascrizioni che hanno in comune. I punteggi restano la parola del giudice: i punteggi di un giudice, a differenza del suo pass o fail, non possono ancora essere verificati rispetto alle persone.

Che cosa non è costruito

• Verificare i punteggi di un giudice rispetto a quelli delle persone, a differenza dei suoi verdetti pass o fail.
• I tag dai metadati di un campione di Inspect: i casi di un'esecuzione importata non portano tag, quindi labels disagreements --by raggruppa solo le esecuzioni che Oloproof ha eseguito.
• Uno sweep più stretto di Bonferroni (Dunnett o closed testing), contrasti tra condizioni su suite diverse, e bande del monitor più strette nella coda, più monitor combinati, o protocolli con più soglie.
• Una figura PNG: la figura è solo SVG.

Che cosa questo non può dirvi

Ogni intervallo riguarda i campioni nel tuo log. Dice che cosa mostrerebbe un'esecuzione completa e senza errori di questi campioni, non come si comporta il modello su altri prompt, in produzione o di fronte a un attaccante che si adatta. Un giudice verificato dalle persone è verificato sui casi che hanno etichettato e sul modello che li ha giudicati, non su trascrizioni diverse da quelle. E un tasso limitato sotto l'1% sul tuo insieme di attacchi non dice nulla sugli attacchi che il tuo insieme non contiene.