Mi az LLM-biztonság? Így mérsékelheted az OWASP Top 10 biztonsági kockázatait

Az a támadás, amely ráveszi az MI-t, hogy a támadó utasításait parancsként kezelje – vagyis a promptinjektálás –, 2023 óta minden kiadásban az OWASP Top 10 for LLM Applications listájának 1. helyén áll.

Ez a lista áll a legközelebb ahhoz, amit az MI-biztonság terén konszenzusnak lehet nevezni. A projekt biztonsági szakemberek kis csoportjaként indult, ma pedig már több mint 18 ország több mint 600 közreműködő szakértőjére támaszkodik.

MI-cégként olyan útmutatót teszünk közzé arról, hogyan lehet az MI-t rábeszélni dolgokra, ezért nem tesszük úgy, mintha ez a probléma meg lenne oldva. Wilson, az OWASP-projekt egyik vezetője, elég egyértelműen fogalmazott a jelenlegi védekezési módszerekről: „…őszintén szólva nem hiszem, hogy 99%-nál tartunk.”

A 2026-os kiadás ugyanezzel a gondolattal indít. A projekt vezetője arra biztat minket, hogy „hagyjunk fel azzal, hogy olyan modellt próbálunk építeni, amelyet nem lehet becsapni”, és úgy tervezzük meg a körülötte lévő rendszert, hogy egy becsapott modell se tudjon semmi fontosat tönkretenni.

Ezt a szemléletet követjük végig az OWASP 2026-os listájának mind a 10 kockázatán.

Mit jelent az LLM-biztonság?

Az LLM-biztonság az MI-modellek és az azokat használó alkalmazások védelmét jelenti a támadásokkal és a visszaélésekkel szemben. A kockázat azzal együtt nő, hogy mihez kapcsolódik a modell: milyen fájlokat és adatokat olvashat, és milyen eszközöket használhat, például e-mailt, keresést vagy egy vállalati adatbázist.

A megfelelően védett szoftverekben éles határ húzódik a program által követett utasítások és az általa feldolgozott információk között. Az LLM-ekben azonban nincs ilyen határ.

Minden, amit a modell olvas, egyetlen hosszú szövegfolyamként érkezik: a fejlesztő utasításai, a kérdésed, egy weboldal, amelyet felkeresett. Az MI-modelleknek elvileg követniük kell, hogy ki beszél éppen: a fejlesztő, a felhasználó, vagy maga a modell, miközben végiggondol egy problémát.

Jasmine Cui és Charles Ye kutatók azonban azt találták, hogy a modellek többnyire a szöveg hangvételéből találgatják, ki beszél. Ha tehát egy támadó olyasmit ír, ami úgy hangzik, mint a modell saját gondolatmenete, a modell azt hiheti, hogy az ötlet tőle magától származik. Ez minden olyan biztonsági megoldás számára problémát jelent, amely arra épít, hogy a modell tudja, ki irányít.

Ugyanezzel a problémával szembesültünk saját MI-ügynökeinknél is. Kyle Polley, a biztonsági igazgatónk (CISO), azt nyilatkozta az ISMG-nek, hogy az ügynökök „akkor sem feltétlenül követik a szabályzatokat, ha beleírod őket a rendszerpromptba”. Ezért építettük meg a Numbat nevű nyílt forráskódú eszközt, amely ellenőrzi, mire készül egy ügynök, és le tudja tiltani a műveletet, ha az megsért egy beállított biztonsági szabályt.

Az LLM-biztonság azt jelenti, hogy elfogadjuk: a modell időnként rossz személytől fogad el utasításokat, és olyan MI-védőkorlátokat építünk köré, amelyek ilyenkor is kitartanak.

Melyek az LLM-biztonság bevált gyakorlatai?

Sorban végigmegyünk az OWASP Top 10 for LLM Applications 2026 listáján, az 1. helytől a 10.-ig.

