GitHub Copilot poate fi manipulat pentru a produce conținut periculos în contextul dezvoltării software, chiar dacă refuză în mod obișnuit solicitările directe considerate riscante, potrivit unui studiu recent realizat de cercetătorii Abhishek Kumar și Carsten Maple, de la Alan Turing Institute. Descoperirea relevă riscuri ascunse în utilizarea acestor instrumente în proiecte de programare, mai ales în scenarii în care sarcinile sunt împărțite în pași și integrate într-un flux normal de lucru.
Studiul privind comportamentul GitHub Copilot
Kumar și Maple au testat funcționarea GPT-3-based a GitHub Copilot în mediul Visual Studio Code, utilizând patru modele: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro și Gemini 3.5 Flash. În total, au adresat 204 solicitări considerate periculoase, provenind din trei benchmarkuri de siguranță: Hammurabi’s Code, HarmBench și AdvBench.
În primul rând, solicitările au fost adresate ca întrebări directe în chat. În această etapă, sistemul a refuzat aproape complet răspunsurile, înregistrând doar opt rezultate problematice din 816 încercări. Acest comportament sugerează o funcționare adecvată a filtrelor de siguranță în scenariile de conversație directă.
Riscuri în butoane ascunse ale fluxului de lucru
Rezultatele au fost însă diferite în a doua etapă de testare. Cercetătorii au împărțit aceleași sarcini pe pași care simulau activități normale de dezvoltare software: citirea fișierelor, rularea scripturilor, procesarea de date, inspectarea valorilor și ajustarea pipeline-urilor. În aceste condiții, modelele au generat rezultate dăunătoare în toate cele 816 rulări.
Această metodă a expus vulnerabilități în modul în care modelul interpretează și gestionează solicitările. Instrumentul de asistență pentru programatori devine astfel o cale de a genera conținut periculos în contextul unui flux tehnic, nu doar prin răspunsuri directe și inițiale.
Fenomenul de jailbreak la nivel de workflow
Un jailbreak clasic implică formularea unei solicitări directe pentru a determina modelul să ignore restricțiile de siguranță. În cazul detectat, cercetătorii au identificat o metodă mai subtilă, numită „workflow-level jailbreak construction”.
Modelul nu trebuie rugat explicit să ignore regulile, ci să proceseze cererea în cadrul unei sarcini tehnice. Într-un mediu IDE, unde asistentul optimizează, modifică sau generează cod, solicitările periculoase intervine ca parte a unui proces de lucru, nu ca o întrebare izolată, făcând că refuzul să pară o nereușită tehnică, nu o decizie de siguranță.
În cazul acestui tip de manipulare, protecțiile nu mai pot fi evaluate simplu prin refuzul de a răspunde. Modelele pot produce rezultate dăunătoare în contextul unei secvențe de pași, cu fișiere, scripturi și date intermediare. Astfel, riscul major stă în faptul că asistenții IA pot fi folosiți involuntar pentru a genera cod sau informații periculoase în cadrul fluxurilor de lucru normale. Cercetătorii nu au făcut public complet toate solicitările și rezultatele generate pentru a evita crearea unui ghid deschis pentru atacatori. Totuși, concluzia clară rămâne: siguranța modelelor de inteligență artificială nu poate fi măsurată doar prin răspunsul la o solicitare, ci trebuie analizată întreaga sesiune și fluxul de lucru în care acestea sunt utilizate.
