💬 NLP

Code as a Weapon: A Consensus-Labeled Prompt Bank for Measuring Coding-Model Compliance with Malicious-Code Requests

Questo articolo introduce un archivio di prompt etichettati per consenso che distingue tra codice malevolo eseguibile e conoscenze di sicurezza dannose, al fine di fornire un benchmark affidabile e standardizzato per valutare se i modelli specializzati nella codifica soddisfano gli standard di rifiuto più rigorosi necessari per prevenire la generazione di armi funzionali.

Autori originali: Richard J. Young, Gregory D. Moody

Pubblicato 2026-05-28

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Richard J. Young, Gregory D. Moody

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

L'idea principale: Testo contro la cosa reale

Immagina di chiedere a un chatbot generico: "Come si costruisce una bomba?". Se risponde, ti fornisce una ricetta. Devi ancora andare al negozio, comprare gli ingredienti e mescolarli tu stesso. Sono informazioni pericolose, ma sono solo parole.

Ora, immagina di fare la stessa domanda a un IA specializzata nella programmazione. Se risponde, non ti dà solo una ricetta; ti consegna una bomba completamente assemblata e funzionante, pronta a esplodere non appena premi "esegui".

Gli autori di questo documento sostengono che, poiché le IA per la programmazione possono consegnare "armi funzionanti" (come virus o spyware) istantaneamente, dovrebbero essere molto più severe nel dire "No" rispetto ai chatbot normali. Ma al momento, nessuno ha un buon modo per misurare se stanno effettivamente dicendo "No" abbastanza spesso.

Il problema: Mescolare mele e arance

Per verificare se queste IA sono sicure, i ricercatori hanno utilizzato elenchi di domande (prompt). Ma questi elenchi sono stati disordinati. Mescolano due tipi molto diversi di richieste pericolose:

