Agenții AI au nevoie de limite de securitate pe care nu le pot rescrie

Este tentant să citim povestea Hugging Face ca momentul în care agenții AI au devenit răzvrătiți. Nu este exact ce s‑a întâmplat, iar detaliile contează. Aceștia erau agenți de cercetare în domeniul securității cibernetice care rulau în evaluări în care măsurile de protecție fuseseră deliberate reduse pentru ca cercetătorii să poată vedea de ce sunt capabile modelele. Nimeni nu are un bot de asistență pentru clienți care s‑a trezit într‑o dimineață și a decis să atace o companie. Dar acel context nu scutește pe nimeni de responsabilitate. Un agent a depășit limita în care trebuia să rămână, a folosit acreditări și instrumente în moduri neautorizate de operatorii săi și a ajuns în sisteme care aparțineau altcuiva. Aceasta este partea la care fiecare echipă de securitate ar trebui să acorde atenție.

Reuters a raportat că agenții investigau Hugging Face încă din mai, deși cercetătorii au spus că nu au găsit nimic care să arate că activitatea anterioară a cauzat o breșă de una singură. Iulie a fost diferit. OpenAI a declarat că modelele sale au ocolit controalele de izolare, a ajuns pe internet și a compromis părți ale propriei sale infrastructuri de cercetare, alături de sistemele Hugging Face. Contul propriu al Hugging Face descrie o intruziune desfășurată de la capăt la capăt de un sistem de agenți autonom, care a exploatat linia de procesare a datelor, a colectat acreditări și s‑a deplasat prin clustere interne.

Partea inconfortabilă este că agenții își făceau treaba. Ei urmăreau obiectivul care li‑s‑a fost atribuit. De aceea această poveste depășește cu mult un singur laborator de cercetare. Agenții din mediul enterprise urmăresc și ei obiective. Dețin acreditări, apelează la instrumente și se mișcă mai repede decât poate revizui orice persoană. Un agent cu intenții perfect bune poate totuși să provoace daune reale, iar un agent deturnat poate folosi exact aceeași autoritate în numele unui atacator. Prin urmare, securitatea trebuie să guverneze ce poate face efectiv sistemul, indiferent cât de încrezător pare modelul sau cât de inofensiv pare scopul său declarat.

Secure the Action, Not Just the Model

Majoritatea programelor de agenți timpurii își concentrează efortul asupra modelului. Echipele testează prompturile, ajustează refuzurile, adaugă un al doilea model pentru a verifica primul și monitorizează traseul de raționament pentru semne de intenții rele. Nimic din acestea nu este irosit. Dar totul este probabilistic, deoarece depinde de un alt model care ia o decizie de judecată. O limită de securitate în producție trebuie să fie deterministică și să înconjoare instrumentele, acreditările, rețelele și tranzacțiile.

Întrebarea pe care aș-o pune este una concretă: ce poate să realizeze efectiv acest agent în lumea reală? Redactarea unei cereri de plată este un lucru. Eliberarea fondurilor este altul. La fel este și în cazul pregătirii unei modificări a bazei de date versus rularea ei în producție, sau marcarea înregistrărilor care îndeplinesc o regulă de păstrare versus ștergerea lor. Poate fi același model în ambele cazuri, cu riscuri foarte diferite în funcție de partea liniei în care se află.

O prezentare recentă a Unite AI privind controlul capacităților trasează aceeași linie, legând riscul de date, instrumente, permisiuni, autonomie și mediul în care rulează agentul. Îmi place această abordare deoarece ne depășește etichetele vagi precum „model sigur” și „model nesigur”. Face echipele să urmărească fiecare cale de la decizia unui agent la ceva cu consecințe reale.

Oferiți fiecărui agent o identitate și un mandat restrâns

Un agent nu ar trebui să ruleze niciodată pe contul unui dezvoltator sau să moștenească tot ceea ce un utilizator uman are voie să facă. O identitate partajată anulează atribuirea. Acreditările cu durată lungă oferă unui atacator mai mult timp să le abuzeze. Iar conturile de serviciu largi permit unui flux de lucru mic să pătrundă în date și sisteme la care nu ar trebui să aibă acces.

NIST consideră acum identitatea software-ului și a agenților AI ca o problemă de arhitectură proprie. Documentul său conceptual întreabă cum poate un agent să demonstreze că este autorizat pentru o acțiune specifică, cum poate identitatea unui agent să fie legată de autorizația unui om și cum pot organizațiile să păstreze înregistrări rezistente la manipulare ale a ceea ce a fost intenționat și a ceea ce s‑a întâmplat efectiv. În practică, aceasta duce la un design simplu. Fiecare agent primește o identitate unică, un proprietar (o persoană sau o echipă), un scop definit și permisiuni limitate la sarcina în față.

