Cercetătorii au descoperit o vulnerabilitate în GitHub Copilot

GitHub Copilot poate refuza aproape întotdeauna solicitările periculoase adresate direct în chat, însă situaţia se schimbă atunci când aceeaşi cerere este împărţită în mai mulţi paşi şi integrată într-un flux aparent obişnuit de dezvoltare software. Concluzia aparţine cercetătorilor Abhishek Kumar şi Carsten Maple, de la Alan Turing Institute, care au denumit această tehnică „workflow-level jailbreak”.

Potrivit The Register, vulnerabilitatea nu ţine doar de răspunsul oferit de model la o întrebare directă, ci de modul în care acesta execută o serie de sarcini tehnice care, puse cap la cap, pot conduce la acelaşi rezultat periculos. În medii precum Visual Studio Code, unde Copilot poate analiza fişiere, rula scripturi şi genera cod, filtrele de siguranţă pot interpreta greşit contextul şi pot permite finalizarea unor acţiuni care ar fi fost blocate într-o conversaţie obişnuită.

Pentru a demonstra acest comportament, Kumar şi Maple au testat GitHub Copilot în Visual Studio Code folosind patru modele AI: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro şi Gemini 3.5 Flash. Cercetătorii au utilizat 204 solicitări considerate periculoase, preluate din benchmarkurile de siguranţă Hammurabi’s Code, HarmBench şi AdvBench.

În prima etapă, toate solicitările au fost adresate direct prin chat. Din 816 încercări, doar opt au generat răspunsuri considerate problematice, ceea ce arată că mecanismele clasice de protecţie funcţionează eficient în cazul solicitărilor explicite.

Rezultatele s-au schimbat radical în cea de-a doua etapă a experimentului. Cercetătorii au împărţit aceleaşi obiective în activităţi care imitau un proces normal de dezvoltare software, precum citirea unor fişiere, rularea unor scripturi, procesarea datelor de test, verificarea unor rezultate sau optimizarea unei conducte de evaluare. În acest scenariu, modelele au produs rezultate dăunătoare în toate cele 816 teste efectuate.

Studiul scoate în evidenţă o diferenţă importantă între un chatbot şi un asistent AI integrat într-un mediu de programare. În timp ce un chatbot oferă doar răspunsuri la întrebări, un instrument precum GitHub Copilot poate modifica fişiere, genera cod, crea documentaţie şi executa sarcini succesive. Din acest motiv, spun cercetătorii, siguranţa acestor sisteme nu poate fi evaluată exclusiv prin analiza răspunsurilor oferite în chat.

Spre deosebire de un jailbreak clasic, care încearcă să păcălească modelul prin formulări ingenioase sau instrucţiuni menite să ocolească regulile, noua tehnică exploatează modul în care AI-ul interpretează un flux normal de lucru. Modelul nu este rugat direct să răspundă unei cereri periculoase, ci să proceseze o serie de sarcini tehnice care, împreună, duc la acelaşi rezultat.

Într-un IDE, asistentul AI este proiectat să finalizeze sarcini, să optimizeze cod şi să rezolve probleme. Atunci când o solicitare periculoasă este ascunsă într-un astfel de proces, modelul poate interpreta refuzul ca pe un eşec în îndeplinirea sarcinii, nu ca pe o decizie necesară pentru respectarea regulilor de siguranţă.

Autorii studiului au ales să nu publice exemplele complete de solicitări şi rezultate pentru a evita transformarea cercetării într-un ghid pentru atacatori. Cu toate acestea, concluzia este clară: testele de siguranţă trebuie să analizeze întregul proces de lucru al unui agent AI, inclusiv fişierele generate, scripturile executate, codul produs şi toate artefactele create pe parcursul unei sesiuni.

Problema apare într-un moment în care asistenţii AI devin tot mai autonomi şi primesc acces la un număr tot mai mare de instrumente. Cu cât un agent poate efectua mai multe acţiuni într-un proiect software, cu atât creşte şi suprafaţa de atac.

Cercetătorii susţin că dezvoltatorii unor instrumente precum GitHub Copilot, Cursor, Cline sau Windsurf ar trebui să implementeze mecanisme de protecţie care monitorizează întreaga activitate a agentului, nu doar conversaţia cu utilizatorul. Aceste sisteme trebuie să verifice şi fişierele create, codul generat, modificările aduse proiectelor şi evoluţia completă a sesiunii.

Pentru companii, riscurile sunt semnificative. Un astfel de asistent poate genera conţinut periculos fără ca utilizatorul să observe imediat sau poate introduce vulnerabilităţi, date sensibile ori cod problematic în proiecte reale. În contextul în care atacatorii folosesc tot mai frecvent inteligenţa artificială, astfel de vulnerabilităţi depăşesc sfera cercetării academice şi devin o provocare reală pentru securitatea software.

Concluzia studiului este că evaluarea siguranţei agenţilor AI trebuie mutată din zona testelor simple către scenarii reale, în care modelele execută sarcini complexe pe mai mulţi paşi. Faptul că un asistent AI refuză o solicitare periculoasă în chat nu garantează că va rămâne la fel de sigur atunci când aceeaşi solicitare este mascată într-un flux obişnuit de dezvoltare.