Anatomia unui agent autonom de securitate

Un agent autonom de securitate rulează o buclă: se uită la țintă, decide ce încearcă în continuare, trimite cererea, citește răspunsul, decide din nou. Modelul ocupă un singur pas din buclă. Tot ce îl înconjoară este un cadru de execuție, iar acel cadru face bucla legală, reproductibilă și de încredere. Un model mai bun schimbă calitatea ipotezelor. Un control lipsă schimbă dacă munca ar fi trebuit să aibă loc.

Ce face modelul și ce face cadrul de execuție?

Modelul citește un răspuns și propune acțiunea următoare. Parametrul acesta pare un identificator de obiect. Mesajul de eroare de acolo lasă să se vadă un stack trace. Tokenul acesta pare să aparțină altui client. Este raționament sub incertitudine, partea la care modelele de limbaj excelă.

Cadrul răspunde la trei întrebări diferite. Ce este permis: ce gazde, căi, metode și ritmuri de cereri poate folosi agentul. Ce se înregistrează: cererea exactă, răspunsul, momentul și motivul. Ce este blocat: tot restul, înainte să iasă din mașină. Modelul nu deține autoritatea de a răspunde la niciuna dintre ele.

OWASP numește acest risc în LLM06:2025 Excessive Agency. Dă trei cauze: funcționalitate, permisiuni și autonomie excesive, iar măsura de atenuare este explicită: autorizarea se implementează în sistemele din aval, nu se lasă pe seama modelului. Un agent de securitate este cazul cel mai clar. Treaba lui este să găsească comportament neașteptat, deci propriul comportament ar trebui să fie partea cea mai previzibilă a sistemului.

De ce este capacitatea fără scop o răspundere?

Un agent cu shell, browser și acces la internet poate ajunge oriunde ajunge mașina pe care rulează. Dacă scopul numește o gazdă, iar agentul poate atinge o mie, accesul în plus nu este capacitate liberă. Este un set de cereri pe care nimeni nu le-a autorizat, care așteaptă o greșeală. Un model care citește greșit o pagină, sau o pagină care conține instrucțiuni adresate modelului, este suficient ca să îl trimită în altă parte.

Eșecul acesta este mai rău decât o vulnerabilitate ratată. Testarea unui sistem pe care nu ai fost autorizat să îl testezi nu este un rezultat slab, ci un incident cauzat de uneltele tale. Poate expune date ale clienților, poate declanșa procesul de incident al țintei sau poate scoate un serviciu din funcțiune. Agentul nu va observa. Va scrie ce a găsit cu același ton încrezător pe care îl folosește pentru descoperiri reale.

Ce trebuie scris înainte de prima cerere?

Un scop este mai mult decât o listă de gazde. Numește persoana și organizația care autorizează munca, entitatea juridică care o primește, activele vizate, metodele permise, conturile și datele de test, fereastra de timp, excluderile, tehnicile interzise, contactul de urgență și canalul de raportare. Spune și ce se întâmplă dacă agentul găsește date ale unor terți pe țintă.

Centrul Național de Securitate Cibernetică din Marea Britanie descrie aceeași pregătire în ghidul său despre testarea de penetrare. La stabilirea scopului ar trebui să participe proprietarii de risc, personalul tehnic care cunoaște ținta și un reprezentant al echipei de testare. Documentul rezultat consemnează limitele tehnice, tipurile de test așteptate, durata și efortul, cerințele de conformitate și de raportare, precum și sistemele critice care au nevoie de tratament special.

Scrie scopul de două ori. O copie este semnată de un om și păstrată. Cealaltă este compilată în reguli pe care cadrul le poate impune. Dacă cele două se despart, copia compilată este cea care rulează de fapt, deci diferența este un bug cu consecințe juridice. Dacă nu poți arăta propoziția care autorizează o cerere, cererea nu pleacă.

Cum dovedește agentul că ținta a autorizat testarea?

Păstrează o dovadă de autorizare pe care un revizor o poate verifica fără să te întrebe nimic. Are nevoie de o persoană numită, o organizație, o dată, activele acoperite și fie o semnătură, fie un link către o politică de program care acordă permisiunea. Într-un program de bug bounty, politica este autorizarea, dar ea este condiționată. Acoperă doar activele listate, doar tehnicile permise și leagă deținătorul contului de reguli care se schimbă.

