De la inteligență la autoritate

Inteligența artificială depășește etapa în care doar răspunde la întrebări și generează conținut. Sistemele de inteligență artificială pot tot mai des să interpreteze instrucțiuni, să elaboreze planuri, să selecteze instrumente și să execute sarcini fără îndrumare umană continuă.

Această distincție contează.

Un sistem de inteligență artificială care recomandă o acțiune este diferit de unul autorizat să o efectueze. Diferența nu ține neapărat de inteligență sau de sofisticare, ci de autoritate.

Sistemele autonome nu se limitează la modelele lingvistice mari de ultimă generație. Din această categorie fac parte sistemele specializate de învățare automată, robotica, vehiculele autonome, agenții software și combinațiile de tehnologii care iau decizii sau întreprind acțiuni independent, în condiții de operare definite.

Beneficiile potențiale sunt considerabile. Aceste sisteme pot sprijini descoperirile științifice, operațiunile industriale, serviciile medicale, dezvoltarea de software și securitatea cibernetică. De asemenea, pot produce rezultate neintenționate, pot expune informații sensibile sau pot iniția acțiuni care depășesc ceea ce au intenționat operatorii lor.

În Provocări de securitate în proiectarea sistemelor autonome, Mohammad Hamad și Sebastian Steinhorst analizează provocările de securitate legate de răspunsul autonom la incidente, evaluarea riscurilor, controlul accesului, fiabilitatea datelor și interacțiunile dintre sistemele autonome. Cercetările lor, axate în mare parte pe sisteme ciberfizice, arată că securizarea acțiunilor independente ale mașinilor implică provocări care depășesc sfera agenților bazați pe modele lingvistice mari (LLM) de astăzi.

Consecințele mai ample ale autonomiei merită o analiză serioasă, inclusiv posibilitatea producerii unor vătămări fizice. Dovezile trebuie însă interpretate cu atenție. De exemplu, incidentele în care sunt implicate vehicule automatizate nu pot fi atribuite automat acelorași mecanisme care afectează agenții autonomi de securitate cibernetică. Contează gradul de autonomie, condițiile de operare, implicarea oamenilor și dovezile privind cauzalitatea.

În mod similar, dovezile că inteligența artificială autonomă poate provoca daune nu demonstrează că guvernanța rămâne neapărat în urmă. Nici nu ar trebui să presupunem că sistemele autonome sunt, prin natura lor, dificil de securizat.

Întrebarea esențială nu este dacă inteligența artificială poate realiza activități complexe, ci dacă arhitecturile și cadrele de securitate și organizaționale care guvernează sistemele autonome pot stabili limite adecvate pentru autoritatea delegată și pot furniza dovezi verificabile că aceste limite sunt respectate.

Securitatea cibernetică oferă o perspectivă deosebit de utilă asupra acestei întrebări, deoarece specialiștii în securitate contestă de zeci de ani presupunerile privind încrederea, permisiunile, accesul și comportamentul sistemelor.

Jocul de-a șoarecele și pisica la viteza mașinilor

Securitatea cibernetică a fost descrisă mult timp drept un joc de-a șoarecele și pisica.

Atacatorii descoperă vulnerabilități, apărătorii introduc măsuri de protecție, iar ambele părți se adaptează. Ciclul continuă pe măsură ce se schimbă tehnologiile, tacticile și mediile de operare.

Inteligența artificială autonomă nu schimbă neapărat regulile fundamentale ale acestui joc. Se pot schimba însă participanții — cine sau ce joacă —, viteza cu care acționează și volumul de muncă ce poate fi realizat fără intervenție umană continuă.

Un sistem autonom de securitate ofensivă ar putea identifica servicii expuse, investiga vulnerabilități, elabora posibile căi de atac și testa dacă acestea pot fi exploatate. Un sistem defensiv ar putea folosi capacități similare pentru a investiga amenințări, a identifica vulnerabilități și a valida măsurile de remediere.

Acest potențial de utilizare duală este esențial pentru înțelegerea implicațiilor de securitate ale inteligenței artificiale autonome.

Project Glasswing al Anthropic oferă un exemplu de descoperire a vulnerabilităților asistată de inteligența artificială. În actualizarea cercetării din mai 2026, Anthropic a raportat rezultate substanțiale în descoperirea vulnerabilităților, subliniind totodată provocările operaționale legate de verificare, divulgare și aplicarea de patch-uri.

Această distincție contează. Descoperirea unei vulnerabilități nu echivalează cu confirmarea faptului că aceasta poate fi exploatată, cu remedierea ei sau cu demonstrarea faptului că sistemul afectat este securizat.

