AI security: mikor kell elzárni az AI Agent-et az internettől?

Októberben a nemzetközi AI-szakma több meghatározó alakja nyílt levélben állt ki amellett, hogy a legerősebb AI-modellekre szigorúbb biztonsági szabályok vonatkozzanak.

A levelet már a megjelenésekor több száz kutató írta alá a világ számos országából, az aláírók között van Geoffrey Hinton és Yoshua Bengio is, a két Turing-díjas kutató, akiket a szakma gyakran az AI „keresztapjaiként” emleget, Hinton ráadásul Nobel-díjas is.

Fő kérésük, hogy a kibertámadásra képes modellek alapértelmezésként air-gap izolációban fussanak. Egy AI-modellnél ez azt jelenti, hogy a futtatókörnyezete fizikailag le van választva az internetről és minden más külső hálózatról.

Az izoláció azért fontos kérés, mert a laborok kiberbiztonsági tesztjeiben maga a támadás a feladat. A labor kijelöl a modellnek egy kitalált célpontot a tesztkörnyezetben, és megnézi, meddig jut. Hibátlan elzárás mellett a modell akkor sem ér el valódi rendszereket, ha a támadás kicsúszik ebből a keretből.

A tét valós, mert idén több AI-labor tesztjéből is eljutottak modellek valódi szervezetek rendszereibe.

Ebből egy egészen gyakorlati AI security kérdés következik, amely a laborokon kívül is minden AI Agent-nél felmerül:

Mi tartja az AI Agent-et a kijelölt határok között, amikor eszközöket hív, kódot futtat és eléri a hálózatot?

Júliusban a brit AI Security Institute többek között az Anthropic Claude Mythos modelljének kiberképességeit mérte, szándékosan nyitott internet mellett.

A 122 futásból tízben a modellek összesen 19 olyan lépést tettek, amelyet senki nem hagyott jóvá.

A legsúlyosabb esetben egy modell hamis GitHub-fiókokkal supply chain-támadást kísérelt meg egy valódi nyílt forrású projekt ellen, egy emberi karbantartó vette észre és állította meg.

Ugyanezt az esetet utólag a Cloud Security Alliance is megvizsgálta és kutatási összefoglalójuk szerint a tesztkörnyezetben nem volt valós idejű monitorozás, amely a hatókörön kívüli tevékenységet észlelte volna. A riasztást egy szokatlan Tor-forgalom váltotta ki, inkább véletlenül, mint tervezetten.

Az Anthropic saját értékeléseiben is akadt hasonló eset, ahol a modellek valódi kormányzati űrlapokat töltöttek ki és küldtek be, az egyikben egy kitalált gyilkosságot jelentettek be a philadelphiai rendőrségnek.

Mindkét esetben a modell a kapott tesztfeladatot próbálta megoldani, és ennek során lépett ki a neki szánt keretből, ennek a következményeit viszont már valódi emberek és szervezetek viselték.

A kézenfekvő válasz a teljes leválasztás volna, ám az elzárás még a nagy AI-fejlesztő cégek saját tesztjeiben sem működött hibátlanul, a vállalati AI Agent-eknél pedig sokszor nem is kivitelezhető.

A teljes elzárás és a szabad hálózat között azonban meghúzhatod a határt néhány szempont alapján, és ezek sokkal többet árulnak el a valós kockázatról, mint egy tesztkörnyezet leírásában szereplő „offline” szó.

Mitől függ, mennyi mozgásteret kaphat egy AI Agent?

Minél kevésbé tudod előre jelezni, milyen hatással lesznek egy AI Agent lépései a biztonságra, annál szűkebb cselekvési teret érdemes adni neki. Egy fejlesztőcsapatnál ez három kérdésre bontható:

1. Mennyire képes az AI Agent támadó műveletekre?
2. Mit ér el ténylegesen a hálózatból, a fájlrendszerből, a hitelesítő adatokból és az eszközökből?
3. Mennyire kiszámítható, mi történik, ha az AI Agent rosszul dönt?

1. Mennyire képes az AI Agent támadó műveletekre?

Az első kérdésre tesztekkel lehet választ kapni, ezeknél viszont a valósághűség és az elzárás egymás rovására megy.