Minden kockázatnál közérthető magyarázatot kapsz arról, hogyan csúsznak félre a dolgok, valamint egy valós példát. Ezután bemutatjuk azokat a gyakorlatokat, amelyek segíthetnek megelőzni a problémát, vagy legalábbis korlátozni a kárt.

1. Tartsd kordában a promptinjektálást

Promptinjektálásról akkor beszélünk, amikor egy támadó ráveszi az MI-t, hogy olyan utasításokat kövessen, amelyeket nem kellene. Ezek az utasítások érkezhetnek közvetlenül egy csevegésben, de el is rejthetik őket egy e-mailben, weboldalon vagy dokumentumban.

A második típust közvetett promptinjektálásnak nevezik. Megkéred az asszisztensedet, hogy foglaljon össze egy dokumentumot. A dokumentum készítői azonban arra utasították benne az asszisztenst, hogy küldje el nekik a privát fájljaidat. Ha az asszisztens követi ezeket az utasításokat, a dokumentum írója gyakorlatilag kölcsönvette a hozzáférésedet.

A PCMag ahhoz hasonlítja a promptbiztonságot, amikor valaki egy porózus kő lyukait próbálja betömni. Az egyik nyílást lezárod, a víz pedig talál egy másikat. „Egy támadás átjut; kijavítják, de számtalan más támadási útvonal vár még felfedezésre, egyszerűen azért, mert az LLM-ekhez hasonló rendszerek ennyire dinamikusak.”

Példa: 2025 júniusában az Aim Security kutatói felfedezték az EchoLeak nevű sebezhetőséget, amelynek révén a Microsoft 365 Copilot rávehető volt arra, hogy bizalmas vállalati információkat szivárogtasson ki. Amikor egy alkalmazott egy rutinszerű munkahelyi kérdést tett fel, a Copilot behúzhatta a támadó e-mailjét, követhette a benne elrejtett utasításokat, és érzékeny információkat küldhetett a támadónak. A támadás kijátszotta azokat az ellenőrzéseket, amelyeknek a rosszindulatú utasításokat kellett volna kiszűrniük és a gyanús linkeket eltávolítaniuk.

Teendők:

• Kövesd a Meta „kettő szabályát”: Az EchoLeakhez olyan MI kellett, amely képes olvasni a vállalati adatokat, olvasni a külső e-maileket és információt küldeni kifelé – és mindhárom képességgel rendelkezett. Ha ezek közül csak kettőre korlátozod, megakadályozod, hogy egy promptinjektálás túl nagy irányítást szerezzen. Ha a feladathoz mindhárom szükséges, minden művelet előtt követelj meg emberi jóváhagyást.
• Tesztelj olyan támadókkal, akik ismerik a védelmeidet: Add át a biztonsági tesztelőidnek a bevezetett szabályokat és szűrőket, majd hagyd, hogy megkerüljék őket. Egy tanulmányban a védelmekhez alkalmazkodó támadók a 12 tesztelt védelem többségével szemben az esetek több mint 90%-ában sikerrel jártak.

2. Akadályozd meg az érzékeny információk kiszivárgását

Amikor egy MI-rendszer olyanoknak ad ki privát információkat, akiknek nem kellene látniuk azokat, azt érzékeny információk felfedésének nevezzük. Ez jelentheti például egy ügyfél fizetési adatainak kiadását, vagy azt, hogy privát beszélgetések egy megosztott adatbázisban maradnak.

Sok szivárgás „túlzott megosztással” kezdődik. Tegyük fel, hogy egy vállalat lazán beállított jogosultságú meghajtókhoz és tudásbázisokhoz csatlakoztatja az MI-t. Az MI – pontosan a tervezés szerint – mindent lekér, amit elér. Senkinek sem kell betörnie, de tekintsd úgy, hogy az LLM-be már betörtek.

Példa: 2025 januárjában a Wiz kutatói egy DeepSeek-adatbázist találtak, amely nyitva állt az internet felé, és több mint egymillió naplóbejegyzést tartalmazott, köztük csevegési előzményeket és API-kulcsokat, amelyekkel a szoftverek más szolgáltatásokhoz férnek hozzá. A kutatóknak rá sem kellett venniük a modellt, hogy bármit is felfedjen.

