Álcázott támadások: a GitHub-tokentől a teljes kompromittálásig
A Codex egy példátlan sebezhetőséget hordozott magában: egy intelligensen formázott GitHub-ág nevébe ágyazva lehetett elszívni az OAuth-tokent, méghozzá teljesen olvasható formában. A támadók innovatív Unicode-karaktereket illesztettek az ág nevébe (ideografikus szóköz U+3000), így a Codex portálján szinte észrevehetetlen volt a csalás. A szoftver a néven keresztül értelmezett utasításokat hajtott végre a shellben, így a token kicsaltása gyerekjátéknak tűnt. Az OpenAI kritikus besorolást adott az ügynek, a teljes javítás februárban élesedett.
Később az Anthropic-féle Claude Code esetében két különböző sebezhetőséget is felfedeztek. Ezek egyike a parancsláncolást figyelmen kívül hagyta, így egyszerű shellutasításokkal írni lehetett a projekthez tartozó fájlrendszerbe. Egy jogosultsági trükk pedig a munkaterület biztonsági ablakát kerülte meg, így a felhasználói engedélykérés elmaradt. A legsúlyosabb hibát az jelentette, amikor a Claude Code figyelmen kívül hagyta a tiltószabályokat, ha az adott parancs több mint 50 alparancsból állt: itt a fejlesztők a teljesítmény oltárán áldozták fel a biztonságot.
MI-ügynökök: gyári előjogok, törékeny védelem
A Copilot esetében is kiaknázhatók voltak a rejtett utasítások is: egy pull request leírásába ágyazott parancs felülírta a biztonsági beállításokat, és automatikus jóváhagyást adott, így korlátlan shell-hozzáférés járt az összes főbb operációs rendszeren. Egy másik támadás során egy GitHub-issue szövege rávett egy ártalmas PR beemelésére, és ezzel megszerezte a GITHUB_TOKEN-t – a támadónak csak annyi dolga volt, hogy megnyissa az issue-t.
A Vertex AI esete különösen tanulságos: az alapértelmezett, Google-szolgáltatási identitást használó MI-ügynökök túlságosan tág jogosultságokat kaptak. Egy kompromittált P4SA-hitelesítővel hozzá lehetett férni a teljes Cloud Storage projekthez, sőt, még a zárt, Google által birtokolt Artifact Registry repókhoz is. Ez a hitelesítő szó szerint kettős ügynökként működhetett: egyszerre olvasta felhasználói és belső infrastruktúraadatait.
A védelem vakfoltjai: hol tévednek a cégek?
Az MI-fejlesztők rendszeresen alkalmaztak védelmi intézkedéseket, de ezek rendre áthághatók voltak. Egy elemzés szerint a fejlesztők negyede már rendszeresen használja ezeket az MI-kódoló asszisztenseket, ráadásul a generált kód közel fele tartalmazta a súlyos, OWASP Top 10-es besorolású hibákat. Mindegyik támadás egy közös minta szerint zajlott: a támadók mindig a futási jogosultságokra és a hitelesítőkre vadásztak, sohasem magára a gépi tanulómodellre.
A biztonsági szakértők szerint az egyik legnagyobb gond az, hogy a vállalatok azt hiszik, hivatalosan is jóváhagyták az MI-beszállítót, valójában azonban csak a felszíni felületet auditálták, az alattuk megbújó kulcsok, tokenek nincsenek kellően felügyelet alatt. Az ügynökök sokszor többet tudtak, mint azok az emberek, akiket szolgáltak. A gépi működés sebessége óriási előny a támadónak: míg a javítócsomagokat általában 72 órán belül visszafejtik a támadók, addig a különféle MI-ügynökök ezt másodpercek alatt megugorják.
Cégek túlélési stratégiái: mit kell tenni most?
Ennek fényében a biztonsági szakemberek az alábbi lépéseket javasolják. Először is: minden MI-kódoló ügynök azonosítása és regisztrálása szükséges, a kiadott kulcsok, engedélyek és OAuth-scope-ok tételes felsorolásával. Ha nincs külön szekció az eszközleltárban (CMDB) az MI-ügynökök kezelésére, azonnal létre kell hozni. Az összes eszközt rendszeresen frissíteni kell: a Claude Code 2.1.90 vagy újabb verziójára, a Copilot 2025 augusztusi javítására, a Vertex AI-nál pedig inkább saját szolgáltatási fiókra érdemes váltani.
Minden olyan bemenetet, mint az ágnevek, PR-leírások, issue-k és repo-beállítások, veszélyesnek kell tartani. Folyamatosan figyelni kell a Unicode-obfuszkációra, a túl hosszú, láncolt parancsokra, a settings.json vagy a .vscode/settings.json átrendezésére. Az ügynöki identitásokat ugyanúgy kell felügyelni, mint az emberi előjogokat: kulcsrotáció, a legszűkebb jogosultság elve, a kód generálását és telepítését végző ügynökök szétválasztása. Érdemes mindent előzetesen ellenőrizni, mielőtt bármilyen MI-ügynök hozzáférést kap akár a GitHubhoz, a Gmailhez vagy bármilyen belső repóhoz.
Az audit kötelező: minden szolgáltatótól írásban kell kérni, hogy mutassa be az MI-ügynök életútkezelését, a kulcs- és jogosultságirányítás menetét, rotációs és naplózási rendszerét.
Végzetes lemaradás: MI-ügynökök az árnyékban
A legtöbb biztonsági vezető fáradhatatlanul számon tartja az összes emberi felhasználót és jogosultságot, az MI-ügynököket azonban gyakorlatilag egyáltalán nem kezeli felelősen. Nincs olyan IAM-keretrendszer, amely ugyanolyan szigorúan venné az emberi és a gépi előjogok kezelését. Az automatizált szkennerek sem tudják jelezni, ha például egy ágnévbe ágyazott parancson keresztül fejlesztői jogkört rabolnak el.
Ennek fényében a végső tanulság egyértelmű: minden vállalat pontosan tudja, mit kellene tennie – egyszerűen az MI-ügynökök megjelenése miatt most már túl nagy a tét, hogy ezt tovább halogassák.
