A halálos hármas
A legjobb gondolati keret erre 2025 júniusából származik, és három összetevőt nevez meg:
- hozzáférés a privát adataidhoz,
- kitettség nem megbízható tartalomnak,
- képesség kifelé kommunikálni — olyan módon, ami adatot tud kivinni.
Bármelyik kettő biztonságos. Mind a három együtt nem.
Ez adja a least privilegegyakorlati fordítását is: nem kell mindent bezárni — elég az egyik lábat elvágni. Ha az agent olvashat privát adatot és megnézhet nem megbízható tartalmat, de nem tud kifelé hívni, akkor a kiszivárgáshoz nincs csatorna. Ha kifelé hívhat és privát adatot lát, de csak megbízható forrásból olvas, akkor nincs, aki utasítsa.
Tíz dokumentált eset
Ezek nem elméleti kockázatok. Mindegyik publikált, dátumozott eset.
| Dátum | Mi történt |
|---|---|
| 2025-05 | Nyilvános projektkódba rejtett utasítás kódolt kép-URL-en keresztül vitte ki a privát változtatások részleteit |
| 2025-05 | Publikus hibajegybe rejtett utasítás rávette az agentet, hogy privát tárolókat listázzon, és az adatot egy általa létrehozott nyilvános beküldésben tegye közzé |
| 2025-06 | Irodai asszisztens, kattintás nélküli adatszivárgás alternatív jelölési szintaxissal és egy engedélyezett átirányítón keresztül |
| 2025-08 | Ügyfélszolgálati jegybe rejtett, kódolással álcázott injekció → hitelesítő tokenek és kódadat kiszivárgása |
| 2025-09 | Értékesítési rendszer: az ügyféladatba ágyazott utasítás egy lejárt, de engedélyezett domainen keresztül vitte ki az adatot |
| 2025-10 | Képernyőképbe rejtett, emberi szemmel láthatatlan szöveg → böngészőagentek e-mail-címeket szivárogtattak |
| 2025-11 | Weboldalba rejtett utasítás → az agent felhőkulcsokat és kódrészleteket töltött fel egy naplózó szolgáltatásra |
| 2026-01 | Levelezőasszisztens: nem megbízható levélben lévő injekció → pénzügyi, jogi és egészségügyi adatok egy támadói űrlapra |
És kettő 2026-ból, amit érdemes külön kiemelni.
Az egyik a legtanulságosabb allowlist-történet, amit ismerek. Az agent kimenő forgalmát domainlistával korlátozták — helyesen. Csakhogy a listán rajta volt a szolgáltató saját API-ja. A támadó a promptban elhelyezett kulccsal feltöltette a fájlokat a szolgáltató saját fájlfeltöltő végpontjára, majd később letöltötte onnan. A korlát működött; a kivezető út a megbízhatónak tekintett listán volt.
A másik: egy irodai agent jóváhagyás nélkül küldött ki leveleket, külső képekkel — és a kép betöltése maga volt a szivárgási csatorna.
Ami ezekben közös
Három megállapítás, amit érdemes szó szerint megjegyezni. Az egyik eset kutatói így fogalmaztak:
- „nem az adott szerver kódjának hibája, hanem alapvető architekturális kérdés, amit az agent-rendszer szintjén kell kezelni";
- „nem egy konkrét agentre vagy kliensre jellemző — minden agentet érint, amelyik ezt a szervert használja, a modelltől és az implementációtól függetlenül";
- „a legfejlettebb, illesztett modellek is sebezhetők ezekkel a támadásokkal."
Vagyis: ez nem szoftverhiba, amit majd kijavítanak, és nem modellkérdés, amit a következő verzió megold. Ez az agent-architektúra tulajdonsága, és a jogosultságoknál lehet kezelni.
Van egy visszatérő minta is ezekben: majdnem mindegyik esetben egy „ártalmatlan" csatornán ment ki az adat — kép-URL, átirányítás, beküldés, űrlap. Nem adatexport, hanem valami, ami jogosnak látszott.
Mennyi joggal futnak valójában?
Itt jönnek a mérések, és nem hízelgőek.
| Mérés | Eredmény |
|---|---|
| 7 973 élő távoli szerver vizsgálata (2026. május) | 40,55% hitelesítés nélkül teszi elérhetővé az eszközeit |
| Ugyanott, 119 tesztelhető, hitelesítést használó szerver | mindegyikben találtak hibát, összesen 325-öt |
| 1 899 nyílt forráskódú szerver elemzése | 7,2% általános sebezhetőség, 5,5% eszközmérgezés |
| 19 200 leírás–kód pár, 2 214 szerverből | 9,93% inkonzisztens — az eszközleírás nem azt írja le, amit a kód csinál |
| 64 611 egyedi szerver futásidejű vizsgálata | a biztonsági szkennerek riasztásainak kevesebb mint fele valódi találat |
A 9,93% külön figyelmet érdemel. Az agent az eszközleírás alapján dönt, mit hívjon meg. Ha minden tizedik leírás nem azt írja le, amit a kód csinál, akkor az agent minden tizedik döntése rossz információn alapul — anélkül, hogy bárki hibázott volna szándékosan.
És a tágabb kép, felhőtelemetriából: a virtuális gépek 19–23%-a fut túlzott jogosultsággal, jelentős részük teljes adminisztrátori jogot tud szerezni. Az IAM-felhasználók 59%-ának van egy évnél régebbi hozzáférési kulcsa. (Ez a felmérés nem bontja külön az agenteket — de ebbe a környezetbe kerülnek be.)
A szűkítés eszköztára
A jó hír: erre van elsődleges dokumentáció, nem kell kitalálni.
A hatókör minimalizálása. A protokoll specifikációja külön szakaszt szentel neki, és felsorolja a túl tág jogosultság árát: nagyobb robbanási sugár egy ellopott tokennél, nehezebb visszavonás (egy mindent tudó token visszavonása minden folyamatot megállít), zajos audit (egy összevont jogosultság elfedi, mi volt a felhasználó szándéka), jogosultságláncolás (a támadó azonnal hívhat nagy kockázatú eszközt további emelés nélkül), és a hozzájárulás feladása — a felhasználó elutasítja a párbeszédpanelt, ha túl sok jogot kér.
A javasolt modell progresszív: minimális kezdő jogosultság (csak felderítés és olvasás), és célzott emelés akkor, amikor először van rá szükség.
A nevesített tipikus hibák: minden lehetséges jogosultság közzététele; helyettesítő karakteres vagy „mindent tudó" jogosultság; össze nem tartozó jogok egybecsomagolása, hogy később ne kelljen kérdezni.
Token-továbbadás — abszolút tiltás. A specifikáció kötelező formában mondja ki: a szerver nem fogadhat el olyan tokent, amit nem kifejezetten neki adtak ki.
Hálózati korlát. A specifikáció ajánlott szinten előírja a privát IP-tartományok blokkolását — és nevesíti közöttük a felhő metaadat-végpontját is. Ez az a cím, ahonnan egy kompromittált folyamat a futtatókörnyezet hitelesítő adatait kérheti le. Emellett: HTTPS kikényszerítése, átirányítási célok validálása, kimenő proxy.
Sandboxing. Helyi szervereknél: minimális alapértelmezett jogosultság, korlátozott fájlrendszer- és hálózati hozzáférés, és ahol lehet, olyan átvitel, ami csak a kliensnek enged hozzáférést.
És a legfrissebb iparági kockázati lista, ami külön tételként nevesíti az identitás- és jogosultság-visszaélést: „az ellopott hitelesítők révén jóval a szándékolt hatókörükön túl tudnak működni".
A recept
1. VÁGD EL AZ EGYIK LÁBAT
Privát adat / nem megbízható tartalom / kifelé menő
csatorna. Döntsd el, melyiket veszed ki — ne mind
a hármat próbáld egyszerre kezelni.
2. AZ ALLOWLISTÁT OLVASD EL VISSZAFELÉ IS
Nem az a kérdés, mit engedsz meg. Az, hogy a
megengedett célok közül melyiken lehet adatot KIVINNI.
Egy fájlfeltöltő végpont a listán = nyitott ajtó.
3. OLVASÁSSAL KEZDD, ÍRÁST KÜLÖN KÉRJ
Minimális kezdő jogosultság, és emelés akkor, amikor
először tényleg kell.
4. SEMMI CSILLAG A JOGOSULTSÁGBAN
A "teljes hozzáférés" és a helyettesítő karakter
pont az, amit a specifikáció tipikus hibaként nevesít.
5. BLOKKOLD A BELSŐ HÁLÓZATOT
Külön a felhő metaadat-végpontját. Ez a leggyakrabban
kifelejtett cím.
6. AZ ESZKÖZLEÍRÁS NEM DOKUMENTÁCIÓ
Minden tizedik nem azt írja le, amit a kód csinál.
Amit bekötsz, annak a kódját nézd meg, ne a leírását.
7. RÖVID ÉLETŰ HITELESÍTŐ
A mérés szerint az emberi fiókok 59%-ánál a kulcs
egy évnél régebbi. Az agenté ne legyen ilyen.
A második pont a legfontosabb, és a legkönnyebb elrontani. Az allowlistát mindenki azzal a kérdéssel írja meg, hogy „hova kell mennie az agentnek". A helyes kérdés: „a listán szereplő célok közül melyikre lehet adatot feltölteni?"
Tipikus félreértések
- „Ez egy sebezhetőség, majd javítják." A kutatók szerint nem egy termék kódjának hibája, hanem az agent-rendszer szintjén kezelendő architekturális kérdés.
- „Jobb modell megoldja." A publikált megállapítás szerint a legfejlettebb, illesztett modellek is sebezhetők.
- „Van allowlistám." Az allowlistán szereplő szolgáltatás is lehet kivezető csatorna — pontosan ez történt egy 2026-os esetben.
- „Az agent csak olvas." Ha közben nem megbízható tartalmat is olvas, és van bármilyen kimenő csatornája, a hármas összeáll.
- „Az eszközleírásból tudom, mit csinál." Egy 19 200 párt vizsgáló mérés szerint minden tizedik leírás nem egyezik a kóddal.
- „Van biztonsági szkennerünk." Egy 64 ezer szerveres vizsgálat szerint a riasztások kevesebb mint fele valódi találat.
Amit érdemes elvinni
A least privilege agenteknél nem óvatosság kérdése, hanem a kockázat egyetlen kezelhető pontja — mert a prompt injectionellen nincs megbízható technikai védelem, és a modell fejlődése sem oldja meg.
Egy mondatban: nem azt kell eldönteni, mennyire bízol az agentben, hanem azt, hogy meddig ér el, ha megtévesztik.
És egy ellenőrzés, ami öt percbe kerül: nézd meg a kimenő forgalom engedélyezett céljait, és kérdezd meg mindegyikről, lehet-e oda adatot feltölteni. Ha a válasz igen, akkor az a hármas harmadik lába — akármilyen megbízható is a cél.
Hogy hol érdemes emberi jóváhagyást tenni a láncba, arról az ember a folyamatban poszt szól mérésekkel; a bekötött eszközök szabványáról és annak biztonsági oldaláról pedig az MCP poszt. A legszélsőségesebb eset a saját gépeden futó személyes agent, ahol a határokat végig neked kell megépítened — arról a saját gépen futó agentek témájú írás szól.