Un număr mai mare de constatări poate îmbunătăți vizibilitatea, sporind în același timp solicitările adresate persoanelor și proceselor responsabile de soluționarea lor.

Rezultatul în materie de securitate depinde de ceea ce se întâmplă în continuare.

Dacă atacatorii și apărătorii își pot automatiza o parte din activitate, întrebarea relevantă nu este pur și simplu care dintre părți dispune de cel mai capabil model. Contează dacă apărătorii pot transforma descoperirile în remedieri eficiente și pot verifica independent rezultatele.

Testarea tradițională de penetrare nu devine depășită doar pentru că inteligența artificială poate îndeplini sarcini ofensive. Domeniul ei trebuie extins pentru a include sistemele care interpretează instrucțiuni, folosesc instrumente, combină permisiuni și urmăresc obiective în mai mulți pași.

Obiectivul rămâne același: să identificăm vulnerabilitățile, să stabilim importanța lor, să le remediem și să demonstrăm că măsurile de protecție funcționează.

Zonele de îmbinare arhitecturală: unde se întâlnesc limitele de securitate

Unul dintre riscurile mai subtile ale sistemelor autonome apare atunci când componente autorizate individual interacționează în moduri care produc rezultate neintenționate.

Numesc aceste puncte de interacțiune breșe arhitecturale.

Să luăm un exemplu obișnuit. O organizație restricționează accesul la un fișier folosind permisiunile NTFS. Un serviciu separat de partajare în cloud permite unui utilizator autorizat să partajeze informațiile respective cu persoane din afara organizației.

Fiecare sistem poate funcționa conform propriilor reguli. Totuși, interacțiunea dintre ele poate duce la partajarea informațiilor într-un mod care încalcă limita de securitate pe care organizația intenționa să o impună.

Acesta este un exemplu de politici potențial conflictuale, nu o afirmație că vreun produs de partajare a fișierelor ar fi vulnerabil.

Problema poate să nu fie un defect al niciunuia dintre controale, luat individual. Poate fi vorba despre o nereușită în aplicarea politicii de securitate intenționate pe parcursul întregului flux de lucru.

Sistemele de inteligență artificială autonome se pot confrunta cu situații similare atunci când conectează modele, aplicații, identități, instrumente, depozite și servicii externe.

Un agent poate avea permisiunea de a citi un document, de a crea un depozit și de a încărca fișiere. Asta nu înseamnă neapărat că are autoritatea de a combina aceste operațiuni într-un mod care expune informații confidențiale.

Cercetările oferă un motiv practic pentru a analiza aceste interacțiuni.

În AgentDojo, cercetătorii au evaluat atacuri prin injectarea prompturilor împotriva agenților IA care folosesc instrumente, în cadrul a 97 de sarcini realiste și a 629 de cazuri de testare a securității. Rezultatele lor au demonstrat că instrucțiunile rău intenționate introduse prin rezultate provenite de la instrumente nefiabile puteau compromite unele proprietăți de securitate, deși nici atacurile, nici agenții nu au avut succes în mod uniform.

Cercetarea nu stabilește cât de des reușesc aceste atacuri în mediile de producție. Ea arată însă de ce evaluarea exclusivă a răspunsurilor modelului nu este suficientă pentru a înțelege comportamentul unui sistem conectat la instrumente.

Un risc asociat este numit uneori „spălarea permisiunilor”: o acțiune pare legitimă deoarece trece printr-un instrument sau intermediar autorizat, deși comportamentul rezultat încalcă limita de autoritate intenționată.

Pe măsură ce mai mulți agenți colaborează, aceste relații necesită reguli explicite care să stabilească participarea, schimbul de informații și acțiunile permise.

Responsabilitatea trebuie, de asemenea, atribuită la nivelul arhitecturii.

Furnizorii de modele, operatorii platformelor, dezvoltatorii de agenți și organizațiile care îi implementează pot controla diferite părți ale sistemului. Un model util de responsabilitate partajată identifică cine controlează fiecare limită, cine poate autoriza excepții, cine monitorizează execuția și cine intervine atunci când ceva nu funcționează.

Autonomia nu elimină responsabilitatea. Ea sporește importanța de a ști unde se află aceasta.

Rigoare ofensivă: testarea a ceea ce credem că știm

Aici ajungem la un concept pe care îl numesc Rigoare ofensivă.

