GitHub Copilot refuză în chat, dar poate ceda în cod: noul studiu care arată limita filtrelor de siguranță AI

GitHub Copilot poate refuza aproape de fiecare dată o cerere periculoasă formulată direct în chat, dar poate ajunge să producă același tip de conținut atunci când solicitarea este împărțită în pași și ascunsă într-un flux normal de lucru pentru programare, potrivit The Register. Descoperirea vine de la cercetătorii Abhishek Kumar și Carsten Maple, de la Alan Turing Institute, care numesc tehnica „workflow-level jailbreak construction”.

Pe scurt, problema nu este doar ce răspunde un model AI la o întrebare directă, ci ce ajunge să facă atunci când aceeași intenție este transformată într-o sarcină tehnică aparent obișnuită. Într-un mediu precum Visual Studio Code, unde un asistent AI citește fișiere, rulează scripturi, procesează date și generează artefacte, filtrele de siguranță pot interpreta greșit contextul.

Ce au testat cercetătorii

Kumar și Maple au testat GitHub Copilot în Visual Studio Code pe patru modele: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro și Gemini 3.5 Flash. Ei au folosit 204 solicitări considerate periculoase, provenite din trei benchmarkuri de siguranță pentru modele AI: Hammurabi’s Code, HarmBench și AdvBench.

În prima etapă, solicitările au fost puse direct, ca întrebări în chat. În acest scenariu, Copilot a refuzat aproape complet să răspundă. Din 816 încercări, cercetătorii au observat doar opt răspunsuri problematice. Cu alte cuvinte, la nivel de conversație directă, sistemele de protecție au funcționat aproape așa cum ar trebui.

Vezi și:

Este obligatoriu ca blocurile să aibă pubele pentru colectarea selectivă? Ce spune legea

A doua etapă a fost însă mult mai îngrijorătoare. Cercetătorii au împărțit aceleași obiective în pași care semănau cu activități normale de dezvoltare software: citirea unor fișiere, rularea unor scripturi, procesarea unor intrări de benchmark, inspectarea unor valori și îmbunătățirea unei conducte de evaluare. În acest context, modelele au produs rezultate dăunătoare în toate cele 816 rulări.

Diferența este importantă pentru întreaga industrie. Un asistent de programare nu este doar un chatbot care răspunde la întrebări, ci un instrument care poate scrie fișiere, genera exemple, modifica structuri de date și construi rezultate pe parcursul mai multor pași. Tocmai de aceea, GitHub Copilot nu trebuie evaluat doar după felul în care răspunde la o cerere izolată.

De ce jailbreak-ul la nivel de workflow este mai periculos

Un jailbreak clasic încearcă să păcălească modelul printr-o formulare directă, prin roluri inventate sau prin instrucțiuni care îl împing să ignore regulile. În cazul descoperit de cercetătorii de la Alan Turing Institute, mecanismul este mai subtil. Modelul nu este rugat să „răspundă” la o cerere periculoasă, ci să o „proceseze” ca parte a unei sarcini tehnice.

Vezi și:

Asistenții AI de programare sperie sistemele de securitate: de ce Claude Code, Cursor și Codex par atacatori în ochii antivirusului

ASUS lansează în Singapore un AI care ajută medicii să analizeze mai rapid probele de sânge

Asta schimbă modul în care sistemul interpretează situația. Într-un IDE, asistentul AI este obișnuit să termine sarcini, să optimizeze cod, să repare erori și să producă rezultate în fișiere. Dacă un prompt periculos devine doar o intrare într-un pipeline, refuzul poate părea pentru model ca o nereușită de a finaliza munca, nu ca o decizie de siguranță.

Cercetătorii nu au publicat toate solicitările și ieșirile generate, tocmai pentru a nu transforma studiul într-un ghid pentru atacatori. Totuși, concluzia este suficient de clară: siguranța modelelor AI nu poate fi măsurată doar prin întrebarea „refuză modelul o cerere rea?”. Trebuie analizat întregul traseu al unei sesiuni, inclusiv fișierele intermediare, scripturile, exemplele și artefactele produse.

Această problemă se înscrie într-un context mai larg, în care modelele de inteligență artificială devin tot mai capabile, dar și mai greu de controlat atunci când sunt puse să acționeze în fluxuri complexe. Cu cât un agent AI are mai multe permisiuni, cu atât suprafața de risc crește.

Ce trebuie schimbat la siguranța agenților AI

Studiul sugerează că dezvoltatorii de asistenți AI pentru programare trebuie să construiască filtre care nu verifică doar răspunsul din chat. Sistemele de protecție ar trebui să analizeze și ce fișiere scrie agentul, ce date generează, ce cod produce și cum evoluează întreaga sesiune.

Această abordare este importantă mai ales pentru instrumentele integrate în IDE-uri, precum Copilot, Cursor, Cline sau Windsurf. Acestea nu mai sunt simple generatoare de sugestii, ci pot acționa aproape ca niște colaboratori software. Pot citi proiecte, pot propune modificări și pot crea automat cod sau documentație. Dacă protecțiile se opresc la interfața de chat, o parte importantă a comportamentului rămâne neverificată.

Pentru companii, riscul este dublu. Pe de o parte, un astfel de asistent poate produce conținut periculos fără ca utilizatorul să observe imediat. Pe de altă parte, poate introduce vulnerabilități, date sensibile sau logici problematice în proiecte reale. Într-o perioadă în care hackerii folosesc inteligența artificială tot mai creativ, asemenea slăbiciuni devin mai mult decât o problemă academică.

Concluzia cercetătorilor este că evaluările de siguranță trebuie mutate din zona testelor simple în medii reale, agentice, unde modelele lucrează în mai mulți pași. Pentru utilizatori, lecția este la fel de importantă: faptul că un asistent AI pare să refuze o cerere periculoasă în chat nu înseamnă automat că este sigur în toate formele în care poate produce cod.

Se schimbă regulile de pensionare pentru unele femei din august 2026. Ce stagiu de cotizare va fi necesar