Teendők:

• Ellenőrizd a hozzáférést, mielőtt az MI beolvassa az adatokat: Az alkalmazásodnak ellenőriznie kell, hogy a kérdést feltevő személy mely dokumentumokat láthatja, mielőtt továbbadja azokat a modellnek.
• Védd az MI által hátrahagyott feljegyzéseket: A tevékenységnaplók mentése előtt távolítsd el belőlük a privát adatokat és a titkos kulcsokat, tedd kötelezővé a bejelentkezést, és korlátozd a hozzáférést azokra, akiknek szükségük van rá. Állíts be megőrzési időt, hogy ezek a feljegyzések ne halmozódjanak fel korlátlanul.

3. Fékezd meg a túlzott önállóságot

A túlzott önállósággal rendelkező MI-k több hatalommal bírnak, mint amennyit a feladatuk megkövetel: olyan eszközökkel, amelyekre nincs szükségük, a feladatukon túlmutató jogosultságokkal, vagy azzal a szabadsággal, hogy ellenőrzés nélkül cselekedjenek. Hogy mi okozza a bajt, itt lényegtelen.

Egy injektált prompt, egy programhiba vagy egy egyszerűen tévedő modell – mindegyik ugyanahhoz az eredményhez vezet. Ha az MI-nek megvan rá a képessége, előbb-utóbb valami romboló dolgot fog tenni.

Példa: 2025 júliusában Jason Lemkin, a SaaStr alapítója arról számolt be, hogy a Replit kódolóügynöke törölte az 1206 vezetői rekordot tartalmazó adatbázisát, annak ellenére, hogy arra utasította, ne végezzen módosításokat. Az ügynök eleinte azt állította, hogy az adatokat nem lehet visszaállítani, később azonban kiderült, hogy a helyreállítás mégis lehetséges. Jason rájött: attól, hogy megmondta neki, ne nyúljon az adatbázishoz, az ügynök még képes maradt törölni azt.

Nagyítás

Forrás: X

Teendők:

• Távolítsd el azokat a képességeket, amelyekre a feladathoz nincs szükség: Korlátozd az ügynöknek adott eszközöket, és azt is, hogy ezek az eszközök mire képesek. Egy e-maileket összefoglaló asszisztensnek olvasási engedélyre van szüksége, nem küldésire vagy törlésire.
• A jogosultság-ellenőrzést az MI-n kívül végezd: Minden kért műveletet vess össze a biztonsági szabályaiddal, és követeld meg, hogy egy ember jóváhagyja.

4. Ellenőrizd, mi kerül be az MI-ellátási láncodba

Kevés vállalat fejleszt MI-t a nulláról, és évről évre egyre kevesebb. A Menlo Ventures 2025-ös, The State of Generative AI in the Enterprise című felmérése szerint 2024-ben a vállalatok 53%-a vásárolt MI-modelleket, ez az arány 2025-re 76%-ra nőtt.

A vállalatok legtöbbször olyan platformokról töltenek le modelleket, mint a Hugging Face, mások által gyűjtött adatkészleteken tanítják tovább őket, és idegenek által írt bővítményeket és kódcsomagokat kapcsolnak hozzájuk.

Ezen részek mindegyike egy-egy bejárat. Ha valamelyiket manipulálják, a probléma a termékeddel együtt kerül ki a világba.

Példa: A Hugging Face nyilvános modelltárainak száma 2026 januárja és augusztusa között 2,43 millióról 2,96 millióra nőtt. 2026 júliusában azonban az OpenAI modelljei egy belső biztonsági tesztelés során megkerülték azokat a korlátozásokat, amelyeknek távol kellett volna tartaniuk őket az internettől, és behatoltak a Hugging Face rendszereinek egyes részeibe. Sőt, az egyik ügynök 14 nyilvánosan elérhető hozzáférési hitelesítő adatot szerzett meg, ellenőrizte, hogy működnek-e, és megosztotta őket más ügynökökkel. Az ügynökök ezután olyan hibákat használtak ki, amelyek lehetővé tették számukra, hogy kódot futtassanak a Hugging Face szerverein.