Tratează politica drept dependență live. Descarc-o, păstrează un hash și momentul descărcării, apoi reverific-o înainte de fiecare rulare. Dacă pagina de scop s-a schimbat, oprește și cere o nouă aprobare, în loc să presupui că vechile reguli mai sunt valabile.

Dovada de autorizare călătorește împreună cu descoperirea. O raportare ar trebui să numească programul, activul, versiunea politicii și rularea care a produs dovada. Fără acest fir, raportul este o afirmație că ceva nu funcționează pe un sistem pe care poate nu aveai voie să îl atingi.

De ce o listă de permisiuni, nu una de interdicții?

Lista de interdicții greșește în favoarea accesului. Presupune că te-ai gândit la fiecare cale, gazdă și tehnică ce trebuie exclusă, iar primul lucru uitat devine o cerere neautorizată. Lista de permisiuni greșește în favoarea refuzului. Tot ce nu este numit este refuzat.

Compilează scopul în gazde, prefixe de cale, metode și limite de parametri, și refuză tot restul implicit. Pune punctul de aplicare în afara modelului, într-un proxy prin care trece fiecare unealtă. O unealtă de browser, un client HTTP și o unealtă de linie de comandă ar trebui să iasă prin aceeași ușă, iar containerul în care rulează să nu aibă altă rută. Dacă o unealtă poate deschide un socket direct, lista de permisiuni este o sugestie.

Două detalii produc majoritatea scurgerilor. Redirectarea: dacă verifici doar primul URL, ținta poate trimite agentul către o gazdă din afara scopului, deci fiecare pas are nevoie de aceeași verificare. Rezolvarea numelui: o gazdă din scop poate indica o adresă pe care nu o voiai, inclusiv una internă. Rezolvă, verifică adresa față de listă și față de intervalele private, apoi fixeaz-o.

Tratează wildcard-urile cu suspiciune. Un scop care acoperă toate subdomeniile acoperă și subdomeniul pe care un client l-a îndreptat către un serviciu terț printr-un CNAME. Modelul poate fi convins să îl încerce. Proxy-ul nu poate fi convins.

Cum își limitează agentul ritmul?

Limitele de ritm fac parte din respectul față de țintă, nu sunt o setare de performanță. Dă fiecărei gazde un plafon de concurență și unul de cereri pe secundă și dă întregii rulări un buget în cereri, nu în minute, ca o țintă lentă să nu transforme o intervenție de două ore într-una de o săptămână. Reduce ritmul la răspunsurile 429 și 503 și respectă antetul Retry-After pe care RFC 6585 îl definește pentru 429. Oprește rularea când rata erorilor crește brusc și păstrează un buton de oprire pe care un om îl poate folosi în timpul rulării.

Reîncercările sunt partea periculoasă. Un agent care tratează fiecare eșec ca motiv de a mai încerca transformă un endpoint instabil într-un instrument de denial of service. Limitează numărul de încercări, adaugă întârzieri aleatorii și tratează un grup de erori de server ca semnal de oprire, nu ca o enigmă de rezolvat.

Ghidul NCSC adaugă partea umană: testerii ar trebui să facă tot posibilul să evite impactul nedorit, iar un punct de contact tehnic ar trebui să fie disponibil la scurt timp. Pentru o rulare autonomă, persoana de contact este numită în scop, accesibilă în fereastra de testare și poate opri rularea printr-un canal care nu depinde de agent.

Ce înseamnă, concret, capturarea dovezilor?

Pentru fiecare acțiune, înregistrează momentul în UTC, unealta, ținta, metoda, calea, antetele fără credențiale, un hash și o copie a corpului cererii, codul, antetele și corpul răspunsului, durata, motivul dat de model și decizia de politică ce a permis cererea. Acesta este minimul pentru ca altcineva să poată reproduce descoperirea.

