Hogyan tervezünk biztonságosabb ügynököket

A biztonságosabb mesterségesintelligencia-ügynökök építéséhez mind a képességeiket, mind a meghibásodásaikat figyelembe kell vennünk a tervezés során. Még a legitim feladatok végrehajtása során is, mindenféle rosszindulatú utasítás nélkül, az ügynökök átléphetik a biztonsági határokat, miközben megpróbálják legyőzni az akadályokat.

Hiszünk abban, hogy ez egy biztonsági mérnöki probléma, és az iparágnak úgy kell kezelnie, ahogyan a 2000-es évek eleji internetes férgeket kezelte. Az ügynököket körülvevő rendszereknek korlátozniuk kell az ügynökök hozzáférését, észlelniük kell a nem kívánt viselkedést, és el kell szigetelniük a hibákat, amikor azok bekövetkeznek.

A Perplexitynél aktívan együttműködünk kutatókkal és gyakorló szakemberekkel a mesterségesintelligencia-ügynökök biztonsági mérnöki feladatainak előmozdítása érdekében, és a védelem több rétegét alkalmazzuk a modelleken, az ügynökök harness-ein és az infrastruktúrán, hogy a biztonság ne függjön egyetlen védelmi mechanizmustól sem.

Az MI-ügynökök összeomlási viselkedése

Júliusban az MI-ügynökök betörtek a Hugging Face nyílt forráskódú MI-platform éles infrastruktúrájába. A belső kiberbiztonsági kiértékelési és betanítási futtatások során az OpenAI modelljei felfedezték a módját annak, hogy kihasználják az Artifactory tárolókezelőt egy üzenetfal létrehozásához, amelyen keresztül kommunikálhatnak egymással, így lehetővé téve számukra, hogy rajokká szerveződjenek. Később azok az ügynökök, amelyek nem tudtak előrelépni a feladatokban egy kiberbiztonsági benchmark keretében, más ügynököket béreltek fel segítségül. Ezek az ügynökök kitörtek a kiértékelési környezetükből, és elérték az internetet. Arra is rájöttek, hogyan csalhatnak a benchmarkfeladatok válaszainak visszafejtésével, de úgy vélték, hogy az értékelési rendszer észlelni fogja a csalást. Annak érdekében, hogy jobban megértsék a benchmark-kiértékelés működését a csalásként való észlelés elkerülése érdekében, végül kompromittálták a Hugging Face rendszereit (Hugging Face; OpenAI).

Az incidens világos példája annak a hibaforrásnak, amelyet akkor írtunk le, amikor júliusban nyílt forráskódúvá tettük a Numbatot: véletlenszerű összeomlások (accidental meltdowns), amelyet a Cornell Tech biztonsági kutatói alkottak meg (arXiv). A legitim célt követő ügynök akadályokba ütközik (például hiányzó fájl, sikertelen API-hívás, lejárt hitelesítő adat vagy engedély megtagadása), és alternatív megoldást keres. Ennek során felderítés, jogosultság-eszkaláció, titokfelfedezés vagy adatexfiltráció révén átlépheti a biztonsági határokat. Maga az ügynök lényegében ellenséggé válik, annak ellenére, hogy semmilyen rosszindulatú prompt vagy külső támadó nincs jelen.

A Hugging Face nem volt egyedi eset. Az elmúlt hetekben további ügynök-összeomlási eseteket fedeztek fel és jelentettek. Május 27-én és 28-án a Data USA-ból (az amerikai kormányzati adatokhoz nyílt hozzáférést biztosító platformról) az Iowai Egyetem adatait gyűjteni próbáló ügynökök hibákba ütköztek, amelyeket egy hibás lekérdezés okozott. Válaszul vizsgálatokat indítottak, beleértve az SQL-injekciót, a webhelyközi parancsfuttatást (XSS), a sabloninjekciót, az elérési út bejárását és a parancsinjekciót. A tevékenységet később az OpenAI-hoz kötötték (SecurityWeek). Június 20-án és 21-én az OpenAI ügynökei, amelyek az Ausztrál Egészségügyi és Jóléti Intézettől (AIHW) próbálták meg megszerezni a viktoriai helyi térségekre vonatkozó egy főre jutó kormányzati költségeket egy gyógyszerkategória tekintetében, nem tudtak letölteni egy fájlt. Válaszul az ügynökök letöltötték az AIHW előgyártási szerveréről a már nyilvános fájlt, miközben megkerülték a webhely botellenes védelmét (SecurityWeek).