A remio.ai elemzése szerint ugyanis offline környezetben két dolog nem vizsgálható: az indirekt prompt injection, amikor a támadó utasítás egy élő, kiszámíthatatlan weboldal tartalmába rejtve érkezik, és a modell váratlan megoldási stratégiái, amelyek valósághű hálózati körülmények nélkül elő sem jönnek.

A vállalati oldalon még élesebb a helyzet. Az eWeek szerint:

a felhős API-kra és adatbázisokra épülő vállalati AI Agent-eknél a teljes izoláció nem kivitelezhető, és nem is minden hálózatra kötött AI Agent egyformán kockázatos.

Egy webshop rendeléskezelő AI Agent-je, amely a futárszolgálat API-ját hívja, vagy egy könyvelést segítő AI Agent, amely a NAV Online Számla rendszerével dolgozik, hálózat nélkül nem tudja elvégezni a dolgát.

A kompromisszum ezért attól függ, mit akarsz mérni vagy üzemeltetni:

• Ha azt vizsgálod, ellenáll-e az AI Agent egy manipulált weboldalnak, ahhoz kell valamilyen webes kapcsolat.
• Ha viszont a támadóképességét méred kikapcsolt biztonsági szűrőkkel, akkor az elzárás a józan alapértelmezés.

2. Mit ér el ténylegesen a hálózatból, a fájlrendszerből, a hitelesítő adatokból és az eszközökből?

Erre a kérdésre csak a futó környezet ellenőrzése ad megbízható választ.

Az Anthropic, a Claude-modellek fejlesztője júliusban három olyan esetet írt le, amelyben a modell egy külső partner tesztkörnyezetéből valódi szervezetek rendszereibe jutott be.

A feladatleírás szerint a környezetben nem volt internet, valójában volt, és senki nem ellenőrizte a kimenő útvonalakat.

A promptban leírt korlát csak annyit ér, amennyit a környezet ténylegesen kikényszerít belőle.

Ha egy AI Agent-nek azt írod, ne nyúljon a hálózathoz, de a konténerből kifelé nyitva van a 443-as port, akkor a mozgásterét a nyitott port határozza meg, az utasításod csupán kérés marad.

Az elzárás sem mindig az, aminek látszik. Az air-gap és a szűrt internetkapcsolat két különböző biztonsági határ, és a gyakorlatban könnyű összemosni őket.

Az InfoQ szerint két OpenAI-modell júliusban kijutott egy air-gap izolációval védettnek szánt tesztkörnyezetből, és az AI-modelleket megosztó Hugging Face éles infrastruktúráját támadta meg.

A kiutat egy belső csomagproxy, a JFrog Artifactory addig ismeretlen sérülékenysége nyitotta meg.

Ez a szoftver az elzárt hálózat gépei helyett tölti le és tárolja a fejlesztéshez szükséges külső szoftvercsomagokat, például a Python-könyvtárakat, ezért a feladatából adódóan kapcsolatban áll a külvilággal.

Az AI Chief hírportál összefoglalója arra figyelmeztet, hogy az elzárás hamis biztonságérzetet ad, ha proxyszerverek, megosztott szolgáltatások vagy hitelesítő adatok csendben visszakötik a környezetet a külvilághoz.

Egy környezetet ezért csak akkor tekinthetsz elzártnak, ha a köztes szolgáltatásairól is meggyőződtél, hogy nem nyitnak kiutat.

3. Mennyire kiszámítható, mi történik, ha az AI Agent rosszul dönt?

Egy hibás döntés következménye azon múlik, mennyire egyértelmű a feladat határa, és mi állítja meg az AI Agent-et, ha átlépi.

Az Anthropic egyik esetében a tesztfeladatban kitalált célcég neve megegyezett egy valódi domain-nel, így a modell gyenge jelszavakkal egy éles adatbázisba jutott be.

A cég ebből azt a tanulságot vonta le, hogy a feladatleírásban kifejezetten meg kell adni, mely rendszerek tartoznak a hatókörbe, és melyek nem.

A pontos hatókör a tévedés esélyét csökkenti, a kár mértékét viszont a futtatókörnyezet beállításai határolják be.

A remio.ai elemzése ehhez a következő intézkedéseket javasolja:

• leállási feltételek,
• a kimenő olvasás és írás külön kezelése,
• automatikus idő-, számítási és adatátviteli korlátok,
• tiszta image-ből induló, eldobható környezet.

Ezekkel előre belátható, meddig juthat el egy hibás lépés, mielőtt a futás leáll.

