Megakadályozhatja-e egy jobb rendszerprompt a prompt injectiont?

Nem. A rendszerprompt ugyanabban a kontextusablakban újabb szöveg, és a modell azt súlyozza azzal együtt, amit olvas. A világos utasítások és az elválasztók csökkentik a véletlen hibákat, de egy elszánt támadó felülírhatja őket. A megbízható védelem az architektúrából jön: korlátozni kell, milyen adatokhoz fér hozzá az ügynök, milyen műveleteket indíthat nem megbízható tartalom, és hová küldhet adatot.

Mi a különbség a közvetlen és a közvetett prompt injection között?

A közvetlen prompt injectiont az adja, aki a modellbe ír, például amikor egy felhasználó felülírja egy chatbot szabályait. A közvetett prompt injection utasításokat rejt el olyan tartalmakba, amelyeket a modell valaki más nevében olvas: egy weboldalba, egy e-mailbe, egy ticketbe vagy egy eszközeredménybe. A közvetett injection ügynököknél veszélyesebb, mert az áldozat soha nem látja a rosszindulatú szöveget.

Működnek-e a prompt injection osztályozók vagy a guard modellek?

Második rétegként segítenek, de nem biztonsági határok. Egy 2025. októberben közölt kutatás adaptív támadásokkal 12 friss védelmet került meg, a legtöbbnél 90 % feletti sikeraránnyal. Az osztályozók emelik a támadó költségét és kiszűrik a gondatlan támadásokat, a valódi garanciákat viszont az adatkör, a kimenő forgalom szabályozása és az emberi jóváhagyás adja.

Hogyan szivároghatnak ki adatok egy MI-chatből Markdown-képeken keresztül?

Ha a chatfelület automatikusan rendereli a Markdownot, egy injektált utasítás képre utasíthatja a modellt, amelynek URL-je a query stringben privát adatot tartalmaz. A böngésző letölti a képet, és kattintás nélkül elküldi az adatot a támadó szerverének. A válaszok sima szövegként való renderelése, vagy a képek átirányítása egy rögzített allowlisten keresztül bezárja ezt a csatornát.

Prompt injection és a lethal trifecta

A prompt injection olyan támadás, amelyben az a szöveg, amelyet az LLM adatként olvas – egy weboldal, egy e-mail, egy issue-komment vagy egy eszközeredmény –, olyan utasításokat tartalmaz, amelyeket aztán a modell követ. Ez nem egy adott modell hibája, amelyet a következő kiadás javítana. Abból következik, hogyan működnek a nyelvi modellek, tehát architekturális probléma: nem lehet megbízhatóan kiszűrni, úgyhogy olyan rendszereket tervezel, amelyekben egy sikeres injection nem tud sok kárt okozni.

Ez a bejegyzés megmagyarázza, miért nem tudnak a modellek elválasztani az utasítást az adattól, mit nevez Simon Willison lethal trifecta-nak, és melyek azok a hat tervezési minta egy 2025-ös tanulmányból, amelyek korlátozzák, mit érhet el egy injektált utasítás. Utána alkalmazza őket két gyakori rendszerre, egy support botra és egy kódoló ügynökre, és egy ellenőrzőlistával meg egy CI-ben futtatható red team felállítással zár.

Miért nem tud egy LLM megkülönböztetni az utasítást az adattól?

Mert a modell számára minden a kontextusablakban ugyanaz: egy tokensorozat. A rendszerprompt, a felhasználó kérése és egy letöltött weboldal tartalma egyetlen folyamban érkezik, és a modell az egész alapján jósolja meg, mi következik. Nincs külön, privilegizált csatorna arra, hogy „ezeket az utasításokat kell követnem”.

Willison ezt nyersen megírja 2025. júniusi bejegyzésében a lethal trifectáról: a modellek „szívesen követ bármilyen utasítást, amely eljut hozzájuk”, nem csak a tiédet. A szerepek jelölései és az elválasztók segítenek a modellnek súlyozni a forrásokat, de ezek a modell által megtanult konvenciók, nem pedig olyan határ, amelyet betartat.