Rigoarea ofensivă este o abordare disciplinată a testării adversariale, a analizei critice și a validării bazate pe dovezi, menită să pună la încercare ipotezele de securitate. Ea evaluează comportamentul sistemelor în condiții realiste, în loc să se bazeze exclusiv pe proiecte arhitecturale, controale documentate sau protecții presupuse.

Practicile fundamentale sunt bine cunoscute. Testarea de penetrare, modelarea amenințărilor, exercițiile de tip red team și validarea securității pun de multă vreme la încercare ipotezele defensive.

Rigoarea ofensivă reunește aceste practici în jurul unei întrebări esențiale:

Ce dovezi demonstrează că limita de securitate intenționată rezistă?

O organizație poate avea politici care restricționează informațiile sensibile, un model configurat să respingă solicitările interzise și un agent care funcționează cu permisiuni limitate.

Acestea sunt măsuri de protecție importante. Existența lor nu demonstrează însă, de una singură, că întregul sistem se comportă în siguranță în condiții adversariale.

Un model poate respinge o instrucțiune rău intenționată, în timp ce un instrument autorizat permite totuși o acțiune neintenționată. O politică poate părea corectă, dar interacțiunile dintre sisteme pot crea o cale neașteptată de ocolire a acesteia.

Uneori numesc acest fenomen „iluzia barierelor de protecție”: confundarea prezenței unor bariere de protecție cu dovada că sistemul nu poate depăși limita pe care acestea ar trebui să o impună.

Barierele de protecție sunt utile. Eficacitatea lor trebuie însă demonstrată.

Să luăm cazul unui agent autonom autorizat să investigheze o posibilă compromitere. Acesta poate prelua jurnale, examina activitatea utilizatorilor și recomanda măsuri de limitare a incidentului.

În timpul unui test de securitate autorizat, un tester adversarial introduce instrucțiuni înșelătoare în informațiile pe care agentul ar trebui să le proceseze.

Testul nu ar trebui să se limiteze la a stabili dacă agentul a urmat acele instrucțiuni.

Ar trebui să se verifice dacă agentul a încercat să efectueze o acțiune neautorizată, dacă niște controale independente au împiedicat executarea acesteia, dacă tentativa a fost înregistrată și dacă sistemul și-a revenit în mod corespunzător.

Rigoarea ofensivă reunește cinci activități:

1. Stabilirea ipotezei: Identificarea proprietății de securitate pe care arhitectura trebuie să o asigure.
2. Testarea ipotezei: Verificarea unor căi de atac realiste, a unor intrări manipulate și a combinațiilor de capabilități legitime.
3. Colectarea dovezilor: Stabilirea acțiunilor pe care sistemul a încercat să le întreprindă, a celor care au fost executate și a controalelor care au funcționat.
4. Remedierea vulnerabilității: Tratarea modelului, fluxului de lucru, permisiunilor, arhitecturii sau procesului operațional care a provocat defecțiunea.
5. Verificarea remedierii: Retestarea căii de atac relevante și confirmarea faptului că proprietatea de securitate vizată este asigurată.

Aceasta este diferența dintre testarea răspunsului unui model și testarea securității întregului sistem.

De asemenea, este necesar să se analizeze ce se întâmplă după obținerea unui punct inițial de acces. Un atacator poate încerca să colecteze acreditări, să-și escaladeze privilegiile, să-și asigure persistența sau să se deplaseze lateral, abuzând de capabilitățile deja disponibile în mediul respectiv.

Faptul că un instrument este legitim nu înseamnă că orice utilizare a lui este legitimă.

Scopul rigorii ofensive nu este să presupunem că sistemele autonome sunt nesigure, ci să stabilim, prin testare, unde rezistă limitele lor de securitate.

Autonomie condiționată: separarea inteligenței de autoritate

Un răspuns arhitectural constă în a distinge între ceea ce poate face un sistem de inteligență artificială și ceea ce este autorizat să facă.

Numesc această abordare autonomie condiționată.

Autonomia condiționată recunoaște că gradul adecvat de independență depinde de sarcină, mediul de operare, consecințele potențiale, incertitudine și dovezile disponibile pentru justificarea unei acțiuni.

Un agent care rezumă informații publice nu necesită neapărat același nivel de supraveghere ca unul autorizat să dezactiveze conturi, să modifice regulile firewallului sau să schimbe infrastructura de producție.

În cazul celui din urmă, pot fi necesare reguli explicite de desfășurare a testării, permisiuni aplicate independent, o autorizare mai strictă și aprobarea unei persoane pentru acțiunile cu consecințe importante.