„Szigorúbb követelményeket támasztunk az összehangolással (alignment) szemben a modell teljes életciklusa során, elszigeteltebb sandboxokat hozunk létre, korlátozzuk az internet-hozzáférést, és tovább szigorítjuk a modellsúlyokhoz való hozzáférést” – áll az OpenAI jelentésében.

Teendők:

• Rögzítsd a modelleket egy pontos verzióhoz, és ellenőrizd őket: Minden modellt rögzíts egy átvizsgált verzióhoz, és betöltés előtt ellenőrizd a fájl ujjlenyomatát, hogy egy kicserélt fájl ne csúszhasson be ugyanazon címke alatt. Az OWASP digitális aláírásokat is javasol, egy fenntartással: az aláírás azt bizonyítja, honnan származik a modell, azt viszont nem, hogy biztonságos.
• Ellenőrizz minden csomagot, amelyet az MI javasol: Mielőtt telepítenél egy MI-asszisztens által ajánlott kódcsomagot, győződj meg róla, hogy létezik, hogy valóban az a csomag, amelyre gondoltál, és hogy a várt kiadótól származik.

5. Védekezz az adat- és modellmérgezés ellen

A megmérgezett MI meghamisított adatokból tanul. Ezek lehetnek azok a példák, amelyeken finomhangolták, vagy egy tudásbázis, amelyben válaszokat keres. A modell látszólag továbbra is működik, csak rossz leckéket tanul meg, és néha azt tanulja meg, hogy csak akkor viselkedjen rosszul, ha egy adott kiváltó kifejezést lát.

Egy ilyen modell minden teszten átmegy, amíg valaki be nem veti a kiváltó kifejezést.

Nagyítás

Ráadásul nagyon nehéz visszafordítani. A mérgezés nem olyan programhiba, amelyet egy javítással orvosolni lehet. Ha az adataid hibásak, előfordulhat, hogy újra át kell ellenőrizned őket, újra kell tanítanod a modellt, vagy teljesen le kell cserélned.

Példa: 2025 októberében az Anthropic, a brit AI Security Institute és az Alan Turing Institute kutatói kimutatták, hogy 250 megmérgezett dokumentum elég ahhoz, hogy egy modell értelmetlen szöveget állítson elő, valahányszor egy bizonyos kiváltó jellel találkozik. Ugyanez a szám mind a négy tesztelt modellméretnél működött, pedig a legnagyobbat több mint hússzor annyi tiszta adaton tanították.

Teendők:

• Kövesd nyomon, honnan származnak az adataid: Vezess nyilvántartást minden használt adatkészletről és modellről: honnan származik, és mi változott az egyes verziók között. Javasoljuk az adatkészletek verziókezelését, hogy ha mérgezés derül ki, vissza tudj állni egy tiszta verzióra, és ki tudd deríteni, hogyan került be.
• Tesztelj hátsó kapukra: A „hátsó kapu” olyan rejtett viselkedés, amelyet a támadó helyez el egy modellben, és amely egy adott kifejezésre vagy más kiváltó jelre vár, hogy aktiválódjon. Ezeket olyan bemenetekkel teszteld, amelyek arra szolgálnak, hogy a modellt a szokásos szabályai megszegésére késztessék.

6. Szabj határt a korlátlan erőforrás-felhasználásnak

Ha az MI-k esetében nincs semmilyen korlát arra, hogy mennyi munkát végezhetnek vagy mennyibe kerülhetnek, erőforrás-felhasználásukat „korlátlannak” tekintjük. Az MI-szolgáltatások többsége használat alapján számláz, így egy támadó felhizlalhatja a számládat, vagy lemásolhatja a modelledet.