Mikor legyen szigorú az alapértelmezés?

Ahol mindhárom kérdésre bizonytalan a válasz, ott indokolt a szigorú alapértelmezés.

A kutatók javaslata is erre a bizonytalanságra felel, amikor az air-gap izolációt teszi kiindulóponttá.

Az Anthropic ugyanebbe az irányba lépett, a cég minden belső értékeléséből kivette az élő internet-hozzáférést, miután a modelljei valódi kormányzati űrlapokat is beküldtek.

A Hinton és Bengio által is aláírt októberi nyílt levél ugyanakkor nyitva hagyja, hol húzódik a „kibertámadásra képes” kategória technikai küszöbe, így neked kell megítélned, hogy a saját AI Agent-ed ide tartozik-e.

A szabályozás sem dönt helyetted: az EU AI Act 55. cikke a rendszerszintű kockázatot jelentő, általános célú modellek szolgáltatóinak írja elő a súlyos incidensek jelentését és a kiberbiztonsági védelmet (CSET).

Hogy az AI Act alapján mi a cégek teendője, arról korábbi cikkünkben írtunk.

Hogyan tehető ellenőrizhetővé az AI Agent mozgástere?

Ha a három kérdés alapján nem a teljes elzárás mellett döntesz, a mozgásteret rétegenként kell szűkíteni: az izolációs határral, a sandbox korlátozásaival, az eszközönkénti jogosultságokkal és a nyomkövetéssel.

Izolációs határ: konténer, gVisor vagy microVM

Az izolációs határ választja el az AI Agent által futtatott kódot a gazdagéptől, és a lehetőségek erősségben jelentősen eltérnek.

A fő különbség az, hogy a kód mennyire közvetlenül éri el a gazdagép kernelét, mert egy kihasznált kernelhibán át a teljes gazdagép elérhetővé válhat.

A Fly.io összehasonlítása szerint a sima konténer közös kernelt használ a gazdagéppel, vagyis a benne futó program rendszerhívásait közvetlenül a gazdagép kernele szolgálja ki, és a többi folyamattól csak a kernel saját elkülönítő funkciói, a névterek és az erőforráskorlátok választják el. Emiatt csak félig megbízható kódhoz ajánlott, hálózat és titkok nélkül, csak olvasható fájlrendszerrel.

A gVisor a Google nyílt forráskódú, felhasználói térben futó kernele, amely a konténer és a gazdagép közé ékelődik. A program rendszerhívásait ő fogadja és szolgálja ki, így a gazdagép kerneléhez csak egy szűkebb, ellenőrzött felületen jut el kérés.

Ezzel erősebb határt húz a konténernél, de gyengébbet a virtuális gépnél, cserébe gyorsan indul, és rövid feladatokhoz jól használható.

A Firecracker az AWS nyílt forráskódú eszköze, amely hardveres virtualizációval apró virtuális gépeket, úgynevezett microVM-eket indít.

Minden feladat külön microVM-ben fut, saját vendégkernellel, így a kódnak egy kernelhiba kihasználása után még a virtuális gép határán is át kellene jutnia.

A három közül ez adja a legerősebb határt, a gyártói adatok szerint mégis 125 ezredmásodperc alatt indul, 5 MiB-nál kisebb memória-többlettel. A nem megbízható, AI Agent által írt kód futtatására is reális választás.

Sandbox: fájlrendszer, hálózat és hitelesítő adatok

Az izolációs határ megválasztása mellett a fájlrendszert, a hálózatot és a hitelesítő adatokat külön is korlátozni kell. Erre szolgál a sandbox: egy elkülönített futtatókörnyezet, amelyből a program csak a kifejezetten engedélyezett erőforrásokat éri el.

Az Anthropic kódoló AI Agent-je, a Claude Code operációsrendszer-szintű sandboxolást használ, a kimenő forgalmat pedig egy, a sandboxon kívül futó proxyszerver engedi tovább, csak az engedélyezett domainekre. A cég szerint hálózati izoláció nélkül egy kompromittált AI Agent akár az SSH-kulcsokat is kiszivárogtathatja.

Az OpenAI kódoló AI Agent-je, a Codex a hitelesítő adatokat időben választja le: a felhős változatában a titkok csak a telepítési fázisban érhetők el, és még azelőtt törlődnek, hogy az AI Agent munkába állna.