Aceste limite nu ar trebui extinse doar pentru că un agent decide că un acces mai larg l-ar ajuta să-și îndeplinească obiectivul.

Un agent poate reconsidera modul în care îndeplinește o sarcină autorizată, fără a obține autoritate suplimentară.

Top 10 OWASP pentru aplicațiile LLM abordează această problemă prin categoria LLM06:2025 – Agenție excesivă. OWASP identifică funcționalitățile, permisiunile și autonomia excesive drept surse de risc și recomandă limitarea capabilităților și aplicarea independentă a autorizării.

Autonomia condiționată aplică aceste principii în funcție de riscul operațional.

Accesul la informații ar trebui limitat la ceea ce necesită sarcina. Permisiunile instrumentelor ar trebui restrânse la operațiunile aprobate. Limitele de acțiuni, limitele de frecvență, cerințele de aprobare și condițiile de oprire pot constrânge execuția.

Aceste măsuri de protecție sunt deosebit de importante în testarea ofensivă autonomă.

Un agent de testare poate descoperi în mod legitim acreditări sau informații sensibile în timp ce urmărește un obiectiv autorizat. Dar descoperirea unei acreditări nu înseamnă că modelul trebuie să primească valoarea acesteia în text clar.

Un cadru de securitate poate separa acreditările sensibile de model și poate intermedia utilizarea lor printr-un mecanism de autorizare aplicat independent. De exemplu, un intermediar pentru acreditări ar putea furniza un secret direct unui serviciu aprobat, fără a-l expune inutil modelului.

Acest lucru se înscrie în principiile consacrate ale privilegiului minim și separării atribuțiilor.

Acest lucru ridică și o întrebare interesantă despre arhitectura Bring Your Own Model (BYOM) sau Bring Your Own LLM (BYO-LLM).

Dacă modelul de bază este înlocuit mâine, ce garanții de securitate rămân valabile?

Autorizarea sarcinilor, izolarea acreditărilor, restricțiile de domeniu, înregistrarea în jurnale și aplicarea politicilor pot ține de cadrul din jurul modelului, în loc să depindă în întregime de comportamentul acestuia.

Asta nu înseamnă că acel cadru este automat sigur sau că modelele sunt interschimbabile. Modele diferite pot interpreta instrucțiunile în mod diferit, pot apela instrumentele în mod diferit și pot introduce moduri de eșec diferite.

O evaluare relevantă trebuie să testeze atât controalele care ar trebui să rămână invariante, cât și comportamentele care se schimbă odată cu modelul.

Poate că unele dintre cele mai durabile proprietăți de securitate sunt cele care pot fi aplicate independent chiar și pe măsură ce componenta de inteligență evoluează.

Când inteligența artificială acționează asupra inteligenței artificiale: problema verificării

Să luăm în considerare un flux de lucru ipotetic pentru operațiunile de securitate:

Investighează acest incident, colectează dovezile, identifică identitățile afectate, propune măsuri de limitare, execută acțiunile aprobate și verifică rezultatul.

Un agent de investigare analizează telemetria. Un altul recomandă măsuri de izolare. Un agent autorizat să execute acțiuni face modificările. Un agent de verificare evaluează rezultatul.

Acesta este un exemplu de răspuns autonom la incidente cu buclă închisă, nu un eșec documentat la nivelul întregii industrii.

Să presupunem că primul agent identifică în mod eronat o identitate ca fiind compromisă. Un al doilea acceptă această concluzie și dezactivează contul. Un al treilea confirmă că acel cont a fost dezactivat și raportează că operațiunea a reușit.

Operațiunea selectată a fost finalizată.

Dar a fost corectă concluzia inițială? A fost acțiunea autorizată? A răspuns măsura de izolare amenințării reale? A provocat perturbări inutile?

Verificarea nu se poate rezuma la confirmarea faptului că un agent a executat acțiunea pe care a selectat-o.

Nici atribuirea verificării unui alt agent AI nu face automat ca rezultatul să fie independent.

Agenți diferiți se pot baza pe aceeași telemetrie inexactă, pe informații compromise sau pe ipoteze eronate. Faptul că sunt de acord nu stabilește în mod independent care sunt faptele de la bază.

Cu cât consecințele unei acțiuni autonome sunt mai grave, cu atât este mai importantă o verificare independentă de sistemul care ia decizia.

Această independență poate presupune dovezi provenite din surse separate, verificări deterministe ale politicilor, medii de execuție cu restricții, examinare umană sau o combinație de măsuri de protecție.