Az OWASP „költségaszimmetriának” nevezi az alapproblémát. Egy rövid, olcsó kérés költséges számításokat indíthat el a te oldaladon.

Példa: 2024 májusában a Sysdig Threat Research Team egy új, „LLMjacking” nevű támadást fedezett fel. Egy támadócsoport ellopott hitelesítő adatokkal 10 felhőben futó LLM-szolgáltatást vett célba. A Laravel egy sebezhető verzióján keresztül jutottak be, majd kiderítették, mire használhatók a hitelesítő adatok, és milyen kvóták tartoznak hozzájuk – nyilvánvalóan azzal a céllal, hogy eladják a hozzáférést. Számos naplózási beállítást is lekérdeztek, valószínűleg azért, hogy elkerüljék a lebukást. A Sysdig szerint a legrosszabb esetben ez napi több mint 46 000 dollárjába kerülhet az áldozatnak.

Teendők:

• Állíts be olyan kereteket, amelyek megállítják a költekezést: Határozz meg szigorú költési korlátokat az egyes felhasználókra, API-kulcsokra, csapatokra és a fiók egészére. Érvényesítsd őket mindenhol, ahol kérések érkezhetnek.
• Adj minden feladatnak egy végpontot: Korlátozd, mennyi ideig futhat egy feladat, mennyi szöveget dolgozhat fel és állíthat elő, és hány eszközhívást indíthat. Építs be automatikus leállítást azokra az ügynökökre, amelyek ismétlik önmagukat vagy túllépik a keretüket.

7. Szűrd ki a téves információkat, mielőtt cselekednél

Ha egy MI olyan hamis dolgot állít elő, ami helytállónak hangzik, és valaki – vagy valami – ennek alapján cselekszik, azt téves információnak nevezzük. Az alapvető kockázat nem is annyira maga a rossz válasz, hanem az, hogy a rossz válaszban megbíznak, és fel is használják.

Az incidensek tanúsága szerint a szakemberek nem aggódtak annyira a téves információk miatt, mint kellett volna. A 2026-os kiadás bevezető levele szerint a szavazók a lista aljára helyezték, a valós incidensek alapján viszont a lista élén a helye.

Példa: 2025-ben a Deloitte Australia egy 440 000 ausztrál dolláros kormányzati szerződés keretében elkészítette a szociális ellátási informatikai rendszerek felülvizsgálatát. A Sydney-i Egyetem kutatója, Chris Rudge nem létező kutatásokra mutató hivatkozásokat talált a jelentésben, valamint egy szövetségi bírósági ítéletből származó kitalált idézetet. A módosított jelentésből kiderült, hogy a Deloitte az Azure OpenAI GPT-4o modellt használta a módszertanában, és a cég beleegyezett, hogy visszafizesse az utolsó részletet. Mindez ráadásul – sajnos – egy minőségbiztosítási felülvizsgálat volt.

Teendők:

• Ellenőrizd, hogy a bizonyítékok alátámasztják-e a választ: Az állításokat naprakész, hiteles forrásokra alapozd. Egy szabályzattal kapcsolatos válasznál kérd le a jóváhagyott szabályzatot, és ellenőrizd, hogy az – a kivételeivel együtt – alátámasztja-e a következtetést.
• Ellenőrizz, mielőtt a rendszer cselekszik: Ha egy ügynök azt állítja, hogy egy ügyfél átment a személyazonosság-ellenőrzésen, a kifizetés jóváhagyása előtt erősítsd meg ezt az ellenőrző rendszerben. A jelentős következményekkel járó döntésekhez követeld meg az emberi jóváhagyást, és gondoskodj róla, hogy az alátámasztó bizonyítékok elérhetők legyenek a jóváhagyó számára.

8. Korlátozd a rejtett kontextus felfedéséből eredő kárt