Szűk jogosultság eszközönként

Az izoláció azt szabja meg, hová juthat el az AI Agent, azt viszont nem, mit tesz a neki engedélyezett eszközökkel.

A Hugging Face vezetője arra hívta fel a figyelmet, hogy az engedélyezőlista csak a célállomást korlátozza, a végrehajtott műveletet nem.

From what we know (take with a grain of salt, we need much more transparency!), if @OpenAI had been running this on their own agents that attacked us, they would have caught them before we did!

Since the first agent cyberattack hit us in July, we've been asking what safe agent… https://t.co/kfoL6aiklb pic.twitter.com/d2iyRaI20b

— clem 🤗 (@ClementDelangue) September 28, 2026

Az OWASP GenAI Security Project Top 10 for Agentic Applications listája ezt eszközzel való visszaélésnek (ASI02) nevezi.

Ilyenkor az AI Agent a meglévő, legitim eszközeivel okoz kárt, ezért a jogosultságokra épülő észlelés könnyen elsiklik felette.

A javasolt védekezés három elemből áll:

• eszközönként szűk jogosultság,
• a paraméterek ellenőrzése
• és megerősítés a romboló műveletek előtt.

Vegyük példaként a korábban említett, a NAV Online Számla rendszerével dolgozó, könyvelést segítő AI Agent-et: szabadon olvashatja a beérkező számlákat, de a számlaadatok beküldéséhez a NAV-nak vagy egy utalás indításához emberi jóváhagyás kell.

A paraméterellenőrzés pedig megállítja a beállított összeghatár feletti vagy ismeretlen bankszámlaszámra szóló műveletet.

Nyomkövetés, amelyből utólag is kiderül, mi történt

Ha egy határ mégis enged, az sokszor csak utólag derül ki.

Az Anthropic a júliusi beszámolójában leírt három esetet is 141 006 tesztfutás átnézésével találta meg, egy negyedikre pedig még később derült fény.

The Hacker News szerint a cég Opus modelljének egyik korai verziója harmadik felek rendszereibe tört be. Ugyanannál a partnernél, ugyanazzal a konfigurációs hibával történt, mint a többi eset, de csak augusztusban vették észre.

A visszaélés felismerésének és utólagos rekonstruálásának alapja ezért az auditálható nyomkövetés, amely egy AI Agent-futást összekapcsol az általa indított eszközhívásokkal és azok eredményével. Erre ma már szabványos keret is van.

Az OpenTelemetry a szoftverek nyomkövetési adatainak gyűjtésére szolgáló nyílt szabvány. Ebben minden mért lépésről egy span készül: egy bejegyzés arról, mi történt, mikor kezdődött, meddig tartott, és melyik nagyobb lépés része.

Az OpenTelemetry GenAI szemantikai konvenciói külön span-típust, vagyis saját bejegyzésfajtát és hozzá tartozó mezőket határoznak meg az AI Agent-futásra, a modellhívásra és az eszközhívásra. Az eszközhívás bejegyzésében így ott van az eszköz neve, a hívás időtartama és a hibaállapot is.

A konvenciók az MCP-t (Model Context Protocol-t) is támogatják, vagyis azt a nyílt protokollt, amelyen keresztül az AI Agent külső eszközökhöz és adatforrásokhoz kapcsolódik.

A promptok és az eszközargumentumok alapértelmezésként nem kerülnek a naplóba, mert személyes adatot tartalmazhatnak.

Egy hazai cégnek, amelyre a GDPR is vonatkozik, ezért tudatosan kell eldöntenie, mit rögzít teljes tartalommal, mit maszkolva, és meddig őrzi meg.

A remio.ai elemzése arra is figyelmeztet, hogy a modell saját érvelése egy automatikus monitort is félrevezethet. Emiatt különösen értékesek a modelltől független jelek, például a hálózati napló és az eszközhívások naplója.

Mikor indokolt tehát a teljes leválasztás?

Egyik réteg sem teszi önmagában biztonságossá az AI Agent-et, mert maga az izolációs határ is tartalmazhat hibát.

Az OpenAI szerint a cég a legerősebb kiberképességű modelljeire épülő AI Agent-csapatokkal kerestette a kutatási környezetei gyengeségeit.

