Pentesting-ul agentic cu AI are limite: ce nu vede și cum pot companiile să reducă riscul
Pentesting-ul agentic promite să schimbe ritmul securității cibernetice: în locul unor teste punctuale, făcute manual și planificate cu săptămâni înainte, agenți AI pot explora infrastructura, corela vulnerabilități și simula lanțuri de atac mult mai rapid. Este o evoluție utilă pentru echipele IT care au prea multe alerte și prea puțin timp. Dar viteza nu înseamnă automat acoperire completă. Un agent poate demonstra că o vulnerabilitate este exploatabilă pe un server accesibil, însă poate rata sisteme sensibile, active izolate, aplicații fără exploit public sau breșe create de configurații și permisiuni. Pentru companiile din România, mai ales cele cu infrastructură hibridă, magazine online, VPN-uri și aplicații SaaS, întrebarea corectă nu este „avem AI pentru pentesting?”, ci „ce risc real validează și ce rămâne nevăzut?”. (bleepingcomputer.com)
Ce face bine un agent AI de pentesting
Un instrument de pentesting agentic poate automatiza etape care, până recent, necesitau multă muncă manuală: inventarierea unei suprafețe de atac, verificarea serviciilor expuse, corelarea unei vulnerabilități cu un activ și încercarea unor trasee de escaladare a privilegiilor sau de mișcare laterală în rețea.
Pentru mai multe detalii despre această parte a subiectului, vezi Alertă critică de securitate: VMware anunță vulnerabilități severe de tip "VM Escape".
Valoarea lui nu este că „gândește ca un hacker” în sensul spectaculos promovat în prezentări comerciale. Valoarea reală este capacitatea de a repeta rapid un set de verificări, de a prioritiza problemele care pot fi exploatate în contextul unei organizații și de a furniza dovezi mai utile decât o listă lungă de CVE-uri cu scoruri CVSS.
Diferența este importantă. O vulnerabilitate cu severitate critică nu este automat cel mai urgent incident dacă serviciul vulnerabil nu este accesibil, este segmentat corect sau protejat de controale care blochează tehnica de atac. În schimb, o problemă evaluată inițial ca medie poate deveni prioritară dacă afectează un server expus public, un panou de administrare WordPress, un VPN sau o aplicație care procesează date de clienți.
Ghid ServerSpan relevant: Cum să securizezi WordPress după un hack: oprește reinfectarea, recuperează SEO-ul și înțelege când DIY nu mai este suficient.
Pentesting-ul autonom poate fi foarte bun la demonstrarea impactului: „un atacator poate ajunge de aici până aici”. Este mai util decât simpla scanare, deoarece leagă vulnerabilitatea de acces, identitate, permisiuni și active cu valoare de business. Tocmai de aceea trebuie însă tratat ca un instrument de validare, nu ca un înlocuitor complet pentru echipa de securitate sau pentru un test de penetrare făcut de specialiști. (picussecurity.com)
Zonele pe care pentesting-ul agentic le poate rata
Prima problemă este una de siguranță. Un agent care rulează exploit-uri reale nu poate fi lăsat să testeze fără limite toate sistemele. Serverele de producție, bazele de date critice, echipamentele industriale, rețelele medicale, sistemele financiare sau serviciile fără toleranță la întreruperi pot fi excluse din test. Acest lucru este corect operațional, dar creează o pată oarbă: exact activele cele mai importante pot rămâne neverificate prin exploatare directă.
A doua limitare apare când nu există un exploit sigur sau public. În primele ore după apariția unei vulnerabilități noi, echipa de securitate trebuie să decidă dacă este expusă înainte ca un test automat să poată demonstra practic exploatarea. Nu toate vulnerabilitățile pot fi reproduse fără riscul de a modifica date, de a bloca un serviciu sau de a afecta disponibilitatea.
Picus Security, compania aflată în spatele analizei preluate de BleepingComputer, estimează că testarea automată bazată pe exploatare live poate acoperi doar aproximativ 10-15% din mediul tipic, tocmai din cauza activelor restricționate, izolate sau prea sensibile pentru testare directă. Este o estimare de furnizor, nu o regulă universală, însă ilustrează corect problema: un rezultat „nu s-a găsit nimic” poate însemna doar că agentul nu a avut voie sau nu a putut testa zona respectivă. (picussecurity.com)
Mai există și problema vizibilității. Dacă inventarul de active este incomplet, agentul va analiza foarte eficient doar ceea ce cunoaște deja. Un subdomeniu uitat, un server vechi de staging, un cont de administrare rămas activ sau o aplicație găzduită la un furnizor extern pot lipsi din analiză. AI nu compensează automat un inventar slab; de multe ori, doar accelerează concluziile trase din date incomplete.
Cum se închid golurile: trei tipuri de validare, nu un singur produs
Abordarea promovată în materialul analizat este combinarea pentesting-ului autonom cu validarea expunerii și simularea de breșă și atac. Ideea merită reținută chiar dacă organizația nu folosește platforma unui anumit furnizor: niciun tip de test nu răspunde singur la toate întrebările relevante.
Primul strat este pentesting-ul cu exploatare controlată. Acesta arată ce poate fi compromis în mod real pe sistemele unde testarea este permisă. Este cea mai puternică dovadă tehnică, dar trebuie limitată prin reguli clare de angajament: intervale orare, active permise, metode interzise și proceduri de oprire.
Al doilea strat este validarea expunerii fără exploatare directă. În loc să ruleze un exploit periculos, platforma poate corela vulnerabilitatea cu tehnicile necesare pentru atac și poate verifica dacă mediul permite acele etape: serviciu accesibil, autentificare slabă, segmentare insuficientă, politici EDR lipsă sau drepturi excesive. Această metodă nu oferă mereu aceeași certitudine ca o exploatare live, dar este utilă pentru sisteme sensibile și pentru vulnerabilități nou apărute. (picussecurity.com)
Al treilea strat este Breach and Attack Simulation (BAS), adică simularea controlată a tehnicilor folosite de atacatori pentru a vedea ce detectează și ce blochează efectiv firewall-ul, EDR-ul, SIEM-ul, WAF-ul sau protecția de email. Aici întrebarea nu este doar „există vulnerabilitatea?”, ci și „dacă cineva o exploatează, observăm atacul la timp?”. (picussecurity.com)
Pentru o firmă românească, această combinație este mai practică decât achiziția unui „agent AI” doar pentru că sună modern. Un magazin online, de exemplu, are nevoie să știe simultan dacă panoul de administrare este expus, dacă backup-urile sunt accesibile greșit, dacă alertele ajung la cineva și dacă refacerea serviciului funcționează după un incident.
Automatizarea are nevoie de limite, identitate și audit
Un agent de securitate este tot un software cu acces la rețea, date și uneori credențiale privilegiate. Prin urmare, el devine el însuși un element care trebuie controlat. Dacă primește acces prea larg, poate colecta date sensibile inutil, poate crea trafic problematic sau poate produce consecințe operaționale nedorite. Dacă primește acces prea restrâns, concluziile sale vor fi incomplete.
NIST subliniază exact această tensiune în proiectele sale recente despre identitatea și autorizarea agenților software: agenții AI au nevoie de identificare clară, permisiuni limitate, trasabilitate, audit și mecanisme care să reducă riscuri precum comportamentul autonom imprevizibil sau prompt injection. (nist.gov)
În practică, companiile ar trebui să evite configurarea de tip „admin peste tot”. Agentul trebuie să aibă conturi dedicate, permisiuni minime, rotație a secretelor și jurnale separate. Orice test care implică exploatare activă ar trebui să poată fi oprit rapid și să producă un raport care explică nu doar ce a găsit, ci și ce sisteme nu au fost testate.
Pentru organizațiile care operează site-uri, aplicații web sau servicii găzduite, baza rămâne aceeași: inventar corect, actualizări, backup testat, acces administrativ protejat și monitorizare. Un proces bun de hosting și administrare a infrastructurii reduce suprafața de atac înainte ca un agent AI să înceapă să caute breșe.
Lucruri practice de urmărit înainte de adoptarea unui instrument de pentesting agentic:
- cereți o listă explicită cu activele testate, excluse și imposibil de testat;
- separați scanarea, simularea și exploatarea activă în politici diferite;
- acordați agentului acces minim și folosiți credențiale dedicate;
- verificați unde ajung logurile, parolele, configurațiile și datele colectate;
- măsurați timpul până la remediere și retestați după aplicarea patch-urilor;
- nu evaluați soluția după numărul de alerte, ci după riscurile confirmate și închise.
Concluzie: Pentesting-ul agentic poate face securitatea mai rapidă și mai relevantă, dar nu este o baghetă magică pentru „testarea completă” a unei organizații. Cele mai mari riscuri apar tocmai în zonele unde agentul nu poate acționa liber: sisteme critice, active ascunse, vulnerabilități fără exploit și controale de securitate care par funcționale doar pe dashboard. Companiile care combină testarea activă cu validarea expunerii, simularea atacurilor și guvernanța strictă a agenților vor obține rezultate mai bune decât cele care cumpără pur și simplu încă un produs AI.