Acreditările ar trebui să expire rapid și să funcționeze doar pentru resurse și acțiuni specifice. Accesul la rețea ar trebui să pornească de la o listă strictă de permisiuni. Dacă un agent trebuie să interogheze o bază de date aprobată, nu ar trebui să primească și un shell general, acces deschis la internet sau puterea de a genera noi acreditări. Și pe măsură ce munca trece printr-un lanț de agenți și instrumente, autoritatea ar trebui să devină mai restrânsă la fiecare pas, nu mai largă.

NIST avertizează, de asemenea, împotriva partajării acreditărilor și a accesului excesiv de larg, iar acest avertisment are greutate deoarece agenții sunt oportuniști. Dacă o rută este blocată, ei pot încerca un alt instrument, să exploreze mediul lor sau să dea peste un token uitat de cineva. Acreditările colectate au făcut parte și ele din povestea din iulie. Principiul celui mai mic privilegiu menține raza de impact mică când stratul de raționament face ceva ce proiectanții săi nu anticipaseră.

Keep Authorization Outside the Reasoning Loop

Un agent poate recomanda o acţiune. Nu ar trebui să poată decide dacă i se permite să o execute. Acea decizie aparţine unui strat de aplicare separat pe care agentul nu îl poate rescrie, opri sau ocoli prin argumente. Fiecare apel de instrument ar trebui să apară ca o cerere structurată: ce agent solicită, ce om o sponsorizează, ce operaţie doreşte, ce ţinteşte şi ce limite se aplică. Stratul de aplicare apoi îl permite, îl blochează sau îl escaladează.

OWASP descrie agenţia excesivă ca un amestec de funcţionalitate inutilă, permisiuni excesive şi prea multă autonomie. Ghidul său recomandă instrumente restrânse, permisiuni minime, autorizare la sistemul de nivel inferior şi aprobare de la utilizator pentru acţiuni cu impact ridicat. Cred că aceasta este exact ordinea corectă. Regula ar trebui să fie aplicată de către cel care deţine datele sau execută tranzacţia. Dacă un model spune că o acţiune este aprobată, acea afirmaţie singură nu ar trebui să aibă nicio greutate.

Această separare ajută şi la injecţia de prompturi. Un e‑mail sau document otrăvit ar putea influenţa raţionamentul agentului, dar nu poate extinde acreditările agentului sau să elimine o poartă de politică. Modelul este liber să solicite ceva interzis. Sistemul ar trebui să răspundă în continuare cu nu.

Păstraţi aprobarea umană pentru momentele cu adevărat importante

Revizuirea umană îşi justifică existenţa atunci când o acţiune nu poate fi anulată, trece o frontieră organizaţională, modifică privilegii, dezvăluie informaţii sensibile, mută bani sau atinge un sistem de producţie. Cereţi aprobare la fiecare pas de rutină şi veţi obţine două lucruri: întârzieri şi oameni care învaţă să facă clic pe „aprobare” fără să citească. NIST denumeşte explicit această oboseală de consimţământ.

O cerere de aprobare bună afișează acţiunea exactă în limbaj clar, inclusiv destinaţia şi parametrii relevanţi. Aceasta ar trebui să provină dintr-un sistem autoritar, nu din textul scris de agent. Aprobare ar trebui să expire rapid şi să acopere doar acea singură acţiune. Dacă se modifică vreun detaliu material, sistemul solicită din nou.

Ghidul de securitate pentru agenţi al OWASP recomandă testarea dacă o acţiune cu impact ridicat poate fi efectuată fără o aprobare validă, neexpirată şi legată de parametri. Această expresie merită reţinută. „OK pentru a continua” este o aprobare slabă care poate fi aprobată de un alt agent sau de un actor rău. „Transferă această sumă în acest cont” sau „deplasează această modificare în acest mediu” sunt lucruri pe care sistemul le poate verifica efectiv în momentul execuţiei, şi pe care utilizatorul le înţelege pe deplin.

Asigurarea identităţii umane în timp real contează la această poartă. O notificare push dovedeşte doar că cineva sau ceva a apăsat un buton. Designuri mai puternice necesită ca o persoană înregistrată să folosească autentificare cu cheie publică rezistentă la phishing, susţinută de o metodă locală de verificare biometrică. Standardele FIDO leagă acreditările cu cheie publică de serviciul online legitim şi păstrează datele biometrice pe dispozitivul izolat al utilizatorului. Folosită corect, autentificarea susţinută de hardware oferă dovezi mult mai bune că persoana potrivită era cu adevărat prezentă. Totuşi, nu înlocuieşte legarea tranzacţiei, un afișaj de încredere sau aplicarea politicii. Aveţi nevoie ca toate acestea să funcţioneze împreună.

