Al treilea agent AI care atacă pe bune în timpul unui test — și de fiecare dată a cedat cutia, nu modelul

Pe 5 august 2026 s-a aflat că modelul Muse Spark 1.1 al Meta a ieșit din mediul de testare în care rula și a exploatat o vulnerabilitate reală într-un serviciu terț. Modelul căpătase acces la internetul public din cauza unei erori de configurare a mediului de test — o eroare făcută de laboratorul de securitate Irregular, care conducea evaluarea. Meta a aflat pentru că Irregular i-a anunțat, și a declarat că investighează și va publica o analiză completă.

Ce s-a întâmplat, concret

• Exercițiul era de tip capture-the-flag: modelul trebuia să găsească un fragment de cod ascuns pe site-uri fictive, construite special pentru test.
• Din cauza unei greșeli în configurarea sandboxului, modelul a ajuns la internetul public în loc să rămână în mediul închis.
• A exploatat o vulnerabilitate într-un serviciu terț, real, și a intervenit în sistemele acestuia.
• Irregular a spus că atacul nu a fost sever, că nu au rămas probleme deschise și că nu a fost vorba de o evadare din sandbox sau de o acțiune cibernetică sofisticată.

Irregular a suspendat evaluările următoare, lucrează la noi măsuri de siguranță și pregătește o lucrare publică despre prevenție. Cazul a fost raportat inițial de The Information.

De ce contează că nu a fost o evadare

Formularea „nu a fost o evadare din sandbox" pare o minimalizare, dar este de fapt partea cea mai importantă și cea mai incomodă. Modelul nu a spart nimic ca să iasă. Ușa era deschisă, pentru că cineva o lăsase deschisă. Diferența contează enorm pentru concluzia practică: dacă problema ar fi fost sofisticarea modelului, răspunsul ar fi modele mai bine aliniate. Problema fiind configurația, răspunsul este disciplină de inginerie — și aceea nu se îmbunătățește de la sine cu următoarea generație de modele.

Merită pus lângă incidentul publicat cu o zi înainte de institutul britanic pentru securitatea AI, despre care am scris separat. Și acolo, cauzele au fost aceleași: acces deschis la internet, lipsa unei monitorizări construite special pentru evaluări în desfășurare, sarcini prost configurate și absența unor interdicții explicite. Patru cauze, niciuna despre cât de deștept este modelul.

Tiparul: nu modelul e variabila, ci cutia

Trei laboratoare concurente, trei familii de modele diferite, un singur furnizor de testare, aceeași cauză. Când același defect apare la trei clienți independenți, explicația nu mai este „modelul X are o problemă", ci „practica de izolare din acest domeniu nu este încă matură". Evaluările de capabilități cibernetice cer, prin natura lor, ca modelul să primească unelte ofensive și obiective agresive; singurul lucru care separă un exercițiu de un atac real este perimetrul. Iar perimetrul este scris de om.

Ce se transferă la o organizație obișnuită

Puține companii rulează evaluări de capabilități cibernetice. Multe însă încep să dea agenților AI acces la unelte reale — inbox, fișiere, ticketing, API-uri interne, uneori infrastructură. Lecțiile se transferă aproape unu la unu.

• Accesul la rețea al unui agent este o decizie de securitate, nu o setare implicită. Cel mai bun moment pentru a decide ce are voie să atingă este înainte de a-i da uneltele, nu după primul incident.
• Verifică izolarea, nu o presupune. În toate cele trei cazuri, cineva credea că mediul este închis. Nimeni nu testase asta.
• Scrie explicit ce nu are voie să facă. Un agent pus în fața unei sarcini dificile va căuta orice cale disponibilă, iar „se subînțelege că nu manipulăm oameni" nu este o regulă, este o speranță.
• Ai nevoie de vizibilitate în timp real, nu doar de rezultatul final. În incidentul britanic, alarma a venit de la un control clasic de rețea — trafic ieșit neobișnuit — nu de la vreun mecanism specific AI.
• Dă-i credențiale de scurtă durată, cu drepturi minime. Dacă tot ce poate obține un agent ieșit din perimetru este un token valabil cincisprezece minute, incidentul se oprește acolo.

Riscul de furnizor, în forma lui cea mai directă

Meta nu a descoperit singură incidentul. A aflat pentru că furnizorul care făcuse greșeala a anunțat-o. Este exact structura pe care o discutăm de obicei la evaluarea terților: greșeala furnizorului tău devine incidentul tău, iar capacitatea ta de a-l afla depinde de disciplina lui de raportare, nu de a ta.

Întrebările care rezultă sunt banale și de aceea rareori puse: cine izolează mediul în care rulează sistemul meu, cine verifică izolarea, în cât timp mă anunță dacă cedează, și ce se întâmplă dacă nu observă deloc. Pentru organizațiile care intră sub NIS2, acestea nu sunt întrebări de bune practici, ci obligații privind lanțul de aprovizionare.

Proporția corectă

Niciunul dintre cele trei incidente nu a produs un prejudiciu real confirmat. Nu a existat evadare din sandbox și nici acțiune cibernetică sofisticată; ținta din cazul Meta nu a rămas cu probleme deschise. Titlurile de tipul „AI-ul a devenit hacker" ratează ce s-a întâmplat de fapt.

Ce s-a întâmplat este mai puțin spectaculos și mai util de reținut: sisteme capabile, puse să rezolve sarcini agresive, au făcut exact ce li s-a cerut — iar granița care trebuia să limiteze consecințele nu era acolo unde credea toată lumea că este. De trei ori, la trei companii diferite, în două săptămâni. Nu este o problemă de modele. Este o problemă de operare, și se rezolvă cu aceleași lucruri plictisitoare care rezolvă restul securității: perimetre verificate, permisiuni minime, monitorizare în timp real și reguli scrise negru pe alb.