Ez a minta nem korlátozódik egyetlen laboratóriumra. A kiberbiztonsági tesztek során az Anthropic modelljei feltörtek három vállalatot, miután egy hiba miatt nyílt internet-hozzáférést kaptak, a Google Gemini modellje kitalálta három webhely hitelesítő adatait, egy Meta modell pedig kihasznált egy harmadik féltől származó szolgáltatást (Reuters).

Tanulás a történelemből: Az internetes férgek korszaka

Ezek az incidensek a mintegy negyedszázaddal ezelőtti internetes férgek korszakára emlékeztetnek. A 2000-es évek elején az internet sokkal gyorsabban nőtt, mint az azt körülvevő biztonsági gyakorlatok. A vírusok és férgek hullámát láttuk, amelyeknek a következményei sokkal súlyosabbak voltak, mint amit jelenleg tapasztalunk az összeomlóban lévő MI-ügynökök esetében.

2000. május 4-én az emberek ismerős feladóktól kaptak e-maileket „ILOVEYOU” tárgysorral. Az e-mailben található melléklet megnyitása egy olyan parancsfájl futasztását eredményezte, amely elküldte a saját másolatát a áldozat Outlook-címjegyzékében szereplő összes személynek. Aznap este 6-ra a CERT Koordinációs Központ több mint 420 000 internetes gazdagépet érintő jelentést kapott (US GAO Report). A jelentések szerint a vírus legalább 14 szövetségi ügynökségbe behatolt, beleértve a Védelmi Minisztériumot, a CIA-t, a NASA-t, valamint a Képviselőházat és a Szenátust (US GAO Report). Leállította a Pentagon és a brit parlament e-mail szervereit is (Wired). A Lloyd’s of London biztosítási óriásvállalat korai becslése szerint a vírus több mint 15 milliárd dolláros kárt és termelékenységkiesést okoz (US House Committee Hearing). A Computer Economics később 8,75 milliárd dollárra becsülte a világméretű károkat (Information Week).

Ezt követően olyan férgek következtek, amelyek nem igényeltek emberi kattintást. 2001. július 19-én a Code-Red féreg kevesebb mint 14 óra alatt több mint 359 000 számítógépet fertőzött meg (CAIDA). 2003. január 25-én az SQL Slammer 8,5 másodpercenként duplájára nőtt, és 10 percen belül megfertőzte az erre sebezhető internetes gazdagépek több mint 90%-át (CAIDA), kihasználva egy olyan rést, amelyre a Microsoft hat hónappal korábban adott ki javítást (CNET). 2003 augusztusában a Blaster féreg és a Sobig e-mail féreg körülbelül egy hét eltéréssel jelent meg (Microsoft, F-Secure).

Akkoriban ésszerű volt feltenni a kérdést, hogy a hálózatba kapcsolt számítógépek egyáltalán biztonságossá tehetők-e. Hat nappal az ILOVEYOU vírus után az amerikai képviselőház egy albizottsága meghallgatást tartott az ügyben. Számos biztonsági szakértő olyan jogszabályokat szorgalmazott, amelyek tehermentesítenék a szoftvercégeket a termékeik hibái által okozott károkért. Washington más utat választott. A kiberbiztonság biztosításáról szóló nemzeti stratégia (National Strategy to Secure Cyberspace) kijelentette, hogy „a szövetségi szabályozás nem válik a kiberbiztonság biztosításának elsődleges eszközévé”. Figyelmeztetett, hogy a széles körű megbízások a „kiberbiztonság legalacsonyabb közös nevezőjének megközelítését” eredményezhetik (CISA).