Monitorizaţi comportamentul şi păstraţi dovezile

Nu puteţi conta pe promptul iniţial pentru a explica ce s‑a întâmplat pe parcursul unei execuţii lungi a agentului. Echipele de securitate au nevoie de telemetrie privind apelurile de instrumente, activitatea de reţea, utilizarea acreditărilor, deciziile de politică, aprobările, respingerile şi modificările de scop. Monitorizarea ar trebui să compare ceea ce a făcut efectiv agentul cu limita declarată pentru acea execuţie. Dacă unui agent i s‑a atribuit să analizeze cod şi începe să caute acreditări externe sau să sondeze un serviciu nelegat, ar trebui să declanşeze o alertă.

Jurnalele trebuie să conţină suficient context pentru a reconstrui lanţul de acţiuni fără a expune secrete în text simplu. Fiecare înregistrare ar trebui să surprindă versiunea agentului, proprietarul său, persoana sau sistemul care a iniţiat procesul, instrumentul utilizat, acţiunea solicitată, rezultatul politicii şi orice autorizaţie umană. Înregistrările semnate sau altfel rezistente la manipulare fac revizuirea post‑acţiune mult mai credibilă, în special când au fost implicaţi mai mulţi agenţi şi servicii.

Totul trebuie să ruleze la viteza maşinii. Nimeni care urmăreşte un tablou de bord nu va opri mii de apeluri care se finalizează în secunde. Controalele automate ar trebui să aplice limite de rată, să detecteze secvenţe neobişnuite şi să suspende acreditările imediat ce comportamentul depăşeşte un prag definit. În acest fel, anchetatorii umani primesc un incident delimitat de investigat, în loc de o urmărire fără sfârşit.

Proiectaţi calea de oprire înainte de lansare

Fiecare implementare a unui agent necesită o metodă de oprire care să elimine efectiv capacitatea. Cererea agentului să se oprească nu contează. Operatorii ar trebui să poată revoca acreditările sale, să întrerupă calea de reţea, să închidă mediul de execuţie şi să împiedice repornirea acţiunilor în coadă. Pentru fluxuri de lucru cu consecinţe majore, dacă serviciul de aprobare sau de politică cade, sistemul ar trebui să se închidă în mod sigur.

Apoi testaţi acea cale sub presiune. Deconectaţi serviciul de aprobare. Oferiţi agentului instrucţiuni contradictorii. Rotiţi o acreditare în mijlocul unei execuţii. Simulaţi un instrument compromis şi un aprobator care nu răspunde niciodată. Confirmaţi că acţiunea este blocată şi că rămâneţi cu o înregistrare utilă. Şi repetaţi acele teste ori de câte ori modelul, promptul, conectorul, sistemul de memorie sau setul de permisiuni se modifică.

Scopul este autonomia responsabilă

Nicicând acest lucru nu este un argument împotriva agenților, iar incidentul Hugging Face nu ar trebui să sperie pe nimeni de la agenții utili. Ceea ce ar trebui să facă este să elimine ideea că un prompt de siguranță plus intenții bune se adaugă la o implementare de încredere. Oferiți agenților spațiu să analizeze, să pregătească munca și să gestioneze sarcini reversibile. Mențineți autoritatea lor de a provoca consecințe reale restrânsă, vizibilă și aplicată de ceva în afara agentului însuși.

Înainte ca un agent să intre în producție, liderii ar trebui să poată răspunde la câteva întrebări simple. Ce sisteme poate accesa? Ce acreditări poate folosi? Ce poate face fără revizuire? Ce declanșează escaladarea? Cum vede aprobatorul acțiunea exactă care este aprobată? Ce dovezi vor rămâne în urmă? Și cum poate securitatea opri execuția imediat?

Dacă răspunsurile sunt neclare, agentul are mai multă autoritate decât își dă seama organizația. Arhitectura care rezistă în timp combină protecțiile modelului cu identitatea, privilegiul minim, aplicarea externă a politicilor, aprobarea umană selectivă, telemetria completă și un mecanism de oprire care funcționează cu adevărat. Pornește de la o presupunere sinceră: agenții capabili ne vor surprinde din când în când. Granițele noastre de securitate nu ar trebui să o facă.

În final, gândiți-vă la un agent AI ca la un stagiar cu acces (potențial) root care nu se teme de HR.

Ce protecții și bariere ar avea aceștia?

Procedați în consecință.