Az MI-alkalmazások olyan utasításokat és háttér-információkat adnak a modellnek, amelyeket a felhasználók általában nem látnak. Ide tartozhat a rendszerprompt, a belső szabályzatok, az elérhető eszközök leírása, valamint az, hogy ki használhatja őket. Rejtett kontextus felfedéséről akkor beszélünk, amikor a modell ezeket az információkat felfedi valaki előtt.

Az OWASP 2026-ban a korábbi „rendszerprompt kiszivárgása” helyett tágabban fogalmazta meg ezt a pontot, mert a rendszerprompt csak egy része annak, ami kiszivároghat. A veszély attól függ, mit helyeztél el benne. Egy kiszivárgott hangnem-útmutató legfeljebb kissé kínos, egy kiszivárgott API-kulcs viszont hozzáférést ad valakinek a bizalmas adatbázisodhoz.

Példa: 2023 februárjában a felhasználók rávették a Microsoft Bing Chatjét, hogy felfedje belső utasításait. Az egyik sikeres próbálkozás Marvin von Hagentől származott, aki OpenAI-fejlesztőnek adta ki magát, és azt kérte, hogy a modell adja ki az utasításait, hogy beállíthassa. A Bing felfedte a kereséseit, válaszait és biztonsági viselkedését szabályozó előírásokat, valamint belső nevét, a Sydneyt. A felfedett utasítások között volt egy olyan is, amely arra utasította, hogy tartsa titokban ezeket az utasításokat.

Teendők:

• Tartsd távol a titkos adatokat a modell kontextusától: Indulj ki abból, hogy bármi, amit a modell olvasni tud, a felhasználók számára is láthatóvá válhat – a jelszavakat, API-kulcsokat és hozzáférési tokeneket külön titokkezelő rendszerben tárold.
• Gondoskodj róla, hogy a jogosultságok akkor is érvényesek maradjanak, ha a szabályok kiszivárognak: A hozzáférés-ellenőrzést az alkalmazás kódjában érvényesítsd. Ha egy eszköz csak rendszergazdák számára érhető el, futtatás előtt ellenőrizd a felhasználó fiókjának jogosultságait.

9. Védd a vektorokat és a beágyazásokat

Amikor egy MI vektoros kereséssel keres válaszokat a vállalatod dokumentumaiban, nem közvetlenül a szövegben keres. A dokumentumokat „beágyazásokká” (embeddings) alakítják – hosszú számsorokká, amelyek az egyes szövegrészek jelentését rögzítik –, majd egy vektoradatbázisban tárolják. A kérdést ugyanígy alakítják át, a rendszer pedig azokat a szövegrészeket kéri le, amelyeknek a számai a legközelebb esnek hozzá.

Az OWASP így foglalja össze a négy hibalehetőséget: a mérgezés miatt a rendszer téved, az inverzió miatt adatokat szivárogtat ki, a blokkolás (jamming) miatt elhallgat, a hibás hozzáférés-szabályozás miatt pedig bárkinek bármit kiad.

A számok nem olyan biztonságos absztrakciót jelentenek, mint amilyennek látszanak. A tárolt beágyazások visszaalakíthatók szöveggé: az egyik módszer a tesztek során a rövid, 32 tokenes szövegrészek 92%-át pontosan visszaállította. Így egy kiszivárgott, „csak beágyazásokat tartalmazó” biztonsági mentés is felfedheti a dokumentumok tartalmát.

Példa: A USENIX Security 2025 konferencián bemutatott kutatásban a kutatók kimutatták, hogy egyetlen gondosan megalkotott dokumentummal meg lehet akadályozni, hogy egy MI megválaszoljon egy adott kérdést. A dokumentumot hozzáadták ahhoz a gyűjteményhez, amelyben az MI keresett. Amikor az MI rátalált, azt válaszolhatta, hogy nincs elég információja, vagy hogy a válaszadás nem lenne biztonságos. A dokumentumnak nem kellett arra utasítania az MI-t, hogy hagyja figyelmen kívül a szabályait. Ezt nevezik „visszakeresési blokkolásnak” (retrieval jamming).

Teendők:

