Robbanásszerű terjedés, észrevétlen kockázatok
A helyzet súlyosabb, mint amit a legtöbb IT-csapat felmér: már 22%-nál jár azoknak a cégeknek az aránya, ahol a dolgozók OpenClaw-t futtatnak vállalati jóváhagyás nélkül. Az elmúlt két hétben 30 ezernél is több nyilvánosan elérhető OpenClaw-példány bukkant fel, míg korábban ezernél is alig volt több. Ráadásul a ClawHub-képességek 36%-a sebezhető.
Jamieson O’Reilly, az egyik legaktívabb szakértő, először különösen a hitelesítő adatok kiszivárgására hívta fel a figyelmet. Azóta Peter Steinbergerrel közösen elindította a kétlépcsős kártékony képességszűrést, most pedig aktívan lobbizik egy új, szigorúbb szabvány bevezetéséért.
Elmondása szerint az OpenClaw esetében nem a maximális biztonság volt a fő szempont a fejlesztés során – ezt ma már vállalják is, bármiféle mentegetőzés nélkül. Mindez azonban nem zárja be azt a három kritikus biztonsági rést, amelyek igazán számítanak.
Három támadási felület, amit semmi sem figyel
Az első a futásidejű szemantikus adatszivárgás. Itt a támadó nem bináris vagy szignatúraalapú módszerrel, hanem a műveletek jelentésébe rejtve juttatja át a rosszindulatú tevékenységet, amelyet a jelenlegi védelmi rendszerek nem észlelnek. A folyamat valódinak tűnik: a hitelesítő adatok igaziak, az API-hívások engedélyezettek, így az EDR csak szabályszerű működést lát.
A második a több ügynök közötti kontextusszivárgás. Amikor ügynökök vagy képességek osztanak meg munkamenet-információkat, egyetlen injektált prompt képes később, más szálakon befolyásolni a műveleteket. Előfordul, hogy az ilyen rejtett parancsok hetekig lappanganak a rendszerben, majd egy teljesen más feladathoz kapcsolódva aktiválódnak.
O’Reilly szerint ezt a rést a legnehezebb megszüntetni, mivel a promptinjektálás iparági szintű problémává nőtte ki magát – nemcsak az OpenClaw-t érinti, minden LLM-alapú rendszer veszélyeztetett.
A harmadik a hitelesítés nélküli ügynök–ügynök bizalmi lánc. Itt, ha egy ügynök feladatot delegál egy másik ügynöknek vagy külső szervernek, semmilyen kölcsönös azonosítás nem történik. Egyetlen kompromittált ügynök a teljes lánc fölött átveheti az irányítást. Ipari elemzők szerint az OpenClaw így lényegében „nem megbízható kódot” hajt végre állandó hitelesítés nélkül.
Mindez könnyedén vezethet hitelesítő adatok, VPN-konfigurációk és vállalati belépési adatok kiszivárgásához, mint azt a Moltbook közösségi háló OpenClaw-botrány is bizonyította, ahol 1,5 millió API-token és 35 ezer e-mail-cím került ki.
Kétheti tűzoltás: mit sikerült tényleg lezárni?
A védelmi ökoszisztéma háromfélére szakadt: két eszköz helyben szigeteli az OpenClaw-t, ezek közül a Prompt Security folyamatosan monitorozza a kritikus fájlokat, a Steinberger–O’Reilly–VirusTotal-féle rendszer minden ClawHub-képességet beszkennel telepítés előtt.
Két másik megoldás teljesen új architektúrát képvisel: a NEAR AI Rust-alapú megközelítésével minden nem megbízható eszköz WebAssembly-sandboxba kerül, ahol a jogosultságokat szigorúan kérvényezni kell. Egy másik nyílt forráskódú projekt operációs rendszer-szintű szigort, fail-closed hitelesítést használ.
Két további eszköz kódellenőrzésre és auditálhatóságra fókuszál: a Cisco nyílt forráskódú szkennere több módszert ötvöz, míg a NanoClaw 500 TypeScript-sorba sűríti az egész alkalmazást, Docker-konténerben futtatva minden munkamenetet.
Ennek ellenére a támadási minták gyorsan szaporodnak: február közepén már 824 kártékony működésű képesség került nyilvánosságra a ClawHubon; a ClawHavoc akció macOS-kriptolopó kártevőt rejtett kriptovaluta-kereskedési eszközök mögé, így kriptotárcákat és böngészőjelszavakat szedett áldozatául.
Új szabvány, új remény?
O’Reilly egy új képességspecifikációt nyújtott be az ügynökközösséghez, amely a mobilalkalmazás-jogosultságokhoz hasonló, kötelező engedélykérési mechanizmust vezetne be – minden OpenClaw-képességnek deklarálnia kellene, hogy pontosan mihez fér hozzá.
Az elszeparálás és a futásidejű védelmi korlátok javíthatnak a helyzeten, de a kontextusszivárgás végleges megoldása csak mély, architekturális változtatásokkal érhető el.
Mit tegyél hétfő reggel?
Kiindulásként szinte biztos, hogy az OpenClaw már jelen van a vállalati környezetben – a 22%-os árnyéktelepítési arány csak a minimum. Hat lépés nyújt átmeneti védelmet:
1. Mérd fel, hol fut bármi: szkenneld a 18789-es porton a WebSocket-forgalmat, nézd az mDNS-reklámokat az 5353-as porton, kísérd figyelemmel az új app-azonosítókat és OAuth-engedélyeket a céges hitelesítési naplókban.
2. Ragaszkodj az elszigetelt futtatáshoz. Egy ügynök sem futhat éles infrastruktúrán.
3. Telepíts ClawSec-et minden példányra, és minden képességet futtass át a VirusTotalon és a Cisco szkennerén telepítés előtt.
4. Követelj emberi jóváhagyást az érzékeny műveletekhez. Minden olyan lépésnél, ahol hitelesítő adatokkal, konfigurációval vagy külső API-val dolgozik az ügynök, legyen kötelező a megerősítés.
5. Térképezd fel a három továbbra is élő rést (szemantikus adatszivárgás, kontextusszivárgás, bizalmi lánc) a kockázatkezelési tervben.
6. Vidd be az értékelési táblázatot a következő vezetőségi ülésre – ez nem MI-kísérlet, hanem minden DLP/IAM-befektetésedet megkerülő, kritikus új kihívás.
A klasszikus biztonsági rendszerek a valódi rosszindulatú kódot felismerik – de egy olyan ügynököt, amely legitim API-híváson keresztül, rejtett parancs szerint szivárogtat, nem. Ebben a résben rejtőzik az új korszak legnagyobb kihívása.