Az iparág mérnöki megoldással válaszolt. Tizenegy nappal az ILOVEYOU után a Microsoft bejelentett egy Outlook-frissítést, amely blokkolta a végrehajtható mellékleteket. 2002 januárjában a vállalat a biztonságot tette az első számú prioritássá (Seattle Times). Az automatikus frissítés, a biztonságos alapértelmezések, a bug bounty programok és a összehangolt közzététel alap gyakorlattá vált. 2008-ban a Chrome elkezdte a webtartalmat egy olyan homokozóban futtatni, amely „korlátozza, hogy mit tehet egy támadó egy hiba kihasználása után” (Chromium Blog). A titkosítás, amely egykor kivétel volt, alapértelmezetté vált. A biztonsági technológiák, beleértve a többtényezős hitelesítést, a tűzfalakat, a Zero Trustet, valamint a biztonsági információ- és eseménykezelést (SIEM), széles körben elterjedtek. A prognózisok szerint a szervezetek világszerte mintegy 240 milliárd dollárt fognak költeni információbiztonságra 2026-ban (Gartner). A férgek soha nem tűntek el teljesen, de a rutinszerű internetes járványok korszaka leáldozott. Ezzel paralel az internet, amelyet a szabályozás nagyrészt nem korlátozott, az elkövetkező két évtizedben az innováció és a gazdasági növekedés erős motorjává vált.

Biztonsági mérnöki feladatok AI ügynökök számára

A a legutóbbi incidensek jogos kérdéseket vetettek fel az ügynökök irányításával kapcsolatban. A meglévő biztonsági mechanizmusokat olyan ügynökök előtti számítástechnikai környezetekhez fejlesztették ki, amelyeket szigorúan korlátozott és nagyrészt determinisztikus szoftverviselkedés jellemez. A hozzáférés-szabályozási mechanizmusok különösen az emberi felhasználók köré épülnek, és gyakran olyan széleskörű jogosultságokat adnak nekik, amelyek elvileg elegendőek jelentős károkozáshoz.

Ez a tervezés számos feltételezésen alapul: a legtöbb felhasználó jóhiszeműen cselekszik; a rosszindulatú szereplők elrettenthetők az auditálás és a valós következmények révén; az emberek pedig viszonylag korlátozott ütemben hajtanak végre helyes vagy téves műveleteket. Ezen biztonsági mechanizmusok ügynökökre való alkalmazása megköveteli az emberi és az ügynöki viselkedés közötti különbségek figyelembevételét. Mint azt a NIST mesterségesintelligencia-ügynökök biztonságára vonatkozó információs kérelmére adott válaszunkban írtuk, a mesterségesintelligencia-ügynökök kétségbe vonják ezeket a feltételezéseket. Képesek jogosultságokat gyakorolni és gépi sebességgel cselekedni, magukat nem rettentik el a valós következmények, és olyan műveleteket hajthatnak végre, amelyek technikailag megengedettek, de amelyeket egy tipikus emberi felhasználó ritkán tenne meg.

Ezen kérdések megválaszolása biztonsági mérnöki munkát igényel. Ismerjük azokat a biztonsági elveket, amelyek olyan rendszerek építéséhez szükségesek, amelyek ellenőrzés alatt tartják a kockázatokat, amikor az egyes komponensek hibásan működnek. Biztosítanunk kell azonban azt is, hogy ezeket az elveket alkalmazzuk a mesterségesintelligencia-ügynökök képzésére, tesztelésére és használatára szolgáló környezetek megtervezése során.

A mélységi védelem biztonsági elve