A detektálás sem zárja be a rést. A „The Attacker Moves Second” (2025. október) című tanulmányban az OpenAI, az Anthropic és a Google DeepMind kutatói adaptív támadásokat alkalmaztak 12 közzétett védelem ellen, és „a legtöbbnél 90 % feletti támadási sikeraránnyal” kerülték meg őket. Azok a védelmek, amelyek egy rögzített támadásprompt-készlet ellen szinte tökéletesnek tűntek, összeomlottak, amint a támadó az adott védelemre hangolta a támadást. Biztonsági nyelven: az a szűrő, amely megállítja a támadások 95 %-át, az a szűrő, amely minden elszánt támadóval elbukik.

Anthropic ugyanerre a következtetésre jut a másik oldalról. A „How we contain Claude” (2026. május) leírásában egy belső red team gyakorlatot mutat be, amelyben egy adathalászati e-mail egy előre bekészített promptot hozott, amely azt írta, hogy a Claude Code olvassa el az AWS hitelesítő adatait, kódolja őket, és POST-tal küldje ki: „A prompt 25 próbálkozása során a Claude 24-szer befejezte az exfiltrációt.” A bejegyzés következtetése: a modellrétegen működő védelem „soha nem lesz 100 %-ban hatékony, és éppen ezért nem állhat önmagában”.

Mi az a lethal trifecta?

A lethal trifecta három képesség együttesje egy ügynökben: hozzáférés a privát adatokhoz, érintkezés nem megbízható tartalmakkal, és a lehetőség a külső kommunikációra. Ha egy ügynök mindhárommal rendelkezik, az a támadó, aki uralma alatt van bármelyik nem megbízható tartalom, ráveheti, hogy olvassa el a privát adatokat, és küldje ki őket.

A lethal trifecta: privát adat, nem megbízható tartalom és külső kommunikáció. Bármely kettő visszatartható; mindhárom együtt lehetővé teszi, hogy egy injektált utasítás privát adatot olvasson, és azt küldje el a támadónak.

A lábak szélesebbek, mint látszanak. A „külső kommunikáció” alatt HTTP-kérés, elküldött e-mail, komment egy nyilvános issue-ban és olyan Markdown-kép is értendő, amelynek URL-je a query stringben hordoz adatot, amit a chatfelület automatikusan letölt. A „nem megbízható tartalom” alatt minden, amit harmadik fél írhat: support ticketek, termékértékelések, PDF-ek, README-fájlok, függőségek forráskódja és harmadik szerverek eszközleírásai.

A Meta biztonsági csapata ugyanezt az ötletet szabályba ültette az „Agents Rule of Two” (2025. október) cikkben: egy munkameneten belül az ügynök legfeljebb kettőt birtokoljon ezek közül: [A] a nem megbízható inputok feldolgozását, [B] a hozzáférést érzékeny rendszerekhez vagy privát adatokhoz, és [C] a lehetőséget az állapot megváltoztatására vagy a külső kommunikációra. Ha egy munkafolyamatnak tényleg mindhárom kell, Meta szerint az ügynöknek „nem szabad autonóm módon működnie”, és emberi jóváhagyásra vagy más megbízható validálási eszközre van szüksége. Meta [C] pontja az állapot megváltoztatását is lefedi, nem csak az adatok kiküldését, és ez a helyes kiterjesztés azokhoz az ügynökökhöz, amelyek törölni, fizetni vagy deployelni tudnak.

Hat tervezési minta, amely behatárolja a prompt injectiont

A hat minta a „Design Patterns for Securing LLM Agents against Prompt Injections” (Beurer-Kellner és mtsai., 2025. június) tanulmányból származik. Egy dolgot közösen: ha egy ügynök egyszer elolvasta a nem megbízható inputot, annak nem szabad következményes műveleteket kiváltania. Mindegyik minta feladja valamennyi rugalmasságot, hogy ezt elérje.

1. Action-Selector

A modell egy kérést egyetlen műveletre képezi le egy rögzített listából, és soha nem látja annak a műveletnek az eredményét. Willison a tanulmány összefoglalójában „LLM-modulált switch-utasításnak” nevezi. Semmi nem folyik vissza, így semmi nem injektálható.

