Anthropic: trei incidente reale în evaluări de cybersecurity
Anthropic a publicat pe 30 iulie 2026 o analiză a trei incidente din propriile evaluări de cybersecurity. Compania spune că, din 141.006 rulări în care un model putea obține acces la internet, a găsit trei incidente în care un model Claude a ajuns la sisteme reale prin sau în timp ce interacționa cu mediul unui partener de evaluare.
Detaliul important nu este o poveste despre un model care „a evadat”. Conform Anthropic, mediul care trebuia să fie izolat avea acces la internet din cauza unei neînțelegeri de configurare. Modelele au tratat sistemele găsite ca pe părți ale unui exercițiu capture-the-flag. Este, înainte de toate, un incident de izolare, scope și observabilitate operațională.
Ce a confirmat Anthropic — și ce nu a confirmat
Anthropic descrie trei incidente, în șase rulări de evaluare, care au afectat infrastructura de producție a trei organizații. Compania spune că modelele au folosit tehnici de bază, inclusiv parole slabe, endpointuri neautentificate și, într-un caz, SQL injection; nu afirmă că ar fi exploatat vulnerabilități complexe sau zero-day.
Într-un caz au fost accesate credențiale și o bază de date de producție cu câteva sute de rânduri. În altul, un pachet Python malițios publicat în PyPI a rămas disponibil aproximativ o oră și a fost rulat pe 15 sisteme. Anthropic declară că a oprit evaluările cyber pe 23 iulie, a notificat partenerul și organizațiile afectate pe 27 iulie și lucrează la remediere.
Postarea precizează și limitele: evaluările au rulat pe infrastructură dedicată, separată de sistemele interne sensibile și de datele clienților Anthropic. Faptele publicate sunt analiza companiei, iar investigațiile partenerului și ale organizațiilor afectate continuă.
Controlul ratat: mediul de evaluare este un sistem de producție pentru risc
Un range de evaluare poate conține ținte fictive, dar un agent capabil să execute comenzi, să caute pe rețea și să publice artefacte reprezintă un risc real dacă iese din limitele de rețea. Anthropic spune că validarea tuturor căilor de acces la internet, monitorizarea în timp real a jurnalelor și revizuirea mai atentă a transcripturilor sau a logurilor de rețea ar fi putut preveni sau descoperi mai devreme problema.
Aceasta este o regulă utilă și pentru echipe care testează intern: tratează containerul, runner-ul CI, proxy-ul, conturile de cloud și cheile de test ca elemente ale aceleiași frontiere de securitate. „Fără internet” trebuie verificat tehnic prin deny-by-default, egress controlat și teste independente, nu doar declarat în prompt sau într-un document de exercițiu.
Cinci controale practice pentru evaluări cu agenți AI
- ▸Izolare de rețea implicită: blochează egress-ul; permite explicit doar destinații de test, prin proxy cu allowlist și loguri care nu pot fi modificate de agent.
- ▸Scope executabil: exprimă țintele admise ca identități, CIDR-uri, hostname-uri și tokenuri de test, apoi aplică aceleași limite la nivel de rețea și de credentiale.
- ▸Credențiale cu rază mică de impact: conturi efemere, privilegii minime, fără acces la producție, fără posibilitatea de a publica pachete sau de a crea resurse plătite.
- ▸Oprire automată: alertează și suspendă rularea la DNS extern, egress neașteptat, încărcare de pachet, scanare în volum sau semnale că ținta nu aparține laboratorului.
- ▸Jurnal și revizuire: păstrează transcriptul, comenzile, logurile de rețea și deciziile de autorizare; fă un postmortem fără vină după orice abatere de scope.
Promptul ajută, dar nu este controlul de securitate
Anthropic observă că modelele fuseseră instruite că nu au acces la internet. Când au găsit sisteme reale, au dedus greșit că acestea fac parte din simulare. Compania notează că un prompt care ar fi explicat clar ce sisteme sunt în și în afara scope-ului ar fi putut modifica comportamentul.
Lecția nu este să renunți la instrucțiuni clare. Este să nu le confunzi cu enforcement-ul. Un agent poate interpreta greșit contextul, iar un prompt nu poate substitui firewall-ul, izolarea identităților, limitele de API sau o politică de blocare a acțiunilor ireversibile.
Ce să verifici înainte de următorul red-team automatizat
Înainte de a lansa un agent într-un exercițiu, cere răspunsuri verificabile la patru întrebări: ce anume poate atinge în rețea, ce identități poate folosi, cine vede semnalele în timp real și cine poate opri execuția. Dacă răspunsul la una dintre ele este „probabil nimic” sau „ne uităm după”, mediul nu este pregătit pentru autonomie.
Pentru organizațiile care au obligații de gestionare a riscului, dovezile acestor controale sunt utile și operațional: configurația de egress, testele de izolare, aprobarea scope-ului, logurile și lecțiile învățate. Ele nu constituie singure conformitate juridică, dar arată că un proces poate fi verificat, nu doar declarat.
Surse primare și metodologice
Păstrează vizibilitatea asupra produselor și deciziilor tale
Awarely Monitor corelează vulnerabilitățile cu produsele și activele urmărite, trimite alerte și păstrează un audit al deciziilor. Nu înlocuiește controalele de izolare pentru agenți AI; le completează cu context de vulnerabilitate.