A támadók ma már körülbelül öt nap alatt fegyvereznek fel egy új sebezhetőséget (Mandiant, a Google Cloud része). Egy átlagos szervezetnek 43 nap kell, hogy kijavítson egyet (Verizon DBIR 2026). Egy új, ingyenes útmutató bemutatja, hogyan zárják be ezt a rést az autonóm AI agentek, és mit kell elvárniuk a biztonsági vezetőknek, mielőtt ilyet engednek éles rendszerre.

TL;DR

• A kihasználás lett a főbejárat. A támadások 31%-a így indul (Verizon DBIR 2026), ez az első számú kezdeti hozzáférési módszer, miközben az éves pentesteléssel a rendszerállomány becslések szerint 90%-a érintetlen marad.
• A képesség már bizonyított, nem csak ígéret. Egy autonóm rendszeraz első helyre került a HackerOne amerikai toplistáján2025-ben (XBOW), és lektorált kutatásokban az agenteka „one-day” hibák 87%-át kihasználták külső segítség nélkül (Fang és mtsai, 2024).
• A folyamatos tesztelés mérhetően jobb, mint az időszakos. A programozott tesztelés4,5-szer nagyobb eséllyel segít abban, hogy a csapatok három napon belül kijavítsák a kritikus hibákat (Cobalt, 2026).
• Ez egy AI agent az éles rendszeredben. Legyen magas a léc. Igazolt lefedettség, független ellenőrző rendszer, a kockázatos hatókört korlátozó védelmi korlátok és részletes naplózás nélkül ne fogadd el.
• A gazdasági oldal az elfogadásnak kedvez. Egy nagyjából 18 000 dolláros manuális megbízás (iparági becslés) áll szemben egy 4,44 millió dolláros átlagos incidenssel(IBM, 2025).

Az éves pentest már a megjelenésekor elavult

A pentestelés az elmúlt tíz évben alig változott – pedig muszáj lenne, mert a támadók már nem éves ciklusokban gondolkodnak. Ha a túloldal napokban mér, akkor az éves megbízás, a hosszú PDF és a már a kézhezvételkor elavult javítási lista egyszerűen túl lassú.

A 2026-os iparági adatokban mind látszanak azok a tényezők, amelyek miatt az időszakos modell tarthatatlanná vált.

A kihasználás átvette a vezetést. A Verizon 2026-os DBIR jelentése, amely több mint 22 000 megerősített incidensre épül, fordulópontot jelez: a sebezhetőségek kihasználása megelőzte az ellopott hitelesítő adatokat, mint leggyakoribb bejutási mód.

A javítás viszont az ellenkező irányba mozdult. Egy ismerten kihasznált hiba javításának medián ideje 32 napról 43 napra nőtt, és a CISA KEV katalógusában szereplő hibák közül a ténylegesen kijavítottak aránya 38%-ról 26%-ra esett vissza.

A támadók napokban, a védők hetekben mérnek. A Google Mandiant telemetriai adatai szerint átlagosan nagyjából öt nap telik el a sebezhetőség felfedezésétől a kihasználásáig. A Cobalt 2026-os State of Pentesting jelentése szerint egy magas kockázatú megállapítás medián javítási ideje 39 nap, és a legjobb és a legrosszabb szervezetek között 25-szörös a különbség. Aki 43 napos ciklusban védekezik egy olyan ellenféllel szemben, aki öt nap alatt lép, az valójában nem kezeli a kockázatot, csak utólag dokumentálja.

Az AI mindkét oldalon szétfeszítette az időszakos modellt. A támadók AI-t használnak, hogy gyorsabban találják meg és fegyverezzék fel a hibákat. A saját fejlesztőid AI-val olyan tempóban adnak ki kódot, amit egy emberi tesztelőcsapat nem tud követni, és a Cobalt szerint az AI/LLM-alapú alkalmazásokban 2,7-szer gyakrabban találnak magas kockázatú problémákat, mint a hagyományos appokban.

Évente egyszer készül egy pillanatkép, az eszközpark tizedéről, heteket csúszva, miközben az ellenfél öt nap alatt mozog. Ezt a rést hivatott bezárni az agentikus pentestelés.

Egy hiba, négy kimenet

Nézzük meg, mit jelent ez a különbség egyetlen, gyakori támadási láncon: egy IDOR hiba egy bejelentkezett felhasználói fiókhoz tartozó felületen.

A támadó belép egy átlagos fiókba, módosítja az account_id mezőt egy profilfrissítési kérésben, és rájön, hogy az alkalmazás soha nem ellenőrzi a tulajdonjogot. Ezután tömegesen végigpróbálja az azonosítókat, átírja más felhasználók e-mail-címét, jelszó-visszaállítást indít, és teljes fiókátvétellel távozik. Nincs CVE. Nincs hibás input. Csak egy üzleti logika, amit az alkalmazás rosszul kezel.

Pontosan ez a hibakategória tett 885 millió jelzálog- és tulajdoni iratot hozzáférhetővé a First American Financialnél 2019-ben: egy számjegyet kellett átírni a dokumentum linkjében, és máris más iratait látta a támadó.

• Egy scanner a válaszokat egy CVE-adatbázissal veti össze. A saját logikádra nincs CVE. Kimarad.
• A DAST egy fix payload-listát lő el. A kihasználáshoz érvényes munkamenet kell, és egy több lépéses folyamat, ami egyetlen payload-listában sincs benne. Kimarad.
• Egy manuális pentester megtalálja, ha ez a végpont épp beleesik a mintavételezett 5–10%-ba, és csak a következő release-ig. Egyszer megtalálja, aztán elavul.
• Egy agentikus rendszer feltérképezi a végpontot, következtet az erőforrás-tulajdonlási viszonyokra, és összefűzi az enumerációt az e-mail átírásával és a jelszó-visszaállítással. Ennek a feladatnak minden futáskor át kell mennie. Folyamatosan megtalálja, ellenőrzi és újraellenőrzi.