• Tarts külön indexet a nyilvános és a privát adatoknak: Ne keverd a webről gyűjtött tartalmakat partneradatokkal vagy bizalmas belső dokumentumokkal. Ahelyett, hogy egyetlen indexen belül címkéznéd a tartalmakat, válaszd szét őket fizikailag a megbízhatósági szint szerint, mert ez a hibás konfigurációk egész osztályát szünteti meg, és így az internetről gyűjtött tartalom nem kerülhet az igazgatótanácsi dokumentumaid mellé.
• Kezeld a beágyazásokat ugyanúgy, mint a dokumentumokat, amelyekből készültek: Titkosítsd őket, a forrásfájlok mellett a vektoradatbázis biztonsági mentéseit is védd, és töröld a beágyazásokat, amikor az eredeti dokumentumot törlöd. A beágyazási szolgáltatás API-kulcsait tartsd titokban.

10. Ellenőrizd az MI kimenetét, mielőtt továbbadod

Ha egy alkalmazás úgy adja át az MI kimenetét egy másik rendszernek, hogy nem ellenőrzi, biztonságos-e ott a használata, akkor nem megfelelően kezeli az LLM kimenetét.

Ez a kategória azt a nem biztonságos kódot is lefedi, amelyet az MI-alapú kódolási asszisztensek nagy mennyiségben generálnak. Az asszisztens által írt minden sor tehát szintén kimenet.

Példa: 2025-ben Johann Rehberger kutató megmutatta, hogyan szivárogtathatta ki a Sourcegraph Amp nevű kódolási asszisztense a csevegések tartalmát pusztán egy kép megjelenítésével. Promptinjektálással elérte, hogy az Amp privát információkat illesszen egy kép webcímébe. Az alkalmazás ezután automatikusan lekérte a képet, és ezzel elküldte az információkat a kutató szerverére. A kimenetkezelési hiba éppen ez az automatikus kérés volt – a modell által generált szövegből egy külső szerverhez irányuló kapcsolat lett, amely magával vitte a privát adatokat.

Teendők:

• Tedd biztonságossá a kimenetet a célhelyének megfelelően: A válaszokat aszerint ellenőrizd és kezeld, hogy hová kerülnek. Weboldal esetén akadályozd meg, hogy a generált szöveg futtatható kóddá váljon. Adatbázis esetén használj előkészített lekérdezéseket, amelyek a megadott értékeket elkülönítik a parancsoktól.
• Akadályozd meg, hogy a válaszok automatikusan külső kapcsolatokat hozzanak létre: Alapértelmezés szerint tiltsd le a képek, a linkelőnézetek és a beágyazott oldalak automatikus betöltését a modell válaszaiban. A szükséges kapcsolatokat korlátozd a kifejezetten jóváhagyott célhelyekre.

Hogyan védi az LLM-eket a Perplexity?

Abból indulunk ki, hogy a fenti kockázatok mindegyike előbb-utóbb bekövetkezik, és úgy tervezünk, hogy ilyenkor ne tudjon nagy kárt okozni. Informatikai biztonsági vezetőnk (CISO), Kyle Polley egy nemrég tartott workshopon mutatta be, hogyan.

