Az AI ügynökök rég túlléptek az egyszerű kódrészletek generálásán. Teljes kódtárakban navigálnak, hibákat javítanak, teszteket futtatnak és pull requesteket készítenek. Megfelelő jogosultságokkal CI/CD-folyamatokhoz, fejlesztői eszközökhöz vagy akár infrastruktúra-elemekhez is hozzáférhetnek.
Ezért az értékelésüknél már nem elég kizárólag azt vizsgálni, mennyire hatékonyan programoznak. Külön mérni kell az offenzív kiberbiztonsági képességeiket is – különösen akkor, ha éles kódbázisokhoz vagy futó rendszerekhez kapnak hozzáférést.
Ezt a szűk, de kritikus képességet vizsgálja az ExploitGym benchmark.
Mi az ExploitGym?
Az ExploitGym egy nagyszabású kiberbiztonsági benchmark, amely azt méri, hogy egy AI ügynök képes-e egy már ismert sérülékenységet működő exploittá továbbfejleszteni.
Módszertani kulcspont: a PoV szerepe
A benchmark nem a sérülékenység önálló felderítésével kezdődik. Az agent megkapja:
– a sérülékeny kódbázist és a buildeléshez szükséges információkat;
– a hibát aktiváló Proof-of-Vulnerability (PoV) bemenetet;
– a sérülékenység szöveges leírását;
– a futtatási környezet adatait.
A benchmark egyes bemeneti elemei konfigurálhatók. A sérülékenységet javító patch rendelkezésre állhat, de az alapértelmezett értékelési beállításban nem érhető el az agent számára.
Az agent feladata, hogy ebből a kiinduló állapotból olyan exploitot építsen, amely jogosulatlan kódfuttatást ér el, majd megszerez egy védett, dinamikusan generált flaget.
A flag megszerzése önmagában még nem feltétlenül jelent sikeres megoldást. Az értékelés azt is ellenőrzi, hogy az agent valóban a feladatban kijelölt sérülékenységet használta-e ki, nem pedig egy másik hibát vagy kerülőutat.
Az exploitfejlesztés többek között alacsony szintű programértelmezést, a memóriaviszonyok és a vezérlésátadás követését, futásidejű alkalmazkodást, valamint hosszabb, több lépésből álló feladatsor végigvitelét igényelheti.
Kik készítették a benchmarkot?
A benchmark módszertanát a UC Berkeley, a Max Planck Institute for Security and Privacy, a UC Santa Barbara és az Arizona State University kutatói dolgozták ki.
A szerzők között az Anthropic, az OpenAI és a Google kutatói is szerepelnek. A tanulmány szerint az iparági partnerek visszajelzést, modell-hozzáférést és egyes kísérletek futtatásához támogatást biztosítottak.
Mit tartalmaz a benchmark?
A kutatási tanulmány 898, valós sérülékenységekből kialakított feladatot vizsgált három területen:
– 520 userspace feladatot, elsősorban nyílt forrású C/C++ projektekből;
– 185 feladatot a V8 JavaScript-motorból;
– 193 Linux kernelhez kapcsolódó feladatot.
Adatmennyiségi pontosítás: a nyilvános 1.0 kiadás
A nyilvánosan közzétett 1.0 kiadás nem teljesen azonos a tanulmányban értékelt adatkészlettel. A projekt hivatalos changelogja szerint a kiadás előtt kiszűrték a nem exploitálható eseteket, így a nyilvános verzió 869 feladatot tartalmaz:
– 502 userspace feladatot;
– 181 V8-feladatot;
– 186 kernelfeladatot.
A tanulmányban közölt eredmények a 898 feladatból álló kutatási mintára vonatkoznak, nem a később közzétett 869 feladatos verzióra.
Milyen környezetben futnak a feladatok?
A feladatokat reprodukálható, izolált értékelési környezetekbe csomagolták. A userspace- és V8-célpontok konténeres környezetben, a kernelcélpontok pedig QEMU/KVM-alapú virtuális gépekben futnak.
A benchmark különböző célrendszeri védelmek hatását is vizsgálja. Ezek közé tartozik:
– userspace környezetben az ASLR, a PIE és a stack canary;
– V8 esetén az ASLR és a V8 heap sandbox;
– a Linux kernelnél a KASLR és a user namespace-ek elérhetősége.
Mit mutattak az eredmények?
A tanulmány szerint az automatizált exploitfejlesztés továbbra is rendkívül nehéz. A legerősebb vizsgált modell–agent párosítások azonban ellenőrzött környezetben már a sérülékenységek számottevő részéből tudtak működő exploitot készíteni.
A fő összehasonlításban:
– a teljes, 898 feladatos kutatási mintát használták;
– a célrendszeri technikai mitigációkat kikapcsolták;
– minden feladatra legfeljebb két óra állt rendelkezésre;
– feladatonként egyetlen, idő- és költségkorlátozott futtatást végeztek;
– a modelleket jóváhagyott trusted-access kutatási programokon keresztül használták.
Ebben a beállításban:
– a Claude Mythos Preview–Claude Code párosítás 157 feladatot oldott meg;
– a GPT‑5.5–Codex CLI párosítás 120 esetben volt sikeres;
– a GPT‑5.4–Codex CLI párosítás 54 feladatot oldott meg.
A számok értelmezésekor fontos, hogy a Mythos Preview módosított instrukciót is kapott egy kiegészítő CLAUDE.md fájlon keresztül. Az eredmények ezért nem tekinthetők olyan tiszta modell-összehasonlításnak, amelyben minden egyéb feltétel teljesen azonos volt.
Két különböző védelmi réteg
Az eredmények értelmezéséhez két eltérő védelmi szintet kell megkülönböztetni.
Modelloldali biztonsági korlátozások
Ezek a szolgáltatók által az inference során alkalmazott biztonsági szűrők, amelyek korlátozhatják, hogy a modell milyen kiberbiztonsági kéréseket hajt végre.
A fő kísérleteket az OpenAI Trusted Access for Cyber és az Anthropic Cyber Verification Program keretében futtatták. Ezekben a jóváhagyott kutatási környezetekben az inference-szintű szolgáltatói korlátozásokat kikapcsolták.
Ez nem jelenti a betanítás és a biztonsági finomhangolás során kialakított visszautasító viselkedés eltávolítását: egyes modellek ilyen környezetben is megtagadtak bizonyos feladatokat.
A GPT‑5.5 alapértelmezett szolgáltatói szűrőinek visszakapcsolásakor az esetek 88,2 százalékában az agent még az első eszközhasználat előtt blokkolódott. A fennmaradó futások eljutottak bizonyos felderítési lépésekig, de nem értek el érdemi előrehaladást az exploitálásban.
Célrendszeri technikai mitigációk
Ezek az operációs rendszer és a futtatókörnyezet védelmi mechanizmusai, például az ASLR, a stack canary, a V8 heap sandbox vagy a KASLR.
A standard mitigációk bekapcsolása jelentősen csökkentette, de nem szüntette meg teljesen az agentek sikerességét. A mitigációkkal újrafuttatott, korábban sikeres feladatok közül az összes vizsgált modell eredményeit együtt számolva 37 userspace-, 20 V8- és 12 kernelfeladat maradt sikeres.
Ezek az eredmények alátámasztják, hogy a célrendszeri védelmek érdemben nehezítik az exploitálást, és támogatják a réteges védelem alkalmazását. A számok nem egyetlen modell teljesítményét, hanem az összes vizsgált modell összesített eredményét jelentik.
Mit mér – és mit nem mér – az ExploitGym?
Az ExploitGym azt vizsgálja, hogy az agent:
– képes-e egy ismert sérülékenységből és PoV-ból exploitláncot építeni;
– tudja-e követni és manipulálni az alacsony szintű futási folyamatokat;
– végig tud-e vinni egy hosszabb, több lépésből álló exploitfejlesztési feladatot;
– képes-e jogosulatlan kódfuttatást elérni a kijelölt sérülékenység felhasználásával;
– hogyan változik a teljesítménye bizonyos memóriavédelmi és sandbox-mechanizmusok bekapcsolásakor.
Az ExploitGym nem méri:
– az agent általános biztonságosságát vagy megbízhatóságát;
– a prompt injection támadásokkal szembeni ellenállását;
– az önálló, nulladik napi sérülékenységek felderítését;
– a biztonságos kódgenerálási képességet;
– a titkok és hitelesítő adatok biztonságos kezelését;
– a teljes vállalati AI kockázatot.
A magasabb ExploitGym-pontszám ezért erősebb exploitálási képességet jelez – nem pedig általánosságban jobb vagy biztonságosabb modellt.
Miért nem elég egyetlen kódolási benchmark?
A SWE-bench és a hozzá hasonló benchmarkok repositoryszintű szoftverfejlesztési feladatokat mérnek: képes-e az agent értelmezni egy hibajegyet, módosítani a kódot és átvinni a teszteket.
Az ExploitGym ettől eltérő kérdést tesz fel: képes-e az agent egy ismert sérülékenységből jogosulatlan kódfuttatáshoz vezető exploitot készíteni?
A két mérés nem helyettesíti egymást.
A magas kódolási benchmarkpontszám önmagában nem bizonyít erős sérülékenységelemzési, biztonságos kódgenerálási vagy exploitálási képességet. Ugyanígy az exploit fejlesztésben elért jó eredmény sem jelenti azt, hogy a modell megbízható biztonsági lektor vagy biztonságos kódgenerátor.
Az AI ügynökök értékeléséhez ezért több különálló dimenzió szükséges:
– fejlesztői produktivitás és kódhelyesség;
– biztonságos kódgenerálás;
– sérülékenységek felismerése;
– exploitálási képesség;
– prompt injection elleni ellenállás;
– jogosultság- és titokkezelés;
– kontrollálhatóság és emberi felügyelet.
Ne egyetlen leaderboard alapján válasszatok modellt
Ha egy modellt kódgenerálásra, security review-ra vagy threat modelingre használtok, az adott feladathoz tartozó értékeléseket vizsgáljátok. A jó általános kódolási teljesítmény önmagában nem bizonyít erős biztonsági képességet.
Az AI által generált kód maradjon a megszokott kontrollok alatt
Az AI használata nem indokolja a statikus alkalmazásbiztonsági tesztelés, a függőségvizsgálat, az automatizált tesztelés vagy az emberi code review elhagyását. Az AI által írt kód ugyanúgy tartalmazhat biztonsági hibákat, mint az ember által készített kód.
Az agent csak a szükséges jogosultságokat kapja meg
A szervezeti kockázatot a modell képességei, az elérhető adatok, az eszközök és a jogosultságok együtt határozzák meg.
Ennek megfelelően:
– alkalmazzátok a legkisebb szükséges jogosultság elvét;
– különítsétek el a fejlesztői, teszt- és éles környezeteket;
– korlátozzátok az agent hálózati hozzáférését;
– minimalizáljátok a hitelesítő adatokhoz és titkokhoz való hozzáférést;
– a kockázatos műveleteket izolált sandboxban futtassátok;
– merge, release és deploy előtt követeljetek meg emberi jóváhagyást;
– naplózzátok az agent műveleteit és eszközhasználatát.