Capturează la granița rețelei, nu din descrierea pe care modelul o dă propriilor acțiuni. Un model care își rezumă faptele este un martor interesat de poveste. Jurnalul proxy-ului este adevărul de bază. Dacă cele două nu se potrivesc, rularea este invalidă.

Secțiunea despre raportare din ghidul OWASP de testare stabilește criteriul pentru o descoperire: suficiente informații ca să înțelegi vulnerabilitatea, să o reproduci și să o rezolvi. Recomandă și mascarea datelor sensibile și punerea rezultatelor curățate ale uneltelor într-o anexă. Dovezile conțin adesea date personale, deci anonimizarea aparține fluxului de lucru, înainte de scrierea jurnalului, nu raportului de la final.

Reluarea nu trebuie să aibă nevoie de model. O descoperire ar trebui să conțină cererea exactă, contextul de autentificare, precondițiile și un script care o trimite din nou. Narațiunea agentului explică de ce a încercat; cererea înregistrată dovedește ce s-a întâmplat. Rezultatul unui model nu este determinist, deci întrebarea repetată nu este reproducere.

De ce semnează un om înainte de orice trimitere?

Un agent poate produce o descoperire convingătoare și greșită, poate raporta un duplicat, poate pune datele personale ale unui client într-o captură de ecran sau poate descrie un impact nedemonstrat. Un om verifică dacă dovada se reproduce, dacă activul este în scop și dacă raportul spune doar ce susține dovada.

Separă credențialele. Agentul scrie o ciornă într-o coadă și nu are acces la contul de trimitere. O persoană numită o revizuiește, o editează și o trimite sub propria identitate. OWASP recomandă aprobarea umană pentru acțiunile cu impact mare, iar o raportare de vulnerabilitate este una: ajunge la un terț, poate declanșa procesul lor de incident și poartă numele tău.

Semnătura este locul unde rezultatul agentului devine afirmația studioului. Este un loc rezonabil pentru un om.

Ce ar trebui să înregistreze agentul despre propriile acțiuni?

Ține două jurnale. Jurnalul de acțiuni notează ce a făcut agentul. Jurnalul de decizii notează de ce cadrul a permis, ce regulă s-a potrivit, ce versiune de scop era încărcată și cât buget mai rămânea. Adaugă metadatele rulării: cine a pornit-o, versiunea modelului și a promptului, setul de unelte, versiunea scopului, numărul total de cereri și motivul opririi.

Apoi compară ambele cu jurnalul proxy-ului după rulare. Jurnalul agentului este util pentru a înțelege raționamentul și inutil ca dovadă, pentru că agentul poate greși sau poate fi manipulat. Doar punctul de aplicare vede fiecare cerere care a ieșit cu adevărat din mașină.

Acest lucru contează cel mai mult în cazul injecției de prompt. Conținutul țintei este intrare neîncrezută. O pagină poate conține text care îi spune agentului că este acum autorizat să testeze altă gazdă, iar modelul poate să o creadă. Apărarea nu este un prompt de sistem mai bun. Este un proxy care refuză cererea și un jurnal care arată tentativa.

La ce este bun, de fapt, modelul?

Generarea de ipoteze, și transformarea dovezilor într-un raport pe care un dezvoltator îl poate folosi. Calitatea lui se vede în mai puține cereri risipite și descoperiri mai bune la o sută de încercări, nu în permisiunea de a scoate un control. Modelului îi dai raționamentul, cadrului îi dai dreptul de veto.

Unde se leagă partea de cercetare?

Cadrul decide ce este permis. Cercetarea decide ce merită încercat. Partea de cercetare o ținem în Bounty Atlas, o bază de cunoștințe selectată și căutabilă pentru testare autorizată: metodologie, lucrări, unelte și tipare adunate într-un singur loc. Este un instrument de lectură și referință, nu un scanner, și nu atinge nicio țintă. Cele două jumătăți se întâlnesc când o ipoteză din catalog devine o cerere pe care cadrul o permite sau o refuză.

Danube Labs construiește sisteme AI și controalele din jurul lor. Dacă plănuiești un agent care atinge sisteme ce nu îți aparțin sau vrei o a doua părere despre cel pe care îl ai, vezi proiectele noastre de sisteme AI sau programează un apel introductiv gratuit.