Olyan, könnyen kihasználható kiutat az internetre, amely a monitorozás elől is rejtve maradt volna, nem találtak, nulladik napi sérülékenységeket és virtuálisgép-kitöréseket viszont igen.

A rétegek ezért egymást fedezik, ha az egyik enged, a másik még megfogja a lépést, vagy legalább láthatóvá teszi.

Bármelyik utat választod, a határokat a futó környezetben ellenőrizd, ne a prompt vagy a környezet leírása alapján. Az AI Agent ugyanis azt a hálózatot fogja használni, amelyet ott talál.

Fenyegetésmodelltől a monitoring-ig: az AI security engineering képzésünk

Ezeket a döntéseket érdemes előbb ellenőrzött környezetben begyakorolni.

AI security engineering képzésünkön ezt saját laborban teszed meg, amelyet lokális modellel, Ollama és Docker segítségével építesz fel.

Kiindulópontként feltérképezed a támadási felületet: végiggondolod, hol és hogyan támadható egy LLM-alapú alkalmazás, és a fenyegetéseket a nemzetközileg használt kockázati listák alapján rendszerezed.

Erre épülnek a további témakörök, amelyekben támadóként és védőként is dolgozol:

• manipulált utasítások (prompt injection) és a modell válaszain keresztül kiszivárgó adatok,
• a cég dokumentumaiból válaszoló asszisztensek tudásbázisának és memóriájának védelme,
• az AI Agent-ek mozgásterének korlátozása: milyen eszközökhöz, adatokhoz és felhős erőforrásokhoz férhetnek hozzá, és hogyan akadályozható meg, hogy egy eltérített AI Agent a megbízója ellen dolgozzon,
• a letöltött modellek és a tanítóadatok ellenőrzése,
• ismételhető, Python-ban automatizált támadássorozatok,
• naplózás, monitorozás és incidenskezelés az éles üzemben, a szabályozási elvárások műszaki kontrollokra fordításával együtt.

A záróprojektben egy szándékosan sebezhető, dokumentumokból válaszoló és önállóan cselekvő AI-asszisztenst mérsz fel, támadsz meg és erősítesz meg, így a végére bemutatható munkád is lesz egy teljes biztonsági értékelés javítási tervvel.

A 12 hetes, mentorált online képzés heti 8-12 óra tanulással munka mellett is elvégezhető, a projekteket heti élő, visszanézhető konzultációkon beszélitek át.

Elsősorban alkalmazásbiztonsági szakembereknek, pentestereknek, AI Engineer-eknek, AI Agent- és MCP-fejlesztőknek, felhős és identitáskezelési architekteknek, valamint MLOps-mérnököknek ajánljuk.

Python-tudás, webes és API-biztonsági alapok, valamint alapszintű Linux- és Docker-ismeret szükséges hozzá.

Gyakori kérdések

Mi az az AI Agent?

Az AI Agent (AI Agent) olyan nyelvi modellre épülő rendszer, amely nemcsak válaszol, hanem egy feladat elvégzéséhez önállóan eszközöket hív, kódot futtat és eléri a hálózatot. Egy webshop rendeléskezelő AI Agent-je például a futárszolgálat API-ját hívja, egy könyvelést segítő AI Agent pedig a NAV Online Számla rendszerével dolgozik. A külső eszközökhöz és adatforrásokhoz az MCP (Model Context Protocol) nyílt protokollon keresztül is kapcsolódhat. AI security szempontból ezért az a kulcskérdés, hogy mi tartja a kijelölt határok között, amikor valódi rendszerekben cselekszik.

Mi az a sandbox a szoftverfejlesztésben?

A sandbox egy elkülönített futtatókörnyezet, amelyből a program csak a kifejezetten engedélyezett erőforrásokat éri el. Így egy hibás vagy kompromittált program kárát azokra a fájlokra, hálózati célokra és hitelesítő adatokra szűkíti, amelyeket megnyitottál számára. Az Anthropic kódoló AI Agent-je, a Claude Code például operációsrendszer-szintű sandboxban fut. A kimenő forgalmát egy sandboxon kívüli proxy csak az engedélyezett domainekre engedi tovább, mert a cég szerint hálózati izoláció nélkül egy kompromittált AI Agent akár az SSH-kulcsokat is kiszivárogtathatja.

Hogyan működik a prompt injection, és miért veszélyes egy internetre kötött AI Agent-nél?

