# Közvetett promptinjekció elleni védelem: így fejleszti folyamatosan a Google Workspace a Gemini biztonságát - Link: https://digiosveny.hu/kozvetett-promptinjekcio-elleni-vedelem-igy-fejleszti-folyamatosan-a-google-workspace-a-gemini-biztonsagat/ - Published: 2026-10-22T03:06:41+02:00 - Author: Márton **Röviden:** A közvetett promptinjekció olyan támadási forma, amely rosszindulatú utasításokat rejt el az AI által feldolgozott tartalomban. A felhasználó ezeket nem feltétlenül adja meg közvetlenül. A Google Workspace védelmi megközelítése ezért nem egyetlen szűrőre épül: új támadások felderítését, tesztelését, szintetikus adatok előállítását, többféle védelmi réteg finomítását és ismételt mérést kapcsol össze. **Írta: Adam Gavish, a Google GenAI biztonsági csapatából.** Az AI-asszisztens nemcsak a felhasználó kérését dolgozhatja fel. Hozzáférhet e-mailekhez, dokumentumokhoz, webes tartalmakhoz vagy más, a feladat szempontjából releváns adatokhoz is. Ez hasznosabbá teszi az eszközt. Egyúttal új támadási felületet hoz létre. A közvetett promptinjekció (indirect prompt injection, IPI) során a támadó olyan tartalomba rejt utasításokat, amelyet az AI később feldolgoz. A cél az, hogy a modell eltérjen a felhasználó eredeti szándékától. Ehhez a felhasználónak nem kell közvetlenül megadnia a rosszindulatú parancsot. Ez nem egyszeri hibajavítási feladat. Az új modellek, az ügynöki automatizálás és a változatos adatforrások folyamatosan módosítják a támadási környezetet. A védelemnek ezért együtt kell fejlődnie a fenyegetésekkel. A Google korábbi, réteges védelemről szóló ismertetője bemutatta az IPI elleni védekezés alapelveit. Ez a cikk a következő lépést részletezi: hogyan kapcsolódik össze a támadások felderítése, a védelem fejlesztése és a hatékonyság ellenőrzése a Workspace Gemini-funkcióiban. ## A védekezés első lépése: az új támadások korai felismerése A hatékony védelemhez először meg kell érteni, hogyan változnak a támadások. A Google többféle forrásból gyűjt új mintákat, majd elemzi, reprodukálja és rendszerezi azokat. A cél nem pusztán egy-egy ismert eset kezelése. A csapatnak azt is fel kell tárnia, milyen más változatok és támadási útvonalak következhetnek belőlük. ### Emberi red teaming A red teaming során szakemberek ellenséges helyzeteket szimulálnak. Valós felhasználási módokhoz igazodó támadási kísérletekkel keresik a rendszer gyenge pontjait. Az eredményeket a termékcsapatokkal együtt vizsgálják, hogy az azonosított problémákból javítás és új teszteset szülessen. Az emberi tesztelés különösen hasznos lehet olyan összetett helyzetekben, ahol a támadás több lépésből vagy különböző adatforrások kombinációjából áll. A szakértő nemcsak azt figyeli, hogy egyetlen rosszindulatú utasítás átjut-e a védelmen. Azt is vizsgálja, hogyan értelmezi a rendszer a teljes feladatot. ### Automatizált red teaming Az automatizált tesztelés gépi tanulásra épülő keretrendszerekkel nagy mennyiségű támadási változatot állíthat elő és próbálhat ki. A rendszer iteratívan módosítja a teszteseteket. Így olyan kombinációk és szélső esetek is vizsgálhatók, amelyeket a kizárólag kézi tesztelés nehezebben fedne le. Ez a módszer segít feltérképezni az összetett támadási útvonalakat, és ellenőrizni, hogy a védelmi intézkedések különböző körülmények között is működnek-e. Az automatizálás nem váltja ki az emberi szakértelmet. Kiterjeszti a tesztelés lehetséges terjedelmét. ### Külső biztonsági kutatók és nyilvános támadási minták A Google AI Vulnerability Rewards Program (VRP) lehetőséget ad külső biztonsági kutatóknak arra, hogy jelentést tegyenek az általuk felfedezett, AI-rendszereket érintő sérülékenységekről. A Google a közreműködő kutatásokat a program keretében elismeri és jutalmazza. A vállalat emellett meghívásos, élő hackereseményeket is szervezhet, ahol a résztvevők kiadás előtti funkciókat vizsgálhatnak. A külső kutatók eltérő nézőpontokat és tesztelési módszereket hoznak. Ha egy bejelentett problémát reprodukálni lehet, a csapat értékelheti a hatását, kijelölheti a felelősöket, majd javítást készíthet. A nyilvánosan megosztott támadási kutatások szintén fontos jelzések. A Google nyílt forrású információkat figyel, például közösségi bejegyzéseket, sajtóközleményeket és szakmai blogokat. Az így azonosított mintákat elemzi, reprodukálja és belső nyilvántartásba veszi. ### A sérülékenységek katalogizálása Az újonnan felfedezett esetek elemzésen mennek keresztül. A folyamat része a reprodukálás, az ismétlődések ellenőrzése, a támadási technikák és lehetséges hatások besorolása, valamint a megfelelő felelősök kijelölése. A rendezett katalógus segít összekapcsolni a különböző forrásból érkező jelzéseket. Így a csapat nemcsak az egyedi hibákat kezeli, hanem a visszatérő mintákat is felismerheti. Ez teremti meg a következő lépés, a célzott tesztadatok előállításának alapját. ## Szintetikus adatok: több támadási változat, szélesebb tesztlefedettség A felderített támadási mintákból a Google a Simula segítségével szintetikus adatokat állít elő. Ezek a példák az ismert támadásokat különböző változatokkal bővítik. A cél az, hogy a védekezés ne csak az eredeti mintára reagáljon, hanem annak módosított formáit is kezelni tudja. A szintetikus adatok a védelmi modellek értékelését és tanítását is támogatják. A közölt beszámoló szerint a munkafolyamat felgyorsítása 75%-kal növelte a szintetikus adatgenerálást. Ez a vállalat által ismertetett folyamatra vonatkozó adat; önmagában nem jelenti azt, hogy a támadások száma vagy a kockázat ugyanilyen arányban csökkent. A nagyobb adatmennyiség csak akkor hasznos, ha a tesztek következetesek. Ezért a generált példák a tanítási és az ellenőrzési folyamatokat is támogatják. A cél a megismételhető értékelés, a változatos támadási lefedettség és a védelmi teljesítmény következetes mérése. ## Több védelmi réteg, eltérő frissítési sebesség A különböző védelmi mechanizmusok más-más módon reagálnak az új fenyegetésekre. Egy szabályalapú konfiguráció gyorsan módosítható. Egy gépi tanulási modell frissítése viszont új adatkészleteket, tanítást és ellenőrzést igényelhet. A Google megközelítése ezért több védelmi réteget kombinál. ### Determinisztikus védelem A determinisztikus védelmek előre meghatározott szabályok alapján működnek. A Google példaként említi a felhasználói megerősítést, az URL-ek tisztítását és az eszközláncolásra vonatkozó házirendeket. Ezeket központi Policy Engine szabályozza. Az ilyen védelem előnye, hogy bizonyos fenyegetésekre konfigurációs módosítással gyorsan lehet reagálni. Egy célzott szabály vagy javítás hamarabb bevezethető, mint egy teljes modellfrissítés. A szabályalapú megközelítés ugyanakkor nem helyettesíti azokat a védelmeket, amelyeknek változatosabb vagy kevésbé kiszámítható tartalmakat kell értelmezniük. ### Gépi tanulásra épülő védelem Az új támadási példákból összeállított adatok felhasználhatók a gépi tanulási védelmek frissítéséhez. A tanítási és az ellenőrzési példákat külön kezelik, hogy a teljesítményt olyan eseteken is lehessen mérni, amelyeket a modell nem használt fel tanulás közben. Ez a szétválasztás segít elkerülni, hogy az értékelés pusztán azt mutassa: a modell felismeri a már látott példákat. A rögzített adat- és tesztelési folyamat emellett megismételhető összehasonlítást tesz lehetővé a különböző modellverziók között. ### LLM-alapú védelem A Google az LLM-alapú védelmek rendszerutasításait is finomítja. Az új szintetikus példákon iteratívan teszteli a módosításokat, és a meghatározott védelmi mérőszámok alapján értékeli az eredményeket. Ennek célja, hogy a modell felismerje a feldolgozott adatokba ágyazott rosszindulatú utasításokat, és ne kövesse azokat a felhasználó eredeti kérésével szemben. A rendszerutasítások finomhangolása önmagában nem teljes védelem. A többi technikai és működési réteggel együtt ad védelmi értéket. ### A Gemini modell megerősítése Az alkalmazás- és rendszerszintű korlátok mellett a Google a modell belső ellenálló képességét is fejleszti. A közölt megközelítés szerint a friss támadási minták és szintetikus adatkészletek segítségével azt gyakorolják, hogy a Gemini felismerje és figyelmen kívül hagyja a tartalomba rejtett káros utasításokat. A cél kettős: a modell tartsa tiszteletben a felhasználó szándékát, és közben ne kövesse a feldolgozott adatokban elhelyezett ellenséges parancsokat. A Google beszámolója szerint a modellkeményítés javította a beágyazott utasítások felismerését, és csökkentette a támadások sikerességét úgy, hogy a rutinfeladatok hatékonysága ne sérüljön. ## A védelem hatékonyságának mérése Egy védelmi módosítás önmagában nem bizonyítja, hogy a rendszer biztonságosabb lett. A változtatás hatását tesztelni kell. A Google a szintetikus támadási adatokkal több Workspace-funkciót, köztük a Gmailt és a Dokumentumokat vizsgálja. A végpontok közötti értékelés során ugyanazokat a támadási helyzeteket a védelem bekapcsolásával és anélkül is lefuttatják. Az összehasonlítás megmutatja, hogyan változnak a kiválasztott mérőszámok az adott módosítás után. Ez segít ellenőrizni egy frissített gépi tanulási modell vagy egy finomított LLM-rendszerutasítás hatását. A tesztelés standardizált eszközkészletet használ, hogy az eredmények összevethetők legyenek. A megbízható értékeléshez a támadási példák minősége és a tesztelési folyamat következetessége egyaránt számít. A mérés így nem egyszeri jóváhagyás, hanem a folyamatos fejlesztési ciklus része. ## Mit jelent a folyamatos védelem a Workspace-felhasználóknak? A közvetett promptinjekció összetett probléma. Egyetlen szűrő vagy modellfrissítés nem zárja le véglegesen. A Google által ismertetett folyamat több egymásra épülő tevékenységet kapcsol össze: * **Felderítés:** emberi és automatizált tesztelés, külső kutatói jelzések, valamint nyilvános támadási minták elemzése. * **Rendszerezés:** az esetek reprodukálása, besorolása és a felelős csapatokhoz rendelése. * **Adatbővítés:** szintetikus támadási változatok előállítása a tesztelési lefedettség növelésére. * **Védelemfejlesztés:** determinisztikus szabályok, gépi tanulási modellek, LLM- alapú védelmek és modellkeményítés alkalmazása. * **Értékelés:** a módosítások összehasonlító, végpontok közötti tesztelése. Ez a működésmód nem jelent abszolút kockázatmentességet. Azt mutatja meg, hogyan lehet a változó fenyegetésekre ismételhető, mérhető fejlesztési ciklussal reagálni. A felhasználók számára a lényeg az, hogy az AI által feldolgozott tartalmat és a modellnek adott közvetlen utasításokat külön bizalmi kategóriaként kell kezelni. ## Összegzés A Google Workspace közvetett promptinjekció elleni megközelítése folyamatos munkafolyamatra épül. A csapat új támadásokat keres, rendszerezi és változatokká bővíti azokat, majd többféle védelmi réteget fejleszt. Végül összehasonlító tesztekkel ellenőrzi a változtatások hatását. A módszer legfontosabb tanulsága, hogy az AI-biztonság nem egyetlen modell képességén múlik. A felderítés, a szabályalapú kontrollok, a tanítóadatok, a modellviselkedés és a mérés együtt alkotnak védelmi rendszert. Mivel a támadási technikák változnak, ezt a rendszert is folyamatosan felül kell vizsgálni. _A cikk a Google által ismertetett biztonsági megközelítést foglalja össze és szerkesztői szempontból értelmezi._