Anthropic a găsit trei incidente reale în evaluări cyber AI: lecția critică este izolarea

Pe 30 iulie 2026, Anthropic a publicat analiza a trei incidente apărute în timpul unor evaluări de securitate cibernetică ale modelelor sale. În toate cazurile, mediul operat de un partener extern a avut acces la internet, deși evaluările fuseseră proiectate pe premisa opusă. Modelele au ajuns astfel să interacționeze cu sisteme reale ale unor organizații, pe care le-au interpretat ca făcând parte din exercițiu.

Ce a raportat Anthropic

Analiza retrospectivă a acoperit 141.006 rulări eligibile ale evaluărilor. Anthropic a identificat trei incidente, însumând șase rulări, în care accesul neintenționat la internet a făcut posibilă atingerea unor sisteme de producție ale organizațiilor. Compania spune că a oprit evaluările cyber la 23 iulie și a notificat partenerul și organizațiile afectate la 27 iulie.

• Mediul de evaluare trebuia să fie izolat, însă o neînțelegere și o configurare necorespunzătoare au permis accesul la internet.
• Modelele au fost instruite că țintele fac parte dintr-un exercițiu controlat și că mediul nu are internet; această presupunere a fost greșită.
• Conform analizei publicate, interacțiunile au folosit slăbiciuni de bază, precum credențiale slabe sau endpointuri neautentificate, nu vulnerabilități complexe.
• Anthropic indică măsuri suplimentare de apărare în profunzime, validarea conexiunilor, monitorizare în timp real și cerințe mai clare pentru partenerii de evaluare.

Ce se schimbă pentru orice echipă care testează agenți sau AI

Un test de capabilitate nu este o autorizație de a atinge infrastructura reală. Această distincție trebuie impusă în arhitectură, nu lăsată într-un document de proiect: trafic de ieșire blocat implicit, conturi de test fără drepturi de producție, ținte inventariate și aprobate, precum și posibilitatea de a opri imediat un experiment. Un mesaj de sistem sau un brief nu poate compensa o rută de rețea deschisă.

• Folosește o regulă de egress „deny by default”; orice excepție trebuie să fie explicită, limitată și jurnalizată.
• Separă DNS-ul, conturile, tokenurile, registrele de pachete și datele de test de resursele de producție.
• Verifică înainte de fiecare rulare că domeniile și adresele permise corespund exact scopului aprobat.
• Păstrează telemetrie suficientă pentru a observa în timp real acțiunile neașteptate și pentru a opri rularea.
• Testează mecanismul de oprire ca pe un control de incident, nu ca pe o opțiune care „probabil funcționează”.

Furnizorul extern nu poate deveni limita de securitate

Evaluările realizate cu un laborator, un vendor de red teaming sau un furnizor de infrastructură extind suprafața operațională a organizației. Contractul este necesar, dar nu este containment. Înainte de o evaluare cu risc ridicat, cere dovezi tehnice ale izolării, reguli de notificare, acces la loguri și o procedură de răspuns convenită. Dacă nu poți verifica traseul de rețea și identitatea resurselor atinse, nu poți afirma că testul este izolat.

Checklist scurt înainte de un exercițiu cyber asistat de AI

• Există o listă scrisă a țintelor autorizate, a datelor de test și a persoanei care poate opri exercițiul?
• Este validat tehnic că mediul nu poate ieși către internet sau către rețelele interne neincluse în scop?
• Au fost eliminate credențialele reale, cheile cu durată lungă și legăturile către producție?
• Există monitorizare a traficului și a transcrierilor, plus alertă pentru un domeniu sau o acțiune neaprobată?
• Sunt pregătite notificarea, păstrarea dovezilor și analiza post-incident înainte de începerea testului?

Awareness-ul poate ajuta oamenii să recunoască o limită de scop sau să escaladeze o situație neobișnuită, dar nu înlocuiește izolarea tehnică. Lecția practică a acestui caz este simplă: în testele cu agenți capabili, controlul mediului este parte din experiment, nu o condiție presupusă în fundal.