2. Plan-then-Execute

Az ügynök a teljes eszközhívási tervét rögzíti, mielőtt bármilyen nem megbízható tartalmat olvasna. Az eszközök kimenetei még mindig elszennyezhetik egy lépés tartalmát, például egy összefoglaló szövegét, de nem adhatnak hozzá, nem törölhetnek és nem rendezhetnek át lépéseket.

3. LLM Map-Reduce

Minden nem megbízható dokumentum egy elkülönített alügynökhöz kerül, amely egy korlátozott eredményt ad vissza, például egy logikai értéket vagy egy számot. Egy koordinátor összegyűjti az eredményeket. Egy mérgezett dokumentum csak a saját eredményét szennyezheti el.

4. Dual LLM

Willison először 2023. áprilisában írta le. Egy privilegizált LLM tervez és hív eszközöket, de soha nem lát nem megbízható szöveget. Egy karanténba tett LLM feldolgozza a nem megbízható szöveget, de nincsenek eszközei. A szokásos kód (a vezérlő) szimbolikus változóként, például $VAR1 néven adja tovább az eredményeket köztük, így a privilegizált modell úgy mondhatja, hogy „küldd el a $VAR1 értékét e-mailben a felhasználónak” anélkül, hogy a $VAR1-et olvasná.

// Pseudo-code: dual LLM with a code controller
plan = privileged_llm(user_request, tools)   // never sees untrusted text
for step in plan:
  if step.kind == "read_untrusted":
    vars[step.out] = quarantined_llm(step.prompt, fetch(step.source))  // no tools
  else:
    execute(step.tool, resolve(step.args, vars))  // $VAR1 substituted by code, not by a model

5. Code-then-Execute

A privilegizált modell egy korlátozott nyelven írt programot állít elő, amely megmondja, mely eszközök hívódnak meg, és hogyan folyik az adat közöttük. Egy értelmező futtatja, és nyomon követheti, mely értékek szennyezettek nem megbízható forrásokból. A legismertebb változat a Google DeepMind CaMeL rendszere; arra capability-alapú szabályokat tesz rá, és a tanulmányában az AgentDojo feladatai 77 %-át oldja meg bizonyítható biztonsággal, egy védelem nélküli rendszerrel szemben 84 %-ot.

6. Context minimalizálás

Vedd ki, ami a modellnek már nem kell. Ha a felhasználó kérését már adatbázis-lekérdezéssé alakítottuk, a lekérdezés eredménye előtt dobd el az eredeti kérést, hogy a kérésben lévő injektált szöveg ne tudja irányítani a választ.

Dual LLM: a privilegizált modell tervez és eszközöket hív, de csak változóneveket lát; a karanténba tett modell nem megbízható szöveget olvas, de nincsenek eszközei; a szokásos kód behelyettesíti az értékeket, amikor egy eszköz fut.

Miért egy képesség-kiosztás az egress allowlist

Az egress allowlist azoknak a hosztoknak a listája, amelyeket az ügynök elérhet. Ez a trifecta külső kommunikációs lábának levágása a legközvetlenebb módja, de csak akkor, ha minden engedélyezett domaint képességek halmazaként kezelsz, nem pedig biztonságos célpontként.

A fenti Anthropic red team gyakorlat azért működött, mert a Claude Code allowlistje engedélyezte az api.anthropic.com címet, és egy API, amely elfogad feltöltéseket, exfiltrációs csatorna. A bejegyzés tanulsága: „Minden funkció, amely bármely allowlistben lévő domainen keresztül elérhető, mostantól támadási felület.” Az Anthropic megoldása egy proxy volt, amely csak azokat a kéréseket engedi át, amelyek a session saját, kiosztott tokenjét hordozzák, így a támadó beágyazott kulcsa elutasításra kerül.

A Claude Code sandbox-dokumentációja kapcsolódó pontot tesz: a széles domainek, például a github.com engedélyezése „útvonalakat nyithat az adatok exfiltrációjára”, és mivel az alapértelmezett proxy a kliens által megadott hosztnév alapján dönt, TLS-vizsgálat nélkül, a domain fronting a listán kívüli hosztokhoz is eljuthat. Gyakorlati következmények:

Csak konkrét hosztokat és útvonalakat engedélyezni (egy csomagtár tükrét), ne olyan teljes platformokat, amelyek írást elfogadnak.
A proxynél a hitelesítő adatokat a sessionhöz kötni, hogy egy idegen tokent tartalmazó kérés elbukjon.
A külső képek és linkek megjelenítését a chat kimenetében eltávolítani vagy letiltani, vagy átirányítani őket egy rögzített allowlisten keresztül.
Minden kimenő kérést a session azonosítójával logolni, hogy egy exfiltrációs kísérlet utólag is látható legyen.

A sandbox-, hálózati és hitelesítő adat-kontrollok CI-ben futó ügynökökhoz külön fejezetet kapnak a kódoló ügynökök sandboxolási checklistjében.

A minták alkalmazása egy support botra és egy kódoló ügynökre

Kezdd azzal, hogy felsorolod, melyik rendszernek melyik trifecta-lába van, majd válassz olyan mintát, amely levesz egy lábat, vagy megakadályozza, hogy a nem megbízható tartalom műveleteket válasszon. Az alábbi táblázat az én olvasatom arról, hová illik melyik minta; a tanulmány esettanulmányai között van ügyfélszolgálati chatbot és szoftverfejlesztő ügynök is.

Minta	Support bot (ticketeket olvas, rendeléseket néz)	Kódoló ügynök (repót, issue-kat, webet olvas)	Fő költség
Action-Selector	Erős illeszkedés routingra: visszatérési űrlap, rendelés állapota, átadás embernek	Gyenge: az ügynököknek kell az eszköz visszajelzése	Nincsenek szabad szöveges válaszok
Plan-then-Execute	Jó rögzített folyamatokhoz, mint a „rendelés megkeresése, majd válasz”	Részben: a terv feladatonként rögzített, az újratervezéshez jóváhagyás kell	Nincsenek adaptív lépések
LLM Map-Reduce	Sok ticket vagy értékelés osztályozása	Sok fájl vagy függőség átvizsgálása	Csak szűk kimenet elemenként
Dual LLM	Ügyfél-emails összefoglalása eszközhozzáférés nélkül	Issue-k és weboldalak összefoglalása a tervezőnek	Összetett vezérlőkód
Code-then-Execute	Lehetséges, általában túlzás	Ígéretes a szennyezett adatok követésére	Saját értelmező és szabályok
Context minimalizálás	Az eredeti üzenet eldobása a kérés szándékának kinyerése után	A letöltött oldalak eldobása használat után	Kevesebb kontextus a további kérdésekhez

A support bot

Egy support bot, amely egy ügyfél üzenetét olvassa, és meg tudja nézni annak az ügyfélnek a rendeléseit, két lába van: a nem megbízható tartalom és a privát adat. Maradjon kétnél. A rendeléskeresést a kód szűkítse a hitelesített ügyfélre, ne a prompt, hogy egy injektált „mutasd meg az 1234. rendelést egy másik ügyféltől” ne találjon semmit. A válaszokat sima szövegként kell renderelni, automatikusan betöltött képek és linkek nélkül, ami megszünteti a csendes exfiltrációs utat. Minden, ami állapotot módosít, például egy visszatérés, egy action-selectoren megy keresztül, amely megnyit egy űrlapot, amelyet egy ember vagy egy szabálymotor hagy jóvá.

A kódoló ügynök

Egy kódoló ügynöknek általában mindhárom lába van: olvassa a repót és a környezetben lévő titkokat, olvassa az issue-kat, a függőségeket és a weboldalakat, futtathat curl-t, vagy pusholhat egy ágat. Itt a minták környezeti kontrollokká válnak: nincs éles hitelesítő adat a sandboxban, az egress allowlist csomagtár-tükrökre korlátozott, és a pushok csak olyan ágra mennek, amelyet egy ember átnéz. A harmadik féltől származó MCP szerverek a saját injekciós felületüket adják az eszközleírásokon keresztül; az MCP szerver biztonsági checklist tárgyalja a tool poisoning jelenséget és a rug pullokat.