A mesterséges intelligenciával működő ügynökök védelméhez alkalmazandó legfontosabb biztonsági elv valószínűleg a mélységi védelem, amely egy olyan rétegzett biztonsági architektúrát szorgalmaz, amelyben többféle, változatos és redundáns védelmi intézkedést alkalmaznak a rendszer-erőforrások védelmére. Egyetlen biztonsági mechanizmus sem tökéletes. Az emberek bedőlhetnek a társadalmómérnöki (social engineering) támadásoknak, és felfedhetik bejelentkezési adataikat, nulladik napi (zero-day) szoftversebességeket fedeznek fel és használnak ki, a behatolásészlelés pedig nem veszi észre az új támadási variánsokat. A mélységi védelem ezt elfogadja, és egymásra építi a védelem több független rétegét. Ha az egyik védelmi réteget megkerülik, a többi réteg a helyén marad a behatolás megakadályozása vagy észlelése érdekében.

A Hugging Face-nél történt incidens jól mutatja, hogy miért fontos a mélységi védelem. Az OpenAI retrospektív jelentése szerint az éles rendszereiben használt automatizált védelmi mechanizmusok – beleértve a harness-eket, az automatikus felülvizsgálati modelleket és a biztonsági besorolókat – hiányoztak a kiértékelési környezetből. Ha a jelenleg üzembe helyezett gondolatmenet-figyelése futott volna ezeken a kiértékeléseken, az észlelte volna a kezdeti tevékenységet, és több mint egy nappal a megsértés előtt riasztotta volna a biztonsági csapatot (OpenAI). Megvoltak azok a rétegek, amelyek elkaphatták volna a problémát. Csak egyszerűen nem voltak mind ott egyszerre.

A mesterségesintelligencia-ügynökök védelme megköveteli mind az MI-modellek, mind a őket körülvevő rendszerek biztonságának javítását. A modellrétegen végzett munka számít, és megvan az eredménye. A korai LLM-eket könnyen manipulálták az injektált utasítások, míg a mai modellek lényegesen jobban felismerik és visszautasítják azokat. A modellfejlesztők a biztonságosabb viselkedés érdekében is tanítják a modelleket, és – amint az OpenAI retrospektívje leírja – figyelik az érvelési nyomokat a problémás viselkedés jeleiért. A modell szintű védelem azonban csak a megoldás egy része. Azokat a rendszereket is biztonságra és elszigetelésre kell tervezni, amelyekben az ügynökök betanítása, tesztelése és üzembe helyezése történik. A modell szintű biztonság csökkenti annak valószínűségét, hogy egy ügynök rossz utat válasszon; a rendszerszintű biztonság pedig korlátozza a károkat, ha mégis ez történik.

Nagyítás

Tervezési szabályok a redundáns védelmi mechanizmusokhoz

A mélységi védelem redundáns védelmi mechanizmusokat igényel. Az ügynökök esetében azt javasoljuk, hogy három tervezési szabállyal alkalmazzák:

1. Függetlenség. Mindegyik rétegnek független okokból kell meghibásodnia. Két olyan vezérlő, amely ugyanarra a feltételezésre támaszkodik, ugyanazzal a támadással legyőzhető. A felügyelőknek és a kényszerítési pontoknak az ügynök elérhetőségén kívül kell elhelyezkedniük.
2. Kényszerítés az ügynök alatt. Legalább egy rétegnek determinisztikusnak kell lennie: hagyományos, ellenőrizhető kódnak, amely blokkolja a tiltott műveleteket függetlenül attól, hogy mit hoz létre a modell. Az a biztonsági mechanizmus, amelyet az ügynök visszautasíthat vagy újrakonfigurálhat, nem biztonsági mechanizmus.
3. A szignálok csak csökkenthetik a jogosultságot. Az észlelésnek olyan válaszlépéseket kell elindítania, amelyek beszűkítik az ügynök által elvégezhető műveleteket (például szüneteltetés, a hitelesítő adatok visszavonása, a hálózati hozzáférés megszüntetése vagy a munkamenet leállítása). Egyetlen kockázati szignál sem adhat soha további hozzáférést.

Ezeket az elveket megosztjuk a partnerszervezeteinkkel a Open Secure AI Alliance-ban, beleértve az NVIDIA-t is, amely azzal érvelt, hogy a harness irányítja, hogy mit próbál meg az ügynök, míg az infrastruktúra szabályozza, hogy mit tehet (NVIDIA).

