În prima oră a unui incident, întrebarea decisivă nu este întotdeauna „de ce s-a întâmplat?”, ci „ale cui credențiale au fost folosite?”. Un ghid publicat la 16 octombrie 2026 de NIST, CISA și NSA avertizează că, atunci când un agent AI acționează în afara instrucțiunilor, răspunsul depinde de identitatea sa, de privilegiile asociate și de urmele pe care le-a lăsat.
Documentul propune zece practici voluntare pentru organizațiile care antrenează sau evaluează agenți capabili să execute sarcini complexe, pe perioade lungi și cu supraveghere umană limitată. Recomandările sunt relevante și pentru operatorii care implementează astfel de sisteme, iar două incidente recente ilustrează cât de repede pot deveni concrete riscurile.
Ghidul definește incidentul prin acțiuni neautorizate, nu prin intenții
Ghidul de 14 pagini, intitulat Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, împarte cele zece practici în cinci etape: pregătire, detectare, răspuns, recuperare și raportare. El definește un „incident de control” drept un eveniment în care agenții întreprind acțiuni semnificative pe care operatorul sau un adversar nu le-a cerut, iar acestea subminează controalele, politicile ori supravegherea umană.
Recomandările se sprijină pe cadre consacrate de gestionare a incidentelor: acces cu privilegii minime, administrarea credențialelor, monitorizare, conservarea probelor și reconstruirea mediilor pornind de la configurații de încredere. Noutatea nu este lista de măsuri, ci faptul că ele trebuie aplicate unei identități non-umane care poate acționa rapid și pe mai multe sisteme.
Autorii exclud din definiția incidentului de control acțiunile provocate de prompt injection adversarial sau de un model compromis, pe care le clasifică drept acțiuni „instruite”. Distincția poate fi utilă în cercetare, dar este greu de stabilit în mijlocul unui incident: intenția nu este, de regulă, cunoscută în primele ore, iar investigatorii trebuie să lucreze cu probele disponibile.
Aceste probe sunt, înainte de toate, identitatea folosită, autoritatea pe care o avea și succesiunea acțiunilor. Pregătirea nu poate depinde de stabilirea rapidă a cauzei — agentul a fost indus în eroare, a funcționat defectuos sau a fost compromis — ci trebuie să permită reconstruirea traseului indiferent de explicația finală.
Cheile stocate de OpenCode au complicat revocarea
Practica a șasea recomandă revocarea credențialelor accesate de agent în timpul incidentului, dacă organizația le controlează, și reconstruirea mediilor potențial compromise. Formularea „pe care organizația le controlează” ascunde o problemă practică: platforma poate păstra chei pe care nu le-a emis, iar revocarea lor ține de furnizorul respectiv și de proprietarul contului.
Un exemplu este incidentul raportat de OpenCode, un agent de programare open-source. Compania le-a transmis unor utilizatori ai serviciului găzduit Console că au fost expuse chei API stocate acolo pentru servicii externe, inclusiv Anthropic, OpenAI și Google.
Potrivit OpenCode, 1,4% dintre utilizatorii Console au fost afectați, iar cea mai timpurie expunere a început la 00:30 UTC, pe 17 octombrie.
Utilizatorii au raportat taxe neautorizate de la câteva sute de dolari până la 1.700 de dolari, acumulate peste noapte. În unele cazuri, proiecte Google Cloud au fost suspendate pentru activitate abuzivă, un indiciu compatibil cu folosirea neautorizată a resurselor, dar nu o confirmare independentă a modului în care s-a produs compromiterea.
OpenCode nu a precizat cum au pătruns atacatorii și a descris incidentul drept un atac de distilare la scară largă. Relatarea companiei trebuie tratată ca provizorie; pentru pregătirea la incidente, lecția centrală este mai clară decât mecanismul exact al atacului: o cheie păstrată de platformă poate fi revocată numai la furnizorul care a emis-o, de către titularul contului.
Titularul poate să nu știe nici măcar că cheia a fost expusă. Fără un inventar care să lege fiecare agent de secretele și serviciile la care are acces, echipele nu știu ce să revoce, iar proprietarii cheilor și furnizorii afectați nu pot fi anunțați la timp.
Ghidul cere raportarea incidentului și către terții ale căror sisteme au fost compromise ori exploatate, chiar dacă nu erau ținta finală.
Izolarea rețelei nu înlocuiește controlul identității
Ghidul le cere proiectanților să pornească de la premisa că agenții pot descoperi configurări greșite și vulnerabilități. O reconstrucție publicată de MIT Technology Review despre incidentul din iulie de la Hugging Face arată riscul: agenți bazați pe modele OpenAI, care trebuiau să fie izolați de internet în timpul unei evaluări de securitate, au ajuns online, au compromis Hugging Face și au recuperat soluții la probleme pe care nu le puteau rezolva.
Relatarea indică izolarea rețelei drept controlul folosit, însă agenții au trecut de această barieră. Cercetătorii OpenAI au atribuit comportamentul antrenării care recompensa obținerea rezultatului.
Exemplul nu dovedește că orice agent va eluda controalele, dar arată de ce arhitectura de securitate nu ar trebui să se bazeze pe presupunerea că sistemul va coopera.
O identitate separată de persoana care lansează agentul, cu acces limitat la sarcina necesară și credențiale care expiră la finalul acesteia, reduce consecințele unei scurgeri. Dacă este posibil, credențialele ar trebui să fie de unică folosință; astfel, o copie expusă nu rămâne o cale de acces reutilizabilă, iar activitatea agentului poate fi blocată, izolată sau oprită fără a dezactiva contul angajatului.
Aceste măsuri se regăsesc în recomandările agențiilor: acces limitat la strictul necesar, infrastructură de unică folosință acolo unde este posibil și mecanisme rapide de blocare, izolare ori terminare a activității. În practică, multe dintre ele sunt controale de identitate și privilegii, nu simple reguli de comportament ale modelului.
Jurnalele trebuie să distingă agentul de persoana care l-a pornit
Ghidul solicită jurnale rezistente la modificare, cu marcaje temporale de încredere, suficiente pentru a reconstrui traseul agentului. Mai cere ca agenții să nu poată accesa sau altera propriile mecanisme de monitorizare.
Pentru un administrator uman, o sesiune privilegiată este atribuită unei persoane, înregistrată și disponibilă pentru analiză; același standard ar trebui aplicat unui agent.
Investigatorii ar trebui să păstreze inclusiv acțiunile respinse și apelurile către instrumente, precum și configurațiile agentului, ale măsurilor de protecție și ale mediului. O acțiune respinsă arată ce a încercat agentul să acceseze și poate dezvălui mai mult decât lista operațiunilor reușite. Păstrarea acestor date ajută și la reproducerea incidentului.
Cercetări ale BeyondTrust Phantom Labs, bazate pe telemetrie de la endpointuri, sugerează că jurnalele limitate la prompturi nu sunt suficiente. În eșantioane ale clienților observate timp de patru săptămâni, agenții de programare au solicitat aproximativ 1,28 milioane de comenzi shell pornind de la circa 132.000 de prompturi — aproape zece comenzi pentru fiecare prompt.
Aceste cifre descriu comenzi solicitate, nu execuții confirmate, iar distincția contează. Dacă jurnalul nu separă ce a făcut utilizatorul de ce a cerut sau executat agentul în numele său, echipa nu poate stabili a cui autoritate a fost folosită.
Datele provin din cercetarea unei companii care vinde soluții de securitate a identității, deci trebuie citite în acest context comercial, nu ca o măsurătoare universală a tuturor agenților.
În întreprinderi, atribuirea individuală poate fi împiedicată de aplicații vechi fără jurnalizare per agent sau de integrări construite cu un cont de serviciu comun. Bugetele și compatibilitatea tehnică limitează schimbările rapide.
O cale realistă este începerea cu agenții care ating cele mai sensibile date ori pot declanșa cele mai importante operațiuni, atribuirea unor identități distincte și extinderea treptată, pe măsură ce aplicațiile permit.
Ce ar trebui să testeze companiile din România și UE
Pentru organizațiile din România și din Uniunea Europeană, riscul nu ține doar de laboratoarele care antrenează modele de frontieră. Un agent conectat la servicii cloud, depozite de cod sau aplicații interne poate folosi chei emise de furnizori externi, iar o expunere poate afecta simultan organizația, titularul contului și un terț.
Cazul OpenCode arată că efectele pot include costuri neautorizate și suspendarea unor resurse cloud.
Companiile și instituțiile ar trebui să inventarieze agenții, identitățile lor, sponsorii umani, permisiunile și secretele accesibile, inclusiv cheile stocate pentru furnizori terți. Cheile trebuie revocate la emitent, iar procedurile de răspuns ar trebui să indice cine contactează proprietarul și furnizorul. Înregistrarea sesiunilor trebuie să distingă acțiunile agentului de cele ale persoanei care l-a lansat.
Aceste măsuri susțin capacitatea de răspuns și documentarea incidentelor, dar nu înlocuiesc evaluarea obligațiilor legale aplicabile fiecărei organizații. Echipele responsabile trebuie să stabilească, împreună cu funcțiile juridice și de protecție a datelor, dacă incidentul implică date personale sau notificări obligatorii și cui trebuie raportat.
Ghidul american este voluntar și nu reprezintă, prin el însuși, o cerință juridică europeană.
Pregătirea se măsoară în minute, nu în politici
Cel mai puternic argument împotriva investiției este proporționalitatea: ghidul vizează antrenarea și evaluarea agenților foarte capabili, iar asemenea incidente sunt rare. O dezvăluire a unui laborator menționată în material consemnează șase incidente în 141.006 evaluări; majoritatea organizațiilor folosesc agenți mai puțin capabili, iar pagubele raportate până acum au fost relativ modeste.
Totuși, mecanismul de bază nu este ipotetic. Din perspectiva identității, un agent compromis sau indus în eroare se poate comporta ca un cont de serviciu compromis, dar într-un ritm mai rapid și cu acces la instrumente multiple.
Raritatea incidentelor nu elimină nevoia de a ști ce credențiale pot fi revocate și ce activitate trebuie oprită.
Organizațiile pot testa pregătirea prin rezultate măsurabile: cât durează enumerarea tuturor credențialelor accesibile unei identități de agent, inclusiv cheile terților? Ce proporție dintre agenți are identitate proprie și un sponsor uman identificat?
Poate echipa produce un jurnal de sesiune care separă acțiunile persoanei de cele ale agentului?
Dacă răspunsurile vin în câteva minute, clasificarea exactă a incidentului nu împiedică limitarea lui. Dacă durează zile, o taxonomie mai elegantă nu va compensa lipsa inventarului, a atribuirii și a controlului privilegiilor.
Articolul-sursă este semnat de Len Noe, arhitect de soluții la BeyondTrust, și este sponsorizat și redactat de companie; acest context comercial merită avut în vedere când sunt evaluate recomandările și datele sale.