A CISO Guide-ban megtalálod a teljes, három generációt összehasonlító áttekintést és a beszállítók értékelési szempontjait, köztük azt a tíz kérdést, amivel gyorsan kiderül, hogy csak egy becsomagolt LLM-ről van-e szó.

Három tervezési döntés, ami elválasztja a platformokat a demóktól

A kategória tipikus zsákutcája az, amikor egy DAST eszközre egyszerűen rátesznek egy LLM-et: alatta ugyanaz a fix payload-lista, fölötte pedig egy kiszámíthatatlan lefedettség. Azt, hogy egy valódi platformról beszélünk-e, nem a modell, hanem az architektúra dönti el – és ez három ponton látszik.

• Feladatokra bontott, kikényszerített lefedettség. Ha az AI dönti el, mit tesztel, a lefedettség bizonyíthatatlanná válik: a modell az „érdekes” találatok felé sodródik, és csendben kihagyja a többit. Követeld meg, hogy a rendszer előre állítson össze egy teljes tesztmátrixot: minden végpontot minden releváns támadási kategóriával szemben, nem átugorható feladatként. Az AI abban legyen rugalmas, hogyan támad meg egy-egy feladatot, ne abban, hogy egyáltalán megcsinálja-e.
• Független validáló agent. Egy találat csak akkor kerülhet be a riportba, ha egy külön agent megismétli és igazolja. Így a téves riasztások kiszűrése az architektúrába kerül, nem a csapatod triage-folyamatára, arra a rejtett teherre, ami miatt sok szkennelő eszköz összességében több elemzői időt éget el, mint amennyit megspórol.
• Böngésző-native agent. A legtöbb agentikus eszköz gyakorlatban csak egy curl, amihez hozzákötöttek egy modellt. A valódi weboldalak ezt azonnal szétverik: dinamikus renderelés, egyszer használatos kódok, MFA, botvédelem. Az agentnek valódi böngészőt kell vezérelnie, tartania kell a session állapotát, és rekonstruálnia kell a felhasználói szándékot, különben a felszín alatti üzleti logika teljesen kimarad a tesztelésből.

„A 80%-os lefedettség már nem elég, mert a támadóknak elég az az egy rés, amit kihagytál.” — Ysrael Gurt, CTO & társalapító, Reflectiz

Irányítsd úgy, mint egy autonóm agentet

Az agentikus pentest eszköz egyszerre két dolog: egy kontroll, ami csökkenti a kockázatot, és egy autonóm AI rendszer, ami a saját környezeted ellen fut. Az útmutató governance-ellenőrzőlistája végigveszi, mit kell megkövetelni az első engedélyezett futtatás előtt: egyértelmű és visszavonható scope, a hatókört korlátozó védőkorlátok azonnali vészleállítással, adatizoláció a customer-data infrastruktúrához való nulla hozzáféréssel, teljes körűen exportálható audit trail, meghatározott emberi felügyelet és vendor-garanciák.

A próba egyszerű. Ha nem tudsz válaszolni arra, hogy „mi a legrosszabb, amit ez az agent tehet az éles rendszerrel, és mi állítja meg?”, akkor még nem állsz készen arra, hogy engedélyezd a futtatását.

A büdzsé matek és az audit hozadéka

Egy manuális megbízás átlagosan ~18 300 dollárba kerül, mielőtt rájön az általános 30–50%-os túlfutás, és egy érettebb program így is évi 150 000 dollár felett költ arra, hogy a becsült eszközállományának mindössze 5–10%-át tesztelje (Reflectiz költségelemzés publikusan elérhető vendorárak alapján). A board számára nem az a kérdés, melyik árajánlat a legolcsóbb. Az számít, mennyi lefedettségre súlyozott kockázatcsökkenést kapsz egy dollárért: az agentikus platformok akár tízszeres tesztkapacitást jelentenek egyetlen manuális megbízás áráért, és minden folyamatosan tesztelt végpont eggyel kevesebb út egy hét számjegyű incidens felé.

Van egy megfelelőségi hozadék is. A folyamatos, dokumentált tesztelés olyan bizonyítékot ad a PCI DSS 4.0.1 „jelentős változás után” záradékaihoz, amit az éves tesztelés szerkezetileg nem tud biztosítani, és illeszkedik a DORA, a NIS2, a SOC 2, az ISO 27001, a GDPR 32. cikk és a HIPAA kontroll- és biztosítéki követelményeihez. Minden futás saját bizonyítékcsomagot generál: lefedettségi mátrixot, validált megállapításokat reprodukálási lépésekkel, valamint trendriportokat, amelyekre az auditorok rá tudnak kérdezni. A guide maps each framework a folyamatos tesztelés által előállított bizonyítékokra.

Mi van a teljes útmutatóban

• A 2026-os kitettségi adatok vizualizálva
• A tíz kérdés a vendoroknak, a figyelmeztető jelekkel, amelyek leleplezik a csupán LLM-re csomagolt megoldásokat
• A governance-kontrollok, amelyeket a szerződésbe érdemes beleírni
• Az agentikus pentestelő vendorok piaci térképe
• Négy árképzési modell, és hogy melyik mire „büntet”
• 90 napos bevezetési ütemterv, a számonkérhető KPI-okkal
• A 11 pontos CISO-ellenőrzőlista

A stratégiai kérdés már nem az, hogy manuális vagy automatizált tesztelés kell. Az számít, hogyan érsz el folyamatos, bizonyítható, validált lefedettséget a teljes webes portfóliódra, biztonságosan, és olyan költségszinten, amit meg tudsz védeni.