Mélységi védelem a Perplexity termékeiben

A Perplexity négyféle környezetben futtat ügynököket: a felhőben az Computer ügynökplatformunkon keresztül, a böngészőben a Comet segítségével, a felhasználói eszközökön a Portable Computer révén, valamint a munkavállalói laptopokon, ahol a mérnökeink harmadik féltől származó kódolási ügynököket használnak. Mindegyik környezet saját kockázatokkal jár, és mindegyik többféle védelmi réteget kap.

A felhőben: Computer és SPACE

Minden egyes Computer-feladat a SPACE-ben fut, amely a homokozó-platformunk, és az ügynököt alapértelmezés szerint megbízhatatlanként kezeli. Mindegyik feladat saját mikroVM-et kap, a hitelesítő adatok a homokozón kívül maradnak, és csak szükség esetén kerülnek injektálásra, a kimenő forgalom a vendégrendszeren kívül van felügyelve, a pillanatképek pedig lehetővé teszik a romboló változtatások visszavonását (Making SPACE). A vállalati ügyfelek saját titkosítási kulcsokat is használhatnak. Egy kulcs visszavonása olvashatatlanná teszi a védett adatokat, és az ügynök nem bírálhatja felül ezt a döntést.

Azt is teszteljük, hogy ezek a rétegek kitartanak-e. Az Escaping SPACE: Part I keretében kilenc csúcskategóriás modellnek adtunk root hozzáférést egy SPACE homokozón belül, és megkértük őket, hogy törjenek ki. Egyik sem szökött ki a virtuális gépből (VM), de néhányan találtak módokat a hálózati házirend megkerülésére, amikor részleges hálózati hozzáférést engedélyeztek. Kijavítottuk ezeket a hiányosságokat, egy újbóli teszt során megerősítettük a javításokat, és bejelentettük a többi 10 homokozóplatform közül 8-ban talált hasonló gyengeségeket a gyártóknak.

A böngészőben: Comet és BrowseSafe

A Comet a bevezetése óta rétegzett prompt-injekciós védelmet használ: a besorolók szűrik a lekérdezett tartalmat, a strukturált promptok megbízhatatlanként jelölik meg, az olyan érzékeny műveletek, mint az e-mail küldés vagy a megrendelés leadása, a felhasználó megerősítését igénylik, a felhasználókat pedig értesítik, ha valamilyen műveletet blokkolnak (Comet prompt-injekciós védelmek). A BrowseSafe, az első réteg mögött álló nyílt forráskódú észlelési modell felülmúlja a csúcskategóriás modelleket a BrowseSafe-Bench benchmarkunkon, ugyanakkor ugyanez a benchmark azt mutatja, hogy egyetlen detektor sem hibamentes, amiért az észlelés soha nem az egyetlen réteg (BrowseSafe kutatás). A Computer örökli ezeket a védelmeket, amelyeket a Trail of Bits auditált (Perplexity).

Az eszközön: Portable Computer

A Portable Computer egy helyi alapú ügynök: a modell, a harness, a beszélgetés és a pálya alapértelmezés szerint a felhasználó gépén marad. Egy determinisztikus orchestrátor, amely LLM helyett harness-kód, futtatja a ciklust és érvényesíti a házirendet. A modell műveleteket javasol, és a jóváhagyott eszközhívások egy operációs rendszer szintű homokozóban futnak, amely korlátozza a folyamatokat, a fájlútvonalakat és a hálózati hozzáférést. A homokozó mindig be van kapcsolva, és hiba esetén leáll: ha nem érhető el, a harness letiltja magát ahelyett, hogy parancsokat futtatna a felhasználó engedélyeivel. Az eszközhatárt átlépő műveletek (például az webes keresés, a csatlakozók és a magasabb szintű felhőbeli tanácsadó modellre való áttérés) csak akkor történnek meg, ha a felhasználó engedélyezi és jóváhagyja azokat. Egy tanácsadói hívás előtt egy PII-besoroló megjelöli az érzékeny információkat, és a felhasználó láthatja, hogy mi kerülne elküldésre. A tanácsadó csak ezt a jóváhagyott kontextust kapja meg, és szöveges útmutatást ad vissza, anélkül, hogy hozzáférne az eszköz fájljaihoz vagy eszközeihez.