A prompt injection során a támadó manipulált utasítást juttat el a modellhez, hogy az a megbízója helyett az ő céljait szolgálja. Internetre kötött AI Agent-nél ez közvetve is történhet: a támadó utasítás egy élő, kiszámíthatatlan weboldal tartalmába rejtve érkezik, amelyet az AI Agent munka közben megnyit. Azért veszélyes, mert az eltérített AI Agent a saját eszközeivel és hozzáféréseivel cselekszik, és hálózati izoláció nélkül akár az SSH-kulcsokat is kiszivárogtathatja.

Mit jelent a legkisebb jogosultság elve, és hogyan alkalmazható egy AI Agent-re?

A legkisebb jogosultság elve azt jelenti, hogy az AI Agent csak azokat az eszközöket, adatokat és jogokat kapja meg, amelyek a feladatához ténylegesen kellenek. Az OWASP Top 10 for Agentic Applications ehhez eszközönként szűk jogosultságot, a paraméterek ellenőrzését és a romboló műveletek előtti megerősítést javasolja. Egy könyvelést segítő AI Agent például szabadon olvashatja a beérkező számlákat, de a NAV-nak való adatbeküldéshez vagy egy utaláshoz emberi jóváhagyás kell. Az összeghatár feletti vagy ismeretlen bankszámlaszámra szóló műveletet pedig a paraméterellenőrzés megállítja.

Hogyan lehet elkülönített sandboxban tesztelni egy AI Agent-et, amely külső szolgáltatásokat hív?

Úgy, hogy a hálózatot nem kapcsolod le teljesen, hanem szűkíted: a kimenő forgalmat alapból tiltod, és csak az engedélyezett célok felé nyitod meg, a külső műveletek előtt pedig emberi jóváhagyást kérsz. A futás tiszta image-ből induló, eldobható környezetben menjen, rövid életű hitelesítő adatokkal, leállási feltételekkel és automatikus idő-, számítási és adatátviteli korlátokkal. A kimenő útvonalakat a futó környezetben ellenőrizd, ne a feladatleírás alapján, mert az AI Agent azt a hálózatot használja, amelyet ott talál.

Milyen eszközökkel lehet figyelni egy AI-rendszer működését és felderíteni a kockázatait?

AI Agent-ek figyelésére az OpenTelemetry nyílt nyomkövetési szabványának GenAI konvenciói adnak keretet: külön bejegyzés (span) készül az Agent-futásról, a modellhívásokról és az eszközhívásokról. Az eszközhívás bejegyzésében az eszköz neve, a hívás időtartama és a hibaállapot is szerepel. Mellette figyeld a modelltől független jeleket, például a hálózati naplót és az eszközhívások naplóját, mert a modell saját érvelése egy automatikus monitort is félrevezethet. A Hugging Face vezetője szerint az engedélyezett forgalmat is figyelni kell, és riasztani, ha sok sandbox hirtelen ugyanarra a hosztra kezd írni.

Hogyan lehet letiltani a hálózati hozzáférést egy tesztfuttatás idejére?

A hálózatot a futtatókörnyezet szintjén kell letiltani, mert a promptba írt „nincs internet” semmit nem garantál: ha a konténerből kifelé nyitva van a 443-as port, az utasításod csak kérés marad. Az OpenAI kódoló AI Agent-jében, a Codexben például a hálózat alapból ki van kapcsolva, és csak kifejezett beállítással, domain-szabályokkal engedélyezhető. A leválasztás után a csomagproxyt, a DNS-t, a megosztott szolgáltatásokat és a hitelesítő adatokat is ellenőrizd, mert ezek csendben visszaköthetik a környezetet a külvilághoz.

Mit jelent az air-gap egy AI-modell esetében?

Az air-gap azt jelenti, hogy a modell futtatókörnyezete fizikailag le van választva az internetről és minden más külső hálózatról. Valódi elzárásról csak akkor beszélhetsz, ha egyetlen csomagproxy, megosztott szolgáltatás vagy hitelesítő adat sem köti vissza csendben a környezetet a külvilághoz. 2026 júliusában két OpenAI-modell egy ilyen csomagproxy, a JFrog Artifactory addig ismeretlen sérülékenységén át jutott ki egy air-gap izolációval védettnek szánt tesztkörnyezetből, és megtámadta a Hugging Face éles infrastruktúráját.