LLM és AI alkalmazásbiztonság

Mit védünk konkrétan az AI-alkalmazásban

A prompt injection ellen bemenet- és kimenetszűrést, valamint rendszerprompt-elkülönítést állítunk be, hogy egy beágyazott utasítás ne írhassa felül az alkalmazás eredeti célját. Ha a rendszered RAG-ot használ (saját dokumentumokból válaszol), dokumentumszintű hozzáférés-vezérlést adunk, hogy egy felhasználó csak olyan tartalmat kaphasson vissza, amihez jogosultsága van. Kimenetszűréssel és PII-szűréssel csökkentjük az érzékeny adat véletlen kiszivárgásának kockázatát. Ha az AI-rendszer önálló műveleteket is végez, például adatot ír vagy külső rendszert hív meg, a jogosultságát a lehető legszűkebbre korlátozzuk, hogy egy sikeres manipuláció kára eleve behatárolt legyen.

• Bemenet- és kimenetszűrés prompt injection ellen
• RAG-hozzáférés-vezérlés dokumentumszinten, jogosultság szerint
• PII-szűrés a kimeneten, érzékeny adat kiszivárgása ellen
• Sebességkorlátozás, hogy egy AI-ügynök ne terhelje túl a modellt vagy a mögötte lévő rendszert

Az AI-kor lényege: itt maga a modell a támadási felület

A hagyományos alkalmazásbiztonságban a bemenet és a kód elkülönül. Egy LLM-nél a bemenet (a felhasználói szöveg) és az utasítás ugyanabban a csatornában érkezik, ezért egy jól megfogalmazott prompt képes felülírni a rendszer eredeti szándékát, vagy rávenni az AI-ügynököt olyan műveletre, amire nincs jogosultsága (túlzott ügynöki jogosultság). Ezért az OWASP LLM Top 10 tételeit egyenként végignézzük: prompt injection, nem biztonságos kimenetkezelés, érzékeny adat szivárgása, túlzott ügynöki jogosultság, és mindegyikhez konkrét kontrollt állítunk be, nem csak elméleti figyelmeztetést adunk.

Red teaming és folyamatos ellenőrzés

Rendszeres AI red teaminget végzünk promptfoo és garak eszközökkel: automatizáltan próbálunk ki ismert jailbreak- és injekciós mintákat az alkalmazásodon, majd a talált réseket bezárjuk. Az EU AI Act által érintett, magasabb kockázatú AI-alkalmazásoknál ez a dokumentált tesztelés fontos alap a megfelelési dokumentációhoz, formális tanúsítási igény nélkül. A teszteket rendszeresen megismételjük, mert a modell frissítése vagy egy új funkció bevezetése új viselkedést hozhat, amit az előző kör még nem fedett le.

Hogyan dolgozunk

1. Architektúra átvizsgálása

   Megnézzük, hogyan kapcsolódik az LLM az alkalmazásodhoz: milyen adatokhoz fér hozzá, milyen műveleteket végezhet, honnan jön a bemenet.

2. Kontrollok beépítése

   Beállítjuk a bemenet-/kimenetszűrést, a RAG-hozzáférés-vezérlést és a sebességkorlátozást az OWASP LLM Top 10 tételei szerint.

3. AI red teaming

   Automatizált és manuális jailbreak- és injekciós próbákkal teszteljük az alkalmazást promptfoo és garak eszközökkel, majd priorizáljuk a talált réseket.

4. Javítás és dokumentáció

   A talált réseket bezárjuk, és dokumentált jelentést adunk, amely az EU AI Act szerinti megfelelési anyaghoz is felhasználható a szervezetednél, a következő teszt előtt.

Felhasználási esetek

Technológiák

• OWASP LLM Top 10
• promptfoo
• garak
• RAG hozzáférés-vezérlés
• PII-szűrés
• Sebességkorlátozás
• EU AI Act

Gyakori kérdések

• Mi az a prompt injection?

  A prompt injection egy technika, amellyel a támadó a felhasználói bemenetbe rejt olyan utasítást, amely felülírja vagy megkerüli az alkalmazás eredeti rendszerpromptját. Ez kiszivárogtathat adatot, vagy rávehet az AI-t olyan válaszra vagy műveletre, amit nem kellene megtennie.

• Miben más ez, mint az AI-kori kódbiztonság?

  Az AI-kódbiztonság (ai-code-security) a fejlesztési láncot védi: a kódot, a függőségeket, a konténer image-eket, függetlenül attól, hogy a kódot ember vagy AI-asszisztens írta. Az LLM-alkalmazásbiztonság magát a futó AI-alkalmazást védi: a prompt-csatornát, a RAG-hozzáférést, az AI-ügynök jogosultságát. A kettő kiegészíti, de nem helyettesíti egymást.

• Mi az a RAG-hozzáférés-vezérlés?

  A RAG-rendszer saját dokumentumokból válaszol. A hozzáférés-vezérlés biztosítja, hogy a modell csak olyan dokumentumot vonjon be a válaszba, amelyhez a kérdező felhasználónak ténylegesen jogosultsága van, ne az egész tudásbázist lássa mindenki.

• Mi az az AI red teaming?

  Az AI red teaming során automatizált és manuális technikákkal, ismert jailbreak- és injekciós mintákkal próbáljuk kicselezni az AI-alkalmazást, hogy még a bevezetés előtt vagy rendszeresen kiderüljön, hol enged olyan választ vagy műveletet, amit nem kellene.

• Érinti-e az EU AI Act az alkalmazásomat?

  Ez a kockázati besorolástól és a felhasználási esettől függ, amelyet egyedileg érdemes átnézni. A magasabb kockázatú AI-alkalmazásoknál a dokumentált tesztelés és kontrollok fontos alapot adnak a megfelelési anyaghoz, formális tanúsítás nélkül is.

• Elég a modellszolgáltató beépített védelme?

  A modellszolgáltató beépített szűrői általános esetekre védenek, de nem ismerik a te alkalmazásod konkrét adatstruktúráját vagy jogosultsági modelljét. A RAG-hozzáférés-vezérlést és a kimenetszűrést az alkalmazásod szintjén kell beállítani, mert ott dől el, ki mit láthat.