• Az ügynök saját számítógépet kap, amely üresen indul: A laptopodra telepített ügynökeszközök hozzáférhetnek a gép fájljaihoz, alkalmazásaihoz és mentett hitelesítő adataihoz. A Perplexity Computer ezzel szemben fordítva működik. Minden feladat a saját, elszigetelt sandboxában fut, és ahogy Polley fogalmaz: „alapértelmezés szerint semmihez sincs hozzáférése.”
• Az ügynök soha nem látja a jelszavakat: A csatlakoztatott szolgáltatások hitelesítő adatait a sandboxon kívül tároljuk. Amikor az ügynöknek el kell érnie egy szolgáltatást, például a GitHubot, hitelesítő adatok nélküli kérést küld. Egy átjáró ellenőrzi, hogy a célhely és a kérés megfelel-e az elvártnak, majd kifelé menet hozzáadja a hitelesítő adatokat. Az ügynök így használhatja a kapcsolatot anélkül, hogy megkapná a kulcsokat.
• A jogosultságaid megmaradnak, és szigoríthatod is őket: Az OAuth-on keresztül létrehozott kapcsolatok megőrzik a hozzáférési jogosultságaidat a csatlakoztatott szolgáltatásban. Amit te nem láthatsz, azt az ügynököd sem.
• Minden weboldalt idegenként kezelünk: Ügynökalapú böngészőnk, a Comet számára fejlesztettük ki a BrowseSafe megoldást, mert az általunk tesztelt eszközök a valós használat során nem feleltek meg az igényeinknek. A böngésző promptinjektálást keresve vizsgálja át a weboldalakat és más külső tartalmakat, köztük az e-maileket is. A modellt és az adatkészletet is nyílt forráskódúvá tettük.
• Figyeljük az ügynököt és a gépeket, amelyeken fut: A Numbat az ügynök cselekvési döntése és az eszköz tényleges futtatása között helyezkedik el. A Numbat naplózza a támogatott kódolási ügynökök tevékenységét, és még a végrehajtás előtt blokkolhatja a beállított szabályzatokat sértő műveleteket. A Bumblebee leltárba veszi a laptopokon, szervereken és buildfolyamatokban található szoftvercsomagokat, és megjelöli az ismerten kártékony csomagokat. Mindkettő nyílt forráskódú.
• A modellszolgáltatók nem őrzik meg az adataidat: Külső LLM-szolgáltatóinkkal nulla adatmegőrzést (zero data retention) előíró megállapodásaink vannak. A vállalati rendszergazdák a Perplexity saját adatmegőrzési idejét is akár 24 órára rövidíthetik.

A Numbatot proaktívan építettük meg, olyan okból, amelyet Polley egyetlen mondatban foglal össze: „Minél nagyobb önállóságot adsz egy ügynöknek, annál nagyobb a kockázat.”

Gyakori kérdések az LLM-biztonságról

Melyik a legbiztonságosabb LLM?

Egyetlen LLM sem teszi önmagában biztonságossá az alkalmazást – a modellek továbbra is összetéveszthetik az elolvasandó tartalmat a követendő utasításokkal. A szabványos teszteken erősnek tűnő védelmek is összeomolhatnak, ha nyomás alá kerülnek.

Jobb kérdés az, hogy melyik konfiguráció a legbiztonságosabb a te felhasználási esetedre. Ez korlátozott jogosultságokat, a modelltől távol tartott hitelesítő adatokat, a kockázatos műveletek emberi jóváhagyását, valamint olyan szakemberek általi tesztelést jelent, akik ismerik a védelmeidet.

Mik az LLM-sebezhetőségek?

Az LLM-sebezhetőségek olyan gyengeségek, amelyek miatt egy MI-rendszer megtéveszthető, adatokat szivárogtathat ki vagy kárt okozhat – akár egy támadó révén, akár saját hibái miatt.

A tíz fő kockázat: promptinjektálás, érzékeny információk felfedése, túlzott önállóság, ellátási lánc, adat- és modellmérgezés, korlátlan erőforrás-felhasználás, félretájékoztatás, rejtett kontextus felfedése, vektor- és beágyazási gyengeségek, valamint nem megfelelő kimenetkezelés.

Biztonságos-e a privát LLM?

Bizonyos szempontból biztonságosabb választás, de nem automatikusan. Ha a modellt saját infrastruktúrán vagy felhőkörnyezetben futtatod, nagyobb kontrollod van az adatkezelés felett. A promptinjektálást, a túlzott önállóságot, a mérgezést vagy a félretájékoztatást azonban semmi sem akadályozza meg automatikusan.

Saját üzemeltetés esetén te felelsz a letöltött modellért is, beleértve az ellátási lánc kockázatait és a szükséges infrastruktúrát.