A biztonsági közösség 2025 végére abbahagyta az indirekt promptinjektiót pusztán elméleti kockázatnak tekinteni. Két évnyi laborbemutató után a támadások a termelési rendszereket is elérték: az OWASP Top 10 for LLM applications most a prompt injekciót helyezte az első helyre, a NIST pedig „generatív AI legnagyobb biztonsági hibájának” nevezte az indirekt injekciót. Akadémiai kísérletek azt mutatták, hogy egyetlen megmérgezett e-mail is képes lehet egy modellt felhasználói interakció nélkül SSH-kulcsok kiszivárogtatására akár 80%-os próbálati sikerességgel.
A támadás nem igényel rosszindulatú binárist, adathalász-kattintást vagy szokatlan bejelentkezést: az ügynök egyszerűen elolvassa a tartalmat és cselekszik, ahogy arra fel lett tervezve, a tartalmat pedig a támadó írta.
Tanulságos példa: ForcedLeak (Salesforce Agentforce)
2025 szeptemberében a Noma kutatói nyilvánosságra hoztak egy kritikus sebezhetőségi láncot (CVSS 9.4) a Salesforce Agentforce platformjában: egy támadó rosszindulatú utasítást helyezett el egy rutin Web-to-Lead űrlap leírás mezőjében. A szöveg ártalmatlannak tűnt a CRM-ben, amíg egy alkalmazott nem kérte meg az AI-ügynököt a lead feldolgozására — ekkor az ügynök végrehajtotta a jogos feladatot és a rejtett támadói payloadot, és szenzitív CRM-adatokat küldött ki egy külső szerverre. Riasztó részlet: a kiszivárogtatás céljaként használt domain szerepelt Salesforce megbízható allowlistjén, de lejárt, és a kutatók körülbelül öt dollárért újra regisztrálták. Minden biztonsági kontroll legitim forgalmat látott egy megbízhatónak hitt domain felé — semmi sem tűnt szokatlannak.
Miért nem elég a bemeneti réteg
Sok vállalati AI-csapat alapvédekezése a bemenetek szaniterizálása: rendszerpromptok megszilárdítása, bejövő tartalmak osztályozása, tréning-időben alkalmazott instruction hierarchy-k vagy RL-alapú ellenálló képzések. Ezek hasznosok, de közös hiányosságuk, hogy mind azt célozzák, hogyan ne tévessze meg a modellt a bemenet. Azonban a probléma nem magának az injekciónak a létezése, hanem a modell által javasolt, végrehajtható akció.
A nagy nyelvi modellek működéséből adódóan a modell egyetlen, meg nem különböztetett tokenfolyamot fogyaszt az inferencia pillanatában: a rendszerutasítások, visszahozott dokumentumok, eszközök kimenete és a frissen lekért weboldalak ugyanabban a kontextusban jelennek meg. Nincs hardveres határvonal „megbízható utasítás” és „megbízhatatlan adat” között úgy, mint az operációs rendszerek kernel- és user-space-e között. Amint egy ügynök agentikus lesz — webet lekérdez, e-mailt olvas, adatbázist kérdez, API-kat hív — a támadási felület ugrásszerűen nő: bármelyik forrás hordozhat utasítást.
Valódi ügynökök ökoszisztémáit vizsgáló kutatók már találtak több száz rosszindulatú harmadik féltől származó bővítményt, amelyek adatkiszivárgást vagy csendes injekciót végeznek felhasználói tudtán kívül — ezek nem labor-kuriózumok, hanem a termelési környezet részei.
Ellenőrizd, aztán bízz meg — az akcióréteg szerepe
A javasolt elv egyszerű megfogalmazásban: az ügynök által javasolt akciót mindig determinisztikus, külső szabályzatnak kell alávetni végrehajtás előtt, függetlenül attól, hogy miért javasolta az ügynök az akciót. A validátor nem arra kérdez rá, hogy maga az utasítást adó tartalom legitim-e, és nem próbál meg minden álcázott rosszindulatot felismerni — ehelyett egy jól meghatározott, zárt kérdést tesz fel: ez az akció megengedett-e önmagában?
Ez az elv áthelyezi a terhet: a támadó kreativitása végtelen lehet, és annak detektálása nyílt probléma; ezzel szemben egy például dollárösszegileg korlátozott átutalás ellenőrzése zárt, eldönthető probléma. A érdemi végrehajtás előtti ellenőrzésnek determinisztikus kódnak kell lennie — újabb LLM bevonása ugyanazt a sebezhetőséget hozza vissza egy szinttel lejjebb. Az érvényesítés rétege hagyományos, unalmas, auditable szoftver: és pontosan ez a cél.
Példa gyakorlatban: egy beszerzési ügynök approve_invoice nevű akciót javasol, amelyet futásidejű szerződés (runtime contract) vizsgál meg a végrehajtás előtt. Ha az akció struktúrált — például typed tool call formájában érkezik (vendor, amount) — a szerződés könnyen ellenőrizhet: túllépi-e a maximális összeget, szerepel-e a beszállító az engedélyezett nyilvántartásban, szükséges-e emberi jóváhagyás az adott határ fölött. Ha a javasolt akció nem felel meg a szabálynak, az API-hívás sosem történik meg.
Fontos feltétel: az akciónak strukturáltnak kell érkeznie. Ha az ügynök szabad szövegben adja meg a kérést, akkor azt feldolgozni csak egy másik LLM képes, és az indeterminizmus visszajön. Ezért követelmény, hogy minden jelentős hatású parancs tipizált eszközhívásként lépjen át a határon. Ha a bemenet elkerülhetetlenül természetes nyelv (például egy e-mail: "Wire them their balance"), a modell kinyerhet strukturált értéket, de az kinyerés soha ne legyen önfelhatalmazó: a kapu ellenőrizze az összeget a rendszer hivatalos számlájával, ne csak az e-mail állításával szemben.
Vannak döntések, amelyek nem paraméterezhetők sima sémával (például: phishing-e az e-mail?). Ilyenkor a modell marad a folyamatban, de korlátozod a következményeket: visszafordíthatóság, emberi felülbírálat egy küszöbérték felett. A szerződések a paraméterezhető akciókat védik; a nem paraméterezhető ítélkezések tartalékoltak.
A javasolt architektúra elemei
Ha elfogadjuk, hogy a biztonság az akciórétegben lakik, három kulcsfontosságú tervezési elv következik:
-
Legkisebb jogosultság (least privilege) az akció szintjén, nem az ügynök szintjén. Az ügynök nem tarthat állandóan birtokában veszélyes képességeket: minden akcióhoz ideiglenes, szűkített emelés kérhető, amelyet a determinisztikus kapu jóváhagy vagy elutasít. A veszélyes hitelesítő adat csak addig él, amíg az akció engedélyezett.
-
Zero trust a gépi identitásokra. Minden ügynöki akciót úgy kell autentikálni és autorizálni, mintha egy megbízhatatlan szereplőtől érkezett volna: a belső eredet nem jelent automatikus bizalmat.
-
Képesség-szerződések a határnál. Minden érdemi művelet determinisztikus kapun megy át, ahol kódba foglalt szabályok határozzák meg az engedélyezést, pénz- és sebességkorlátokat, allowlistelt célokat, és az emberi felülvizsgálat kötelező küszöbértékeit. A szerződések verziókövetettek és auditálhatók, és teljesen a modellon kívül élnek.
A normalizált rendellenesség csapdája
Egy csendes, szervezeti veszély az, amikor a csapatok fokozatosan hamis magabiztosságot halmoznak fel: összekapcsolják az kevésbé biztonságos ügynököket valós rendszerekkel, és semmi baj nem történik — egy darabig. Minden eseménytelen nap megerősíti a döntés helyességébe vetett hitet, mígnem egyszer bekövetkezik a katasztrofális hiba. A csapatok, amelyek túl fogják élni az ügynöki esetek következő hullámát, nem csupán a legokosabb bemeneti szűrőkkel rendelkeznek, hanem alapfeltevésként a kompromittáltságot tételezik fel, és felépítették a „unalmas” érvényesítési réteget, amely megállítja az ügynök autonómiáját ott, ahol a visszafordíthatatlan cselekvés kezdődik.
Hol kezdje a csapat hétfőn
Nem kell mindent újraépíteni. Kezdje azzal, hogy leltározza, milyen akciókat tehetnek az ügynökei, és osztályozza ezeket hatás szerint: mi a legrosszabb, ami történhet, ha egy akció véletlenül vagy rosszindulatból fut? Minden nagy hatású akcióhoz írjon determinisztikus szerződést, amely korlátozza a végrehajtást, és állítson be emberi felülvizsgálatot egy jól megvédhető küszöb fölött. Csak ezután folytassa a bemenetek további megerősítését.
A prompt injekciót nem lehet megoldani kizárólag a bemeneti rétegen — nem is lehetne —, de túlélhetővé tehető az akciórétegen, ahol a determinisztikus kód adja meg az utolsó szót. A modell dolga hasznosnak lenni; az architektúráé az, hogy ha a modell hibázik — vagy rosszindulatúan használják —, a hiba megáll a kapunál.
