Hogyan szivárogtattak ki titkokat az MI-kódoló ügynökök?
A támadást Aonan Guan és kollégái leplezték le, és „Comment and Control” néven ismertették. Működési elve, hogy a módosított GitHub workflow-beállítások révén – főként, ha a pull_request_target triggert használják, ami gyakori az MI-integrációknál – a titkos adatok (például API-kulcsok) bekerülnek az MI-ügynökök futtatási környezetébe. Ezzel egy rosszindulatú felhasználó akár egyetlen PR címével vagy kommentjével utasíthatja az ügynököt érzékeny információk kiszivárogtatására, például azt egy PR-kommentbe beágyazva.
Az Anthropic mindössze 100 dolláros (kb. 36 500 Ft) jutalmat fizetett a hibáért, miközben a sebezhetőség CVSS-értéke 9,4-es, vagyis kritikus: ez aránytalanul alacsony összeg. A Google 1337 dollárt (kb. 487 500 Ft), a GitHub pedig 500 dollárt (kb. 182 500 Ft) fizetett. Egyik cég sem adott ki hivatalos CVE-t vagy biztonsági figyelmeztetést – a javítások csendben történtek.
Mire figyelmeztet a három rendszerkártya?
A támadás lényege, hogy az MI-kódoló ügynökök nemcsak generált szövegek szűrésével foglalkoznak, hanem automatizált műveleteket is elvégeznek (például bash-parancsok, git-műveletek, API-hívások), ezekre pedig a legtöbb védelmi réteg nem terjed ki. Az Anthropic rendszerkártyája (232 oldal) még el is ismeri, hogy a Claude Code Security Review alapból nincs megerősítve promptinjekció ellen, csak a megbízható, belső bemenetekre lett tervezve. Az OpenAI rendszerkártyája modelleken végzett támadáselemzéseket sorol fel, de nem tartalmaz adatokat az ügynökök futtatási környezeteinek ellenállásáról. A Google csak egy rövid összefoglalót ad, leginkább a régi dokumentációkra hivatkozik.
Hét sebezhetőségi osztály az MI-ügynököknél
Az elemzés szerint hét fő fenyegetési pont marad védtelen:
1. Deployment surface mismatch – A platform teszteltnek tűnik, de a futtatási környezet nincs lefedve a gyártó védelmi programjával. Gyakori, hogy a valós telepítés (például Bedrock vagy Vertex) kizárt terület a gyártói program szemszögéből.
2. CI-titkok kiszivárgása – Az olyan környezeti változók, mint az ANTHROPIC_API_KEY vagy a GITHUB_TOKEN, minden workflow-lépéshez hozzáférhetők, így ezek mindössze egy rossz konfigurációval könnyedén kiszivároghatnak.
3. Túlságosan széles körű jogosultság – Az ügynökök alapesetben bash-, git-, API-hozzáférést is kaphatnak, amelyeket ritkán korlátoznak szigorúbb szerepkörökkel.
4. Nincs CVE-figyelmeztetés – Noha a kritikus hibát befoltozták, egyetlen automatizált eszköz sem jelezte volna a problémát, mivel nincs rá sem CVE, sem nyilvános figyelmeztetés.
5. A modellek szűrői nem terjednek ki az ügynök műveleteire – Az MI szöveggenerátorai blokkolhatják a kényes vagy tiltott tartalmat, de ha maga az ügynök hajt végre bash-parancsokat, ezek változatlanul átcsúsznak a szűrőn.
6. Megbízhatatlan bemenet utasításként való értelmezése – Minden felhasználói beírást az ügynök végrehajtható utasításként értelmezhet, például PR-cím, komment, commitüzenet.
7. Nincs összehasonlítható védelmi mérőszám – Egyedül az Anthropic közölt részletes, a promptinjekcióval szembeni ellenállásra vonatkozó adatokat. Az iparágnak nincsenek egységes mérőszámai, így nehéz valóban megalapozott beszerzési döntéseket hozni.
Mit lehet tenni a következő nagy baklövés előtt?
Ennek fényében nem elég egyetlen modellre vagy beszállítóra hagyatkozni, a teljes védelem csak jól szabályozott jogosultsági és futtatási struktúrával teremthető meg. A csapatoknak ki kell deríteniük, hogy milyen védelem vonatkozik az ügynökökre az adott környezetükben; ehhez minden beszállítóhoz irányított írásos kérdést kell eljuttatni, amelyben igazolást várnak el a futtatási védelmi szintekről.
Rendszeresen auditálni szükséges, hogy mely titkokhoz férnek hozzá az MI-ügynökök, minden felfedett hozzáférést zárolni kell, a tárolt titkokat rövid élettartamú OIDC-tokenekre kell cserélni. A bash-végrehajtást minden kódellenőrző MI-ügynöknél érdemes tiltani, a beírásokat (PR-címek, kommentek) szűrni és validálni kell.
Ajánlott az ügynök jogköreit jelentősen korlátozni, például írási jogosultságot csak emberi jóváhagyással adni, és minden ügynök futtatókörnyezetéhez illeszteni a saját szoftverbiztonsági kockázati kategóriáit.
A kulcsüzenet: nem a nulladik napi hibák (zero-day) jelentik a fő fenyegetést, hanem a laza engedélyek, a túl megengedő prediktív modellek és a gondatlan workflow-tervezés, amely már önmagában is a támadók szövetségesévé válhat.
Az MI-fejlesztések sebességével lépést tartó, egységes és transzparens biztonsági metrikákra sürgető szükség mutatkozik; ezek hiányában továbbra is a láthatatlan réseken szivároghatnak ki a legfontosabb titkaink.