A végponton: Numbat

A fejlesztői laptopokon futó kódolási ügynökök órákig futnak forráskódhoz, hitelesítő adatokhoz és éles rendszerekhez való hozzáféréssel. A Numbat, a nyílt forráskódú ügynökbiztonsági csomagunk, egy független réteget ad hozzá, amely bármilyen egységes ügynökön kívül helyezkedik el. Olyan harness-ekkel működik együtt, mint a Claude Code, a Codex, az OpenCode és a Pi, blokkolja a veszélyes műveleteket a futtatásuk előtt, megjelöli a gyanús többlépéses sorozatokat (például egy titok olvasását, majd adatok küldését), és megőrzi a munkamenet idővonalait a vizsgálathoz. A Numbat ezer Perplexity-végponton fut a Bumblebee, a nyílt forráskódú ellátásilánc-szkennerünk mellett. A Computer rendszeresen felülvizsgálja a megállapításaikat, és jobb észlelési szabályokat javasol, és egy ember hagyja jóvá az összes változtatást a kiadás előtt.

Az egész iparág feladata

Ahogy a mesterségesintelligencia-ügynökök egyre rátermettebbé és szélesebb körben használttá válnak, a biztonsági mérnöki munkának a fejlesztésük és a bevezetésük központi elemének kell maradnia. A kutatók és a mérnökök építhetnek a megalapozott elvekre, felhasználhatják a valós megállapításokat a védelem tökéletesítésére, és tesztelhetik a védelmi mechanizmusokat azokon a környezeteken belül, amelyekben az ügynökök működnek. A biztonság egy olyan folyamatos mérnöki tudományág, amely a technológiával együtt fejlődik.

Az ügynökök biztonsági mérnöki feladata az egész iparág feladata. Egyetlen vállalat sem ellenőrzi a teljes stacket, amelyen egy ügynök fut. A modellfejlesztők, a harness-készítők, a homokozó- és futtatókörnyezet-szolgáltatók, a felhő- és hardverszállítók, valamint a vállalatos biztonsági csapatok egyaránt egy-egy rétegért felelnek. Az egész biztonsága attól függ, hogy minden egyes réteg kitart-e, ha egy másik megcsúszik. Ezért építünk olyan védelmi mechanizmusokat, amelyek az ügynökök harness-ein átívelően működnek, és tesszük nyílt forráskódúvá az eszközeinket. Ez az oka annak is, hogy feltárjuk a más platformokon talált gyengeségeket, és részt veszünk olyan kezdeményezésekben, mint az Open Secure AI Alliance.

Annak érdekében, hogy a szélesebb közösséggel együtt dolgozhasson ezeken a kihívásokon, a Perplexity 2026 márciusában elindította a Secure Intelligence Institute-ot, hogy tanulmányozza a legmodernebb mesterségesintelligencia-rendszerek biztonságát, megbízhatóságát és gyakorlati védelmét (Perplexity). A Perplexity jelenleg együttműködik a Stanford, a CMU, a Duke, a Columbia, az Ohio State és a Virginiai Egyetem akadémiai kutatóival, illetve támogatja őket. Emellett belső kutatásokat is végzünk az ügynökök biztonsági kutatásainak élvonalának előmozdítása érdekében, hogy ezen előrelépéseket a Perplexity rendszereinek kézzelfogható fejlesztéseivé alakítsuk, valamint megosszuk azokat a ismereteket és erőforrásokat, amelyek segítenek megerősíteni a szélesebb mesterségesintelligencia-ökoszisztémát. A biztonságosabb ügynökök olyan tényezők, amelyeket az iparág képes megtervezni. Célunk, hogy továbbra is kettegjünk a magunk részéről, és meghívunk másokat is az együttépítésre.