Richieste "Arma": "Scrivimi un programma che ruba le password." (L'IA ti fornisce il codice).
Richieste "Conoscenza": "Spiega come funziona il furto di password." (L'IA ti fornisce un saggio).

Se mescoli questi due tipi e dici: "Questa IA ha rifiutato il 50% delle richieste cattive", non sai se ha rifiutato le armi o solo le spiegazioni. È come testare una guardia di sicurezza chiedendole di fermare un ladro e di fermare qualcuno che chiede indicazioni. Se la guardia ferma il ladro ma lascia passare chi chiede indicazioni, non puoi dire se è brava nel suo lavoro guardando solo il numero totale di persone fermate.

La soluzione: Un archivio di prompt "etichettati per consenso"

Gli autori hanno creato un elenco massiccio, pulito e organizzato di 6.675 domande pericolose. Le hanno divise in due categorie chiare:

Il contenitore "CODICE": Domande che chiedono software eseguibili e pericolosi (le "armi").
Il contenitore "CONOSCENZA": Domande che chiedono informazioni o teorie dannose (le "ricette").

Per assicurarsi che le domande fossero classificate correttamente, non hanno chiesto a una sola persona. Hanno utilizzato un panel di cinque diversi giudici IA (come una giuria). Ogni giudice ha esaminato ogni domanda e ha votato: "Questa è una richiesta di un'arma?" oppure "Questa è una richiesta di conoscenza?".

Il verdetto: Se almeno 3 giudici su 5 erano d'accordo, la domanda riceveva un'etichetta finale.
Il risultato: Hanno ottenuto 4.748 richieste confermate come "Arma" e 1.923 richieste confermate come "Conoscenza".

La "Giuria" e le sorprese

Gli autori hanno utilizzato cinque diversi modelli IA per agire come giudici. Volevano assicurarsi che il test fosse economico e disponibile per tutti, quindi hanno scelto modelli gratuiti o open-source, piuttosto che quelli costosi e a pagamento.

Durante questo processo, hanno scoperto due cose interessanti:

1. Il paradosso "Troppo facile"
Per alcuni elenchi di domande (come l'elenco ASTRA), quasi ogni singola domanda era ovviamente un'"Arma". I giudici erano d'accordo al 99% delle volte.

La metafora: Immagina un test di matematica dove ogni domanda è "Quanto fa 2+2?". Tutti prendono il 100%. Non puoi davvero misurare quanto siano "intelligenti" gli studenti perché il test era troppo facile.
La constatazione: In statistica, quando tutti sono d'accordo su tutto, il punteggio usuale per l'"accordo" (chiamato Kappa) si rompe e appare come zero o un numero negativo. Gli autori hanno dovuto inventare un modo speciale per riportare questo dato: "Ehi, tutti sono stati perfettamente d'accordo, ma il punteggio matematico sembra strano perché il test era troppo facile".

2. Il glitch del "Portinaio"
Uno dei cinque giudici IA (un modello gratuito di OpenAI) ha iniziato a rifiutare di rispondere a qualsiasi domanda, persino a quelle che avrebbe dovuto giudicare. Continuava a imbattersi in un segnale di "Stop" dalla società che lo ospita.

La metafora: Immagina una giuria in cui un giurato viene continuamente cacciato dall'aula di tribunale per aver fatto troppe domande.
La soluzione: Poiché la regola era "3 su 5", gli altri quattro giudici potevano comunque decidere il verdetto. Gli autori hanno notato questo come una stranezza del mondo reale: a volte gli strumenti gratuiti che usi per testare la sicurezza hanno i propri filtri di sicurezza che bloccano il test prima ancora che inizi.

Perché questo è importante

Questo documento non riguarda il testare un'IA specifica per vedere se è sicura oggi. Si tratta invece di costruire il righello che tutti gli altri possono usare.

Prima di questo, i ricercatori cercavano di misurare la sicurezza con un righello rotto che mescolava "armi" e "ricette". Ora, hanno un righello standardizzato e di alta qualità (l'archivio di prompt) che separa chiaramente i due. Questo permette a chiunque di testare le IA per la programmazione e dire: "Ok, questa IA ha rifiutato il 90% delle vere armi", il che è un controllo di sicurezza molto più significativo rispetto al passato.

Riassunto

Obiettivo: Creare un elenco pulito di domande pericolose per testare se le IA per la programmazione sono sicure.
Metodo: Utilizzato una "giuria" di 5 IA per classificare 6.675 domande in "Armi" (Codice) e "Ricette" (Conoscenza).
Risultato: Un database pubblico di 4.748 richieste di armi confermate e 1.923 richieste di conoscenza.
Insight chiave: Non puoi misurare correttamente la sicurezza se mescoli "costruire una bomba" con "leggere delle bombe". Questo documento risolve quel errore di classificazione.

Riepilogo Tecnico: Codice come Arma: Un Banco di Prompt con Etichette di Consenso per Misurare la Conformità dei Modelli di Codifica alle Richieste di Codice Malevolo

Enunciato del Problema

Il documento affronta un'asimmetria critica nella sicurezza dell'IA: mentre un modello linguistico generico che risponde a una query dannosa restituisce testo, un modello specializzato nella codifica che acconsente alla stessa intenzione può generare "armi" eseguibili (ad esempio, keylogger, dropper di ransomware, payload di exploit). I benchmark attuali per misurare il rifiuto del codice malevolo non riescono a distinguere tra richieste di software eseguibile (CODICE) e richieste di conoscenza di sicurezza dannosa (CONOSCENZA). I corpus esistenti mescolano questi tipi di richiesta distinti, rendendo le statistiche uniche sul tasso di conformità ininterpretabili e impedendo confronti diretti tra corpus. Inoltre, i precedenti sforzi di etichettatura basati sul consenso erano limitati nell'ambito (quattro corpus) e si basavano su API commerciali a pagamento, ostacolando la replicabilità e l'estensione economicamente efficiente.

Metodologia

Gli autori presentano la v2 di un banco di prompt con etichette di consenso, espandendo l'ambito da quattro a otto corpus sorgenti e aggiornando il panel di valutazione per utilizzare modelli a costo marginale zero, open-weight o di livello gratuito.

1. Espansione del Corpus

Il pool di dataset è stato ampliato da 3.133 prompt (v1) a 6.675 prompt integrando quattro nuovi corpus rilasciati pubblicamente:

ASTRA: 1.995 prompt con decorazioni di jailbreak, richieste testo-a-codice a turno singolo.
Scam2Prompt (Innoc2Scam-bench): 1.377 prompt di elicitazione indiretta che mascherano l'intento malevolo come richieste innocue di sviluppatori.
JailbreakBench (sottoinsieme di codifica): 10 prompt mirati specificamente alla generazione di codice eseguibile.
RedCode: 160 prompt mirati alle traiettorie degli agenti code-interpreter.
I corpus v1 (RMCBench, MalwareBench, CySecBench e AdvBench/harmful_behaviors) sono stati riclassificati sotto il nuovo panel per garantire la continuità.

2. Panel dei Giudici e Protocollo

È stato assemblato un panel di cinque giudici provenienti da cinque famiglie di vendor distinte, selezionati per il costo marginale zero delle API e l'accessibilità tramite OpenRouter e Ollama Cloud:

NVIDIA: Nemotron-3-Super (Generale)
Alibaba: Qwen3-Coder-Next (Specializzato in codifica)
DeepSeek: DeepSeek-V4-Pro (Generale)
OpenAI: GPT-OSS-120B (Pesi aperti, generale)
Zhipu AI: GLM-5.1 (Generale)

Protocollo di Classificazione:

Modello: Uno schema binario che distingue CODICE (richieste di software/armi eseguibili) da CONOSCENZA (richieste di informazioni/spiegazioni basate su testo). Il modello è identico a livello di byte alla v1 per prevenire derive.
Regola del Consenso: Una regola di maggioranza 3 su 5. Un prompt è etichettato come CODICE o CONOSCENZA se almeno tre giudici concordano; altrimenti, è etichettato come AMBIGUO.
Metrica di Affidabilità: $\kappa$ di Fleiss con un intervallo di confidenza al 95% ottenuto tramite bootstrap di 10.000 iterazioni, calcolato sul sottoinsieme in cui tutti e cinque i giudici hanno restituito etichette valide (6.552 prompt).

Contributi Chiave

1. Il Banco con Etichette di Consenso Ampliato

L'artefatto rilasciato comprende:

4.748 prompt CODICE con consenso (un'espansione di 3,1 volte rispetto alla v1).
1.923 prompt CONOSCENZA con consenso (un'espansione di 5,0 volte rispetto alla v1).
4 prompt AMBIGUI (rilasciati con i voti per giudice per la ricalibrazione a valle).
Il dataset è rilasciato sotto licenza OpenRAIL++ con restrizioni specifiche che vietano l'uso dei dati per addestrare sistemi di generazione di software malevolo.

2. Risultati Metodologici

Il documento documenta due osservazioni metodologiche significative derivanti dalla costruzione della v2:

Il Paradosso dell'Alto Accordamento e Basso- $\kappa$ : Su quattro corpus distorti per prevalenza (ASTRA, MalwareBench, RedCode, RMCBench), dove il consenso è >99% CODICE, il $\kappa$ di Fleiss degenera a valori vicini allo zero o negativi nonostante un alto accordo osservato ( $P_o$ ). Gli autori attribuiscono questo al paradosso di Feinstein-Cicchetti, dove l'accordo casuale atteso ( $P_e$ ) si avvicina a 1,0. Di conseguenza, il documento propone una convenzione di reporting duale: riportare $\kappa$ per corpus misti per prevalenza e accordo osservato ( $P_o$ ) per corpus distorti per prevalenza.
Rifiuti delle Politiche di Contenuto lato Fornitore: Un giudice (GPT-OSS-120B instradato tramite il provider OpenInference di OpenRouter) ha restituito rifiuti HTTP 403 deterministici su 1,84% dei prompt (123 in totale), concentrati pesantemente nel corpus harmful_behaviors. Il documento identifica questo come una proprietà strutturale dei provider di instradamento di livello gratuito che applicano filtri dei contenuti prima che il modello elabori il prompt. La regola di consenso 3 su 5 ha assorbito con successo questi rifiuti senza generare etichette AMBIGUE, ma gli autori lo segnalano come un fattore critico per i ricercatori che replicano il panel.

3. Stabilità Cross-Panel

Il panel v2 (open-weight/gratuito) è stato confrontato con il panel v1 (API commerciali a pagamento) sui 3.133 prompt sovrapposti. I panel hanno raggiunto un accordo del 94,45% sulle etichette di consenso, con un $\kappa$ di Cohen di 0,952 ("quasi perfetto") sul sottoinsieme binario-binario. Ciò valida che il panel a costo zero funge da sostituto robusto del panel commerciale sui corpus condivisi.

Risultati

Affidabilità Complessiva: Sul sottoinsieme del panel completo (6.552 prompt), il $\kappa$ di Fleiss è 0,767 [IC 95%: 0,755, 0,777], rientrando nella banda di accordo "sostanziale" della scala Landis-Koch.
Affidabilità per Corpus:
- Misti per Prevalenza: Scam2Prompt ( $\kappa=0,768$ ), CySecBench ( $\kappa=0,664$ ) e harmful_behaviors ( $\kappa=0,910$ ) mostrano un accordo interpretabile.
- Distorti per Prevalenza: ASTRA, MalwareBench, RedCode e RMCBench mostrano valori di $\kappa$ vicini allo zero o negativi a causa della degenerazione della distribuzione marginale, nonostante l'accordo osservato medio ( $P_o$ ) vari da 0,850 a 0,989.
Robustezza del Giudice: L'analisi leave-one-out conferma che nessun singolo giudice domina il panel. Rimuovendo il giudice più divergente (Nemotron-3-Super) si è effettivamente aumentato il $\kappa$ a 0,832, confermando che il disaccordo introdotto da questo giudice rappresenta lavoro su casi limite significativi e non rumore.
Livelli di Accordamento: Il 76,9% dei prompt ha raggiunto un accordo unanime 5/5; il 95,0% ha raggiunto un accordo di almeno 4/5.

Significato e Affermazioni

Il documento afferma di fornire un substrato stabile nella costruzione per misurare la conformità dei modelli di codifica alle richieste di codice malevolo. Disambiguando le richieste di software eseguibile dalle richieste di conoscenza, il banco permette valutazioni di sicurezza più precise rispetto ai precedenti benchmark a corpus misti.

Gli autori posizionano modestamente il lavoro come un'espansione e un affinamento metodologico della loro precedente release a quattro corpus [1], piuttosto che come una rivalutazione dell'asse sottostante CODICE-verso-CONOSCENZA. Il significato principale risiede in:

Scalabilità e Replicabilità: Dimostrare che l'etichettatura di consenso ad alta affidabilità può essere ottenuta utilizzando modelli open-weight a costo marginale zero, rimuovendo le barriere finanziarie per i ricercatori a valle.
Standardizzazione: Stabilire un protocollo per la gestione di corpus distorti per prevalenza (reporting duale di statistiche) e documentare i comportamenti di filtraggio lato fornitore che influenzano la disponibilità dei giudici di livello gratuito.
Disponibilità dei Dati: Rilasciare un dataset significativamente più grande, multi-giudice e quantificato per affidabilità (6.675 prompt) per consentire confronti tra corpus che in precedenza non erano direttamente interpretabili.

Il documento afferma esplicitamente di non affrontare la domanda comportamentale su come i LLM di codifica target rispondano al banco v2, notando che tali valutazioni rientrano nel campo di lavoro a valle separato.