Măsurile de control adecvate ar trebui să fie proporționale cu consecințele unei erori.

Acțiunile cu impact redus și reversibile pot fi potrivite pentru verificarea automată. Acțiunile cu impact major sau dificil de inversat pot necesita o autorizare mai strictă, o confirmare independentă și aprobarea explicită a unei persoane.

Patru întrebări ajută la distingerea proprietăților de securitate relevante:

• A interpretat sistemul corect sarcina care trebuia îndeplinită?
• S-a încadrat acțiunea în limitele autorității delegate?
• A rămas execuția în limitele permise?
• A îndeplinit rezultatul obținut obiectivul de securitate urmărit?

Aceste întrebări sunt legate între ele, dar nu sunt interschimbabile.

Un agent poate executa o acțiune autorizată care produce un rezultat nedorit. De asemenea, poate obține un rezultat aparent benefic printr-o acțiune neautorizată.

Niciuna dintre aceste situații nu ar trebui considerată automat un succes în materie de securitate.

Pe măsură ce sistemele autonome devin mai capabile, provocarea nu constă doar în a le permite să finalizeze fluxuri de lucru complexe. Trebuie să existe dovezi suficiente că acțiunile lor rămân autorizate, adecvate și corecte.

Asta presupune să știm și când să ne oprim, să escaladăm problema, să anulăm o acțiune sau să acceptăm un risc limitat și înțeles în mod explicit.

Încrederea trebuie să se bazeze pe dovezi

Implicațiile de securitate ale IA autonome nu sunt exclusiv negative.

Sistemele autonome îi pot ajuta pe cei care se ocupă de apărare să descopere vulnerabilități, să investigheze amenințări și să efectueze activități de validare care, altfel, ar consuma mult timp și efort uman.

Modelele mai bune, controalele externe mai stricte și practicile operaționale mai mature pot reduce unele dintre riscurile asociate autorității delegate.

Prin urmare, ar fi prematur să concluzionăm că IA autonomă este inerent nesigură sau că guvernanța nu poate ține pasul cu dezvoltarea sa.

Există, de asemenea, un contraargument serios la ideea că IA autonomă necesită principii de securitate fundamental noi.

Multe dintre problemele de bază — privilegii excesive, intrări de neîncredere, autorizare deficitară, aplicarea inconsecventă a politicilor și verificarea insuficientă — sunt studiate de zeci de ani.

Controalele consacrate pot oferi deja soluții viabile, dacă sunt implementate și testate corect.

Autonomia poate schimba viteza, amploarea și complexitatea aplicării lor. Nu le invalidează automat.

Dovezile susțin o întrebare mai utilă: în ce condiții pot fi considerate de încredere sistemele autonome atunci când exercită autoritatea delegată și cum demonstrăm că aceste condiții sunt îndeplinite?

Răspunsul nu poate veni doar din capacitățile modelului.

Sunt necesare limite arhitecturale, responsabilități atribuite clar, autorizare aplicată independent, supraveghere adecvată și dovezi că măsurile de protecție funcționează în condiții realiste.

Este necesară și o concepție consecventă, dar evolutivă, asupra securității și riscului.

Principiile noastre fundamentale de securitate nu trebuie să se schimbe de fiecare dată când apare un model nou. Însă trebuie să ne punem neîncetat la încercare ipotezele despre modul în care se aplică aceste principii, pe măsură ce evoluează capacitățile, mediile de operare și autoritatea delegată.

Acesta este scopul Rigorii ofensive.

Nu pentru a demonstra că sistemele IA vor eșua, ci pentru a descoperi unde pot eșua, a stabili consecințele și a valida măsurile de control menite să prevină sau să limiteze aceste eșecuri.

Poate că avantajul mai durabil nu constă doar în alegerea unui model mai capabil, ci în construirea unei arhitecturi în care modelele se pot schimba fără a compromite limitele încrederii, autorității și verificării.

Jocul de-a șoarecele și pisica continuă. Din ce în ce mai mult, ambele tabere ar putea avea jucători autonomi.

Disciplina care contează este să ne asigurăm că abilitatea noastră de a găsi punctele slabe, de a le remedia și de a demonstra rezultatele nu se pierde în cursa de a automatiza orice altceva.

Încrederea trebuie să se bazeze pe dovezi.

Nota autorului: punctele de vedere și interpretările exprimate în acest articol îmi aparțin și nu reflectă neapărat pozițiile, politicile sau capabilitățile oficiale ale produselor angajatorului meu.