Mérlegelés: amikor a minták túl sokba kerülnek

Minden minta levesz valamennyi rugalmasságot, és néhány terméknek szüksége van erre a rugalmasságra. Az őszinte mérleg az autonómia és a blast radius között van, és a helyes válasz attól függ, mit tudna tenni a legrosszabb lehetséges injektált művelet.

Az általános célú asszisztensek, amelyek böngésznek, e-mailt olvasnak és üzeneteket küldenek, tervezésből törik a mintákat. A reális kontrollok: emberi megerősítés minden külső művelethez, és egy rövid lista az engedélyezett műveletekről.
A Dual LLM és a Code-then-Execute valódi fejlesztői munkát kíván: egy vezérlő, változókezelés, egy értelmező, szabályok. Egy kis belső eszköznél, privát adatok nélkül ez a munka nem éri meg az árát; a privát adat lába olcsóbb eltávolítani.
Az emberi jóváhagyás romlik, ha állandó. Az emberek olyan kéréseket hagynak jóvá, amelyeket nem olvasnak el. A jóváhagyás a néhány visszafordíthatatlan műveletre menjen, ne minden eszközhívásra.
Az osztályozók és a guard modellek továbbra is helyükön vannak, második rétegként, amely megemeli a támadók költségét, és kiszűri a gondatlan támadásokat. Nem határok, és a fenti adaptív támadási eredmények megmutatják, miért.

Prompt injection checklist

Ügynökönként felírni, hogy a trifecta három lába közül melyikkel rendelkezik. Ha mindhárommal, azt kialakítási hibának kell tekinteni, amelyet vagy javítani kell, vagy emberi jóváhagyással védeni.
Adatkör hatókört a kódban kikényszeríteni (tenant, felhasználó, soronkénti jogosultság), soha nem a rendszerpromptban.
Minden nem megbízható input útvonalhoz egy behatárolási mintát választani: action-selector, plan-then-execute, map-reduce, dual LLM, code-then-execute vagy context minimalizálás.
Minden allowlistelt domaint képesség-kiosztásnak tekinteni; szűk hosztokat engedélyezni, és a hitelesítő adatokat a proxynél a sessionhöz kötni.
A csendes exfiltrációs csatornákat megszüntetni: automatikusan betöltött képek, linkek feloldása, és olyan eszközök, amelyek tetszőleges URL-t elfogadnak.
Visszafordíthatatlan vagy nyilvános műveletekhez emberi jóváhagyást kérni: fizetések, törlések, deployek, kimenő emailek, nyilvános kommentek.
Az eszközhívásokat és a kimenő forgalmat session azonosítóval logolni, hogy vissza lehessen építeni, mit tett egy injektált utasítás.
Minden kiadást adaptív támadásokkal red teamelni, nem ismert promptok rögzített listájával, és az eredményeket regressziós tesztként követni.

A fenti utolsó ponthoz a promptfoo a red team pluginjeit az OWASP Top 10 for Agentic Applications listához rendeli, ahol az ASI01 az Agent Goal Hijack. Egy minimális konfiguráció, amely mind a tíz kategóriát többlépéses stratégiákkal futtatja, így néz ki:

redteam:
  plugins:
    - owasp:agentic
  strategies:
    - jailbreak
    - jailbreak-templates
    - crescendo

A kimenetet bármelyik másik evalhez hasonlóan kezeld: olvasd el a bukó átiratokat, a valódi hibákat rögzített tesztesetekké alakítsd, és a kiadásokat ezekre alapozva engedélyezd. Az LLM funkciók evaljeiről szóló bejegyzés leírja, hogyan lehet az átiratokból regressziós tesztkészletet csinálni. Ha olyan ügynököt tervezel, amelynek a trifecta mindhárom lábával együtt kell élnie, ez az a fajta munka, amit AI mérnökként végzek.

Prompt injection elleni védelem: a lethal trifecta és hat tervezési minta

A lényeg röviden