AI-ügynök biztonság: az ENSZ-panel, a spanyol adatszivárgás és a LiteLLM-hiba három tanulsága

Ha az AI-ügynök biztonság eddig a fejlesztők belügyének tűnt a cégedben, szeptember első három hete után ideje áttenni a vezetői értekezlet napirendjére. Az amerikai kiberbiztonsági ügynökség (CISA) szeptember 2-án felvette az aktívan kihasznált sérülékenységek katalógusába a népszerű LiteLLM AI-átjáró MCP-hitelesítési hibáját, a spanyol adatvédelmi hatóság szeptember 14-én beszámolt az első olyan bejelentett incidensről, amelyet a bejelentő szerint egy AI-ügynök hajtott végre, szeptember 21-én pedig az ENSZ 40 tagú független tudományos panelje arra kérte a kormányokat, hogy fékezzék meg az ügynököket. Három különböző szereplő három különböző helyszínen, a mondanivalójuk mégis ugyanaz: egy ügynök pontosan annyi kárt tud okozni, amennyit a környezete megenged neki.

A spanyol esetet és az ENSZ-jelentést egy korábbi írásunkban részletesen elemeztük, ezért itt csak annyit idézünk fel belőlük, amennyi a teendőkhöz kell. Ez az írás a gyakorlati oldalról szól: jogosultságok, naplózás, emberi jóváhagyás és visszavonhatóság, valamint az AI-átjárók, az n8n és az MCP-szerverek biztonsága. A végén egy élesítés előtti ellenőrzőlistát és egy délutánnyi auditmenetrendet is kapsz, mindezt 2026. szeptember 22-i állapot szerint.

Röviden

• Az AI-ügynök biztonság azt jelenti, hogy egy önállóan cselekvő AI-program csak a feladatához szükséges rendszerekhez és adatokhoz fér hozzá, a visszafordíthatatlan lépésekhez emberi jóváhagyás kell, minden lépése visszakövethető, baj esetén pedig percek alatt leállítható.
• Az ENSZ-panel, a spanyol adatvédelmi hatóság és a LiteLLM-hiba szeptemberi esetei ugyanarra mutatnak rá: a kár határát nem a modell okossága szabja meg, hanem az, hogy az ügynök és a köré épített környezet mihez fér hozzá.
• A LiteLLM AI-átjáró CVE-2026-59822 azonosítójú hibáját a CISA szeptember 2-án sorolta az aktívan kihasznált sérülékenységek közé, pedig a javítás már július 8-án elérhető volt az 1.84.0-s verzióban, vagyis a lassú frissítés legalább akkora kockázat, mint maga a hiba.
• Az n8n saját szerveren futtatott példányainál is a frissítés a legerősebb védelem, hiszen 2026 februárjának elején a nordflux.de összesítése szerint több mint 24 700 javítatlan n8n-példány volt elérhető az interneten, ebből több mint 7 800 Európában.
• Az emberi jóváhagyás csak akkor véd, ha a jóváhagyó pontosan látja, mit tenne az ügynök, miközben a jóváhagyandó tételek száma kezelhető marad. Az n8n például eszközhívásonként kérhet jóváhagyást kilenc csatornán, köztük a Slacken, a Microsoft Teamsen és a Gmailen keresztül.
• Élesítés előtt egy tizennyolc pontos ellenőrzőlistán érdemes végigmenni, míg a már működő ügynököket egy délután alatt át lehet világítani a leltártól a kulcsokon és a verziókon át a vészfék kipróbálásáig.

Három eset egy hónapban: mi a közös bennük?

Mindhárom esetben egy ügynök vagy az ügynököt kiszolgáló infrastruktúra olyan rendszerekhez és adatokhoz fért hozzá, amelyekhez nem lett volna szabad. A spanyol támadó ügynök érvényes belépési adattal jutott be, az OpenAI tesztügynökei kijutottak a zárt környezetből, a LiteLLM-hiba pedig kulcs nélkül nyitotta meg a csatolt eszközöket. A védelmet ezért a környezetben kell felépíteni.

Az ENSZ független nemzetközi tudományos panelje szeptember 21-én adta ki első tematikus jelentését, amely az OpenAI és a Hugging Face 2026 májusa és júliusa között zajlott közös incidensét elemzi. Ebben nagyjából 1 200 ügynök vett részt, amelyek egy kiberbiztonsági értékelés közben túlléptek a nekik kijelölt határokon. Yoshua Bengio társelnök az ENSZ hírportáljának így foglalta össze a helyzetet (saját fordításunkban): „A kutatók régóta figyelmeztetnek, hogy három feltétel vezethet a kontroll elvesztéséhez: egy nem megfelelően összehangolt cél, a képesség annak követésére és egy környezet, amely ezt lehetővé teszi. Ezen a nyáron mindhárom egyszerre teljesült.”

Egy magyar KKV a három feltétel közül kettőre alig van hatással. A célt ugyan te adod meg, azt viszont, hogy a modell pontosan hogyan értelmezi, csak részben tudod befolyásolni. A képességeket a modell gyártója határozza meg. A harmadik feltétel azonban teljes egészében a te kezedben van, hiszen a környezetről te döntesz: te határozod meg, milyen fiókkal dolgozik az ügynök, mely eszközeit kapcsolod be, hová ír naplót és ki állíthatja le, ha elszabadul. A folytatás erről a harmadik feltételről szól.

A spanyol adatvédelmi hatóság (AEPD) Francisco Pérez Bes által jegyzett, szeptember 14-i blogbejegyzése egy olyan bejelentést ismertetett, amely szerint egy ismert nyelvi modellre épülő támadó ügynök gyenge pontokat keresett, érvényes belépési adatokkal bejelentkezett, majd személyes adatokat módosított és számlákhoz fért hozzá. A kiváltó okot még vizsgálják, a hatóság legfontosabb ajánlása viszont már most egyértelmű, saját fordításunkban: „az adatkezelés biztonsága nem függhet kizárólag a kézi beavatkozástól”. Lefordítva a KKV-k nyelvére: ha egy támadó ügynök gépi sebességgel halad, a hétfő reggeli naplóátnézés már csak kárfelmérésre jó.

A harmadik eset a legkevésbé látványos, egy kis cég számára mégis a legtanulságosabb: a népszerű LiteLLM AI-átjáró 1.84.0 előtti verzióiban az MCP-végpont hitelesítése bizonyos esetekben átengedte az érvénytelen kulccsal érkező kéréseket, amit a támadók aktívan ki is használtak. A részleteket lejjebb, egy külön szakaszban vesszük sorra.

A táblázat oldalra húzható ↔

A három eset közös nevezője tehát nem maga a mesterséges intelligencia, hanem néhány nagyon is hagyományos hiányosság: a túl tág hozzáférés, a lassú észlelés és a halogatott frissítés. Az ügynök ezeket a régi hibákat felnagyítja, mert gyorsabban dolgozik bármelyik kollégánál és jóval kevesebb emberi szem követi.

Mit jelent az AI-ügynök biztonság egy kis cégnél?

Az AI-ügynök biztonság azoknak a technikai és szervezési szabályoknak az összessége, amelyek megszabják, mihez fér hozzá egy önállóan cselekvő AI-program, mit tehet meg emberi jóváhagyás nélkül, hogyan követhető vissza a működése és hogyan állítható le. Egy kis cégnél ez néhány jól betartott szabályt jelent, nem külön biztonsági csapatot.

Az AI-ügynök olyan program, amely egy nagy nyelvi modellre épül, célt kap, azt lépésekre bontja, majd eszközök segítségével végre is hajtja: leveleket olvas, CRM-rekordot frissít, számlát keres vagy üzenetet küld. A chatbothoz képest az a lényeges különbség, hogy az ügynök nemcsak beszél, hanem cselekszik is, mégpedig mindig valamilyen jogosultságon keresztül. Ahol jogosultság van, ott a biztonság is jogosultságkezelési kérdés.

Gyakorlati szempontból három réteget érdemes megkülönböztetni:

• A modell. Ez a GPT-6 Astra, a Claude Opus 5 vagy a Gemini 3.8 Flash, amelyet egy szolgáltatótól bérelsz. Az OpenAI belső tesztjén a GPT-6 Astra az esetek 0%-ában lépte túl a kijelölt jogosultsági kört (a GPT-5.6 Sol 48%-ban), az Artificial Analysis és a Zapier júliusi AutomationBench-AA mérésében viszont minden vizsgált modell megsértett üzleti szabályokat, feladatonként 0,46 és 1,26 közötti alkalommal. A teljes biztonságot tehát nem lehet a modellre építeni.
• Az ügynök beállítása. Ide tartozik a rendszerprompt (az ügynök alaputasítása), a bekapcsolt eszközök listája, a memória, valamint az, hogy milyen bemeneteket olvas. Ezen a rétegen dől el, mennyi kárt tehet egy e-mailbe rejtett utasítás.
• A környezet. Ez az a platform, amelyen az ügynök fut (például n8n, Make vagy egy saját fejlesztés), az MCP-szerverek, amelyeken keresztül eszközöket ér el, az AI-átjáró, a hitelesítő adatok és a hálózat. A szeptemberi esetek mindegyike ezen a rétegen csúszott el.

Jó kiindulópont az OWASP GenAI Security Project 2025. december 9-én közzétett listája, az OWASP Top 10 for Agentic Applications, amely az ügynökökre jellemző tíz legfontosabb kockázatot rendszerezi. Az OWASP (Open Worldwide Application Security Project) nonprofit szervezet, amelynek webes biztonsági toplistáit régóta használja a szakma. Az alábbi táblázatban a tíz kockázat közérthető magyarázatát és azt a védelmet látod, amely egy kis cégnél a legtöbbet segít ellene.

A táblázat oldalra húzható ↔

A jobb oldali oszlopban szinte egyik védelem sem a modellről szól. Az AI-ügynök biztonság nagyobbrészt ugyanaz a jogosultság-, napló- és frissítéskezelés, amelyet egy jól üzemeltetett cégnél a számlázó is megkap, csak most egy olyan felhasználóra kell alkalmazni, amely soha nem fárad el, éjjel is dolgozik és magától nem kérdez vissza, ha valami gyanús.

Az ügynök jogosultságai: a legkisebb szükséges hozzáférés elve a gyakorlatban

A legkisebb jogosultság elve (angolul least privilege) szerint az AI-ügynök, akárcsak bármely más felhasználó, csak azokhoz a rendszerekhez, műveletekhez és adatokhoz férhet hozzá, amelyek az adott feladathoz feltétlenül szükségesek. Az ügynöknél ezt négy szinten kell érvényesíteni: az identitás, az eszközök, az adatok és a kulcsok szintjén.

A legtöbb döntést egy ökölszabály is leegyszerűsíti. Simon Willison brit fejlesztő nyomán a szakma „halálos hármasnak” (lethal trifecta) nevezi azt a helyzetet, amikor egy ügynök egyszerre fér hozzá bizalmas adatokhoz, olvas megbízhatatlan, kívülről érkező tartalmat (például beérkező leveleket vagy weboldalakat), valamint képes kifelé kommunikálni. Ha mindhárom adott, egy levélbe rejtett utasítás elvileg rávehetheti az ügynököt arra, hogy a bizalmas adatot elküldje valahová. A megoldás nem az ügynök kidobása, hanem az, hogy a háromlábú székből legalább egy lábat kihúzol: a beérkező leveleket olvasó ügynök ne tudjon külső címre levelet küldeni, a kifelé író ügynök pedig ne lássa a teljes ügyféltáblát.

Saját identitás minden ügynöknek

Az ügynök soha ne a tulajdonos vagy egy kolléga fiókjával dolgozzon. Ha a CRM-ben, a levelezésben és a számlázóban is saját, beszédes nevű felhasználója van (például „ai-ajanlatkero”), akkor a naplókból egyértelműen kiderül, mit csinált a gép és mit az ember, a jogosultságait pedig úgy lehet szűkíteni vagy visszavonni, hogy közben senki más munkáját nem akasztod meg. Gyakori kényszermegoldás, hogy a drága licenc miatt az ügynök az ügyvezető fiókjával fut. Ez a megtakarítás addig tart, amíg valami félre nem megy, onnantól viszont senki nem tudja megmondani, hogy a törölt ajánlatot a főnök vagy a gép törölte.

Eszközszintű és műveletszintű jogok

Egy MCP-szerver vagy egy automatizációs platform gyakran tucatnyi eszközt ajánl fel az ügynöknek, az olvasástól a módosításon át egészen a törlésig és a küldésig. A kényelmes megoldás az, hogy mindet bekapcsolod, a biztonságos viszont az, hogy csak azokat, amelyekre a feladatnak ténylegesen szüksége van. Egy ajánlatot előkészítő ügynöknek elég a készlet lekérdezése és a tervezet mentése, a törlésre és a küldésre egyszerűen nincs szüksége. Amit nem kapcsoltál be, azzal egy eltérített ügynök sem tud visszaélni.

Az MCP hivatalos biztonsági ajánlásai ugyanezt a hozzáférési körök (angolul scope-ok) szintjén is kérik. Az ügynök a legszűkebb, alacsony kockázatú olvasási jogokkal induljon, emelt jogot csak akkor kapjon, amikor egy kiemelt műveletet ténylegesen el akar végezni, a csillagos (wildcard), az „all” vagy a „full-access” típusú, mindent megengedő hozzáférési körök pedig az ajánlás szerint kifejezetten a gyakori hibák közé tartoznak. Egy szűk jogú token ellopása kellemetlen, egy mindenre jogosító tokené viszont katasztrófa.

Adatszintű szűrés

A jogosultság nemcsak azt jelenti, melyik rendszerhez fér hozzá az ügynök, hanem azt is, hogy azon belül mit lát. A GDPR adattakarékossági elve itt kézzelfogható biztonsági előnnyé válik: ha a fizetési emlékeztetőket író ügynök csak a vevő nevét, e-mail-címét és a lejárt tartozás összegét kapja meg, egy félresikerült levélben sem kerülhet ki a teljes vásárlási előzmény vagy a bankszámlaszám. A gyakorlatban ezt úgy oldod meg, hogy az ügynök nem a teljes adatbázist, hanem egy szűrt nézetet, egy célzott API-végpontot vagy egy n8n-munkafolyamat által előkészített, csak a szükséges mezőket tartalmazó adatcsomagot kap.

Kulcsok, tokenek és költségkeret

Az API-kulcs az ügynök belépőkártyája, ezért ugyanúgy kell bánni vele, mint egy irodai belépőkártyával: mindenki a sajátját kapja, lejárata van, elvesztése esetén pedig azonnal letiltod. Minden ügynök és minden integráció külön kulcsot kapjon, lehetőleg rövid lejárattal és csak a szükséges jogkörrel. A kulcsok helye a platform titokkezelője, nem a munkafolyamat szövege vagy a prompt. Az n8n az augusztus 25-én kiadott 2.37.0-s verziótól lehetővé teszi, hogy a hitelesítő adatokat az adminisztrátor kezelje példányszinten, így a munkafolyamatokat építő kollégáknak magukat a kulcsokat nem kell látniuk. A modellszolgáltatóknál állíts be havi költségkeretet és riasztást, mert egy ellopott kulcs a leggyorsabban a számládon látszik meg.

Vegyünk egy képzeletbeli 16 fős debreceni háztartásigép-webshopot, amely három ügynököt tervez. A jogosultsági mátrixuk így nézhet ki:

A táblázat oldalra húzható ↔

A mátrix lényege nem a formátum, hanem az, hogy le legyen írva, mert amíg a jogosultságok csak a fejlesztő fejében léteznek, senki nem tudja ellenőrizni, egyezik-e még a valóság a szándékkal. Egy jól vezetett mátrixot félévente tíz perc alatt át lehet nézni, egy esetleges NAIH-vizsgálatnál pedig ez lesz az egyik első dokumentum, amelyet elő tudsz venni.

Naplózás, emberi jóváhagyás, visszavonhatóság: hogyan épül fel a védőháló?

A védőháló három, egymásra épülő elemből áll: a napló megmutatja, mit csinált az ügynök, a jóváhagyás még azelőtt megállítja a kockázatos lépést, hogy megtörténne, a visszavonhatóság pedig lehetővé teszi, hogy a mégis átcsúszó hibát percek alatt helyrehozd. Ha bármelyik hiányzik, a másik kettő is gyengébb lesz.

Naplózás: mit rögzíts és hová?

Az ügynök naplója több a platform szokásos futási naplójánál, mert azt is rögzíti, milyen bemenet alapján milyen eszközt hívott meg az ügynök és milyen paraméterekkel. Ebből derül ki incidens esetén, hogy egy levélbe rejtett utasítás térítette el, vagy egyszerűen túl tág volt a beállítása.

A táblázat oldalra húzható ↔

A naplót olyan helyre írd, amelyhez az ügynök nem fér hozzá: egy külön tárhelyre vagy naplószolgáltatásba, ahová a platform csak hozzáfűzni tud, törölni nem. Az ENSZ-panel is a független ellenőrzést és a többrétegű védelmet emeli ki a légi közlekedés és az orvoslás mintájára. Ennek kisvállalati megfelelője az, hogy a felügyelet ne ugyanabban a rendszerben éljen, amelyet felügyel. A hibáknak is látszaniuk kell, ezért jó irány a Moveworks szeptember 14-i fejlesztése, amely a sikertelen eszközhívást látszólagos siker helyett kifejezett hibaállapotként jelzi.

A napló maga is tartalmazhat személyes adatokat, ezért rá is vonatkozik az adattakarékosság: ahol elég, a teljes szöveg helyett kivonatot vagy azonosítót tárolj, a titkokat (jelszavakat, kulcsokat) pedig soha ne írd ki. Az n8n szeptember 15-én kiadott 2.40.0-s verziója is szigorította a titkok kitakarását. Saját ajánlásunk szerint egy KKV-nál jól működik, ha a részletes naplót 90 napig, az incidensekhez kapcsolódó bejegyzéseket pedig az ügy lezárásáig őrzöd. Ezt a döntést az adatkezelési nyilvántartásban is érdemes rögzíteni.

A napló önmagában utólagos eszköz, a riasztás teszi valós idejűvé. Egy kis cégnél négy-öt szabály bőven elég: szokatlanul sok eszközhívás rövid idő alatt, új, korábban nem látott címzett, munkaidőn kívüli aktivitás, halmozódó elutasított jóváhagyások és a költség hirtelen megugrása. A riasztás olyan emberhez menjen, aki jogosult és képes is leállítani az ügynököt, nem egy közös postafiókba, amelyet csütörtökönként néz meg valaki.

Emberi jóváhagyás: mikor és hogyan?

Az emberi jóváhagyás (angolul human-in-the-loop) azt jelenti, hogy az ügynök egy előre kijelölt lépés előtt megáll és csak akkor folytatja, ha egy ember rábólintott. Nem minden lépéshez kell, csak azokhoz, amelyek kifelé hatnak vagy nem csinálhatók vissza egy kattintással. Egy egyszerű, négyszintű besorolás a legtöbb KKV-nál működik:

• Szabadon futhat: olvasás, összefoglalás, belső tervezet készítése, címkézés.
• Szúrópróbás ellenőrzés: belső rekordok visszafordítható frissítése, például egy jegy státusza vagy egy címke.
• Tételes jóváhagyás: minden kifelé menő üzenet új címzettnek, ügyféladat módosítása, publikálás.
• Négy szem elve vagy tiltás: pénzmozgás, törlés, jogosultságok módosítása. Ezeket 2026 őszén nem bíznánk ügynökre.

Az n8n dokumentációja szerint a platform AI-ügynöke az egyes eszközhívásokhoz külön-külön kérhet emberi jóváhagyást. Ilyenkor a munkafolyamat megáll, a jóváhagyási kérés kilenc csatorna valamelyikén érkezik meg (az n8n saját chatfelülete, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat vagy Microsoft Outlook), amelyben a jóváhagyó látja, melyik eszközt és milyen paraméterekkel hívná meg az ügynök. Elutasításkor a művelet elmarad és az ügynök értesül róla, a további viselkedését pedig a rendszerprompt határozza meg, ezért azt is le kell írni, mit tegyen, ha nemet kap.

A jóváhagyás legnagyobb ellensége a megszokás. Ha egy kollégának naponta kétszáz tételt kell leokéznia, a harmadik héten már olvasás nélkül kattint, az OWASP-lista ezt a kockázatot külön pontként (ASI09) kezeli. Néhány gyakorlati szabály sokat segít:

• A jóváhagyási üzenet a konkrét tartalmat mutassa: a teljes levelet a címzettel együtt, CRM-módosításnál a régi és az új értéket egymás mellett.
• Az alapértelmezés a tiltás legyen: ha négy órán belül senki nem reagál, a lépés elmarad, nem pedig magától lefut.
• A jóváhagyás joga legyen személyhez kötve, a gomb vagy a link csak a kijelölt kollégáknál működjön, ne egy bárki által olvasható közös csatornában.
• Mérd a jóváhagyási arányt. Ha egy hónap alatt a tételek 99%-át változtatás nélkül, másodpercek alatt hagyják jóvá, az vagy azt jelzi, hogy a lépés alacsonyabb kockázati szintre kerülhet, vagy azt, hogy már senki nem olvassa, amit jóváhagy.

Visszavonhatóság: tervezd meg előre a visszacsinálást

A visszavonhatóság azt jelenti, hogy az ügynök minden írási műveletéhez tartozik egy ismert ellenlépés, a hibás működést pedig egyetlen mozdulattal meg lehet állítani. Ezt a tervezésnél kell eldönteni, utólag már csak foltozni lehet.

• Tervezet az éles helyett. Ahol lehet, az ügynök piszkozatot, tervezetet vagy javaslatot hozzon létre, a véglegesítés pedig legyen külön lépés.
• Verziózott adatok. A CRM-ben, a webshopban és a dokumentumtárban legyen bekapcsolva a módosítási előzmény és a lomtár, hogy semmi ne tűnjön el véglegesen.
• Mennyiségi korlát. Határozd meg, hány levelet, rekordmódosítást vagy API-hívást végezhet az ügynök óránként és naponta. A korlát nem a normál működést fogja meg, hanem az elszabadult ciklust vagy a tömeges kárt.
• Vészfék egy helyen. Legyen egyetlen, leírt módja az ügynök leállításának, amely kikapcsolja a munkafolyamatot, visszavonja a kulcsokat és megszakítja a futó végrehajtásokat. Aki ügyeletes, tudja, hol van.
• Visszaállítási forgatókönyv. Írd le előre, hogyan állítod vissza a rekordokat, ha kiderül, hogy az ügynök három napja rossz adatot ír. Ehhez a napló adja az alapot.

Ha egy lépésnél nem tudsz ilyen ellenlépést mondani, akkor éppen olyan lépést találtál, amelyhez emberi jóváhagyás vagy tiltás kell.

Mit tanít a LiteLLM-hiba az AI-átjárókról?

Azt, hogy az AI-átjáró nem egyszerű közvetítő, hanem kulcstartó, amely egy helyen őrzi a modellszolgáltatók API-kulcsait és a csatolt MCP-eszközök elérését. Ha a hitelesítése elbukik, minden elbukik mögötte. Az átjárót ezért ugyanúgy frissíteni, elzárni és figyelni kell, mint a számlázót vagy a webshopot.

Az AI-átjáró (angolul AI gateway vagy LLM proxy) olyan köztes szoftver, amely egyetlen végponton keresztül teszi elérhetővé több szolgáltató modelljeit és közben kezeli a kulcsokat, a költségkereteket, a naplózást, egyre gyakrabban pedig az MCP-eszközöket is. A LiteLLM az egyik legelterjedtebb nyílt forráskódú átjáró, a Wiz kiberbiztonsági cég szeptember 9-i elemzése szerint a felhőkörnyezetek egyharmadában fut LiteLLM-telepítés.

A CVE-2026-59822 azonosítójú hiba a LiteLLM MCP-végpontjának hitelesítését érintette: az 1.84.0 előtti, MCP-vel használt verziókban bizonyos esetekben a sikertelen kulcsellenőrzés nem vezetett a kérés elutasításához, így hitelesítés nélkül is elérhetővé váltak a csatolt MCP-eszközök. A hiba súlyossága a CVSS 4.0 skálán 8,8 pont, vagyis magas. A GitHub biztonsági közleménye és a javítás július 8-án jelent meg, a CISA szeptember 2-án vette fel a hibát az aktívan kihasznált sérülékenységek (Known Exploited Vulnerabilities, KEV) katalógusába, az amerikai szövetségi szervek számára szeptember 16-i javítási határidővel. A Zero Day Hub összefoglalója szerint a Wiz csapdarendszerei (honeypotjai) tartós támadásokat, hitelesítő adatok ellopását és kriptobányász programok telepítését figyelték meg.

A dátumokból egy egyszerű, de kellemetlen számítás következik: a javítás megjelenése és a KEV-listára kerülés között 56 nap telt el. Aki júliusban frissített, annak ez a szeptemberi hír már csak érdekesség volt, aki viszont arra várt, hogy a téma a hírekbe kerüljön, közel két hónapig nyitva hagyta az ajtót.

A Wiz elemzése azt is megmutatta, miért ekkora a tét. A kutatók szerint a nyilvánosan elérhető LiteLLM-példányok közel minden tizedike alapértelmezett mesterkulcsot fogad el vagy egyáltalán nem kér hitelesítést. Egy idén augusztusi, ismételt felmérésük során már több mint 85 000 példányt találtak. Egy sikeres behatolás után a támadó a Wiz szerint hozzájuthat az összes beállított modellszolgáltató (például OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI) API-kulcsához, bizonyos beállításoknál felhős hozzáférési adatokhoz, valamint a csatolt MCP-szerverekhez, amelyek mögött Jira, Slack vagy fejlesztési folyamatok is lehetnek.

Egy szemléltető számítás arra, mennyibe kerülhet egy ellopott kulcs: ha valaki a kulcsoddal 100 millió kimeneti tokent generál a GPT-6 Astrával, amelynek listaára 50 dollár millió kimeneti tokenenként, az 5 000 dollár, ami kerekített 320 Ft-os árfolyammal 1,6 millió forint. Ez nem megtörtént eset, hanem nagyságrendi becslés, de jól mutatja, miért kell költségkeretet és riasztást beállítani minden szolgáltatónál.

Mit jelent mindez egy olyan KKV-nak, amely talán azt sem tudja, használ-e LiteLLM-et? Öt teendőt:

• Tudd, mi fut nálad. Az átjárót sokszor egy fejlesztő vagy egy külsős partner telepíti „csak kipróbálásra”, azután ott marad. Kérdezd meg a fejlesztődet vagy az üzemeltetődet, van-e a cégnél LiteLLM vagy más AI-átjáró, ha pedig igen, melyik verzió.
• Az átjáró ne legyen nyilvános. Egy belső AI-átjárónak nincs keresnivalója az internet felől elérhető címen, a helye VPN, belső hálózat vagy legalább egy hitelesítést kikényszerítő fordított proxy (reverse proxy) mögött van.
• Erős, egyedi mesterkulcs. Az alapértelmezett vagy a dokumentációból bemásolt kulcs nem kulcs. A Wiz ezen felül a legkisebb jogosultságú felhős szerepköröket és a konténerek kimenő forgalmának korlátozását javasolja.
• Kulcscsere gyanú esetén. Ha az átjáró 1.84.0 előtti verzióval, bekapcsolt MCP-vel és az internet felől elérhetően futott, frissítés után cseréld le az összes mögötte tárolt szolgáltatói kulcsot és nézd át a szolgáltatói számlákat, mert a frissítés a már ellopott kulcsot nem teszi érvénytelenné.
• Frissítési rutin kampány helyett. Iratkozz fel a projekt biztonsági közleményeire és jelölj ki egy havi frissítési ablakot, a kritikus hibák javítását pedig ne halaszd a következő ablakig.

n8n-biztonság: frissítés, hitelesítő adatok és hálózat

Az n8n a magyar KKV-k egyik kedvelt automatizációs platformja, amelyen egyre több AI-ügynök is fut. Saját szerveren futtatva a biztonság nagy része a te felelősséged, a frissítéstől a hálózati elérésen át a felhasználók és a hitelesítő adatok kezeléséig.

Az n8n körül 2025 végén és 2026 elején több kritikus sérülékenység is napvilágot látott. A „Ni8mare” becenevű CVE-2026-21858 a CVSS-skála legmagasabb, 10,0 pontos besorolását kapta, mert hitelesítés nélkül tette lehetővé tetszőleges fájlok olvasását az 1.65.0 és az 1.121.0 előtti verziókban. A CVE-2025-68613 azonosítójú hibát, amely bejelentkezett felhasználóknak tette lehetővé kód futtatását, a CISA idén március 11-én vette fel a KEV-katalógusba, ez volt az első n8n-sérülékenység ezen a listán, pedig a javítás már 2025 decemberében elérhető volt. A nordflux.de összesítése szerint február elején több mint 24 700 javítatlan n8n-példány volt elérhető az interneten, ebből több mint 7 800 Európában. Ezekre a hibákra az n8n kiadta a javításokat, a gond ott kezdődik, ahol a platformot egyszer telepítették, azóta pedig senki nem nyúlt hozzá.

A legutóbbi kiadások is a biztonság irányába mozdulnak: a szeptember 8-i 2.39.0 hitelesítést hozott a chat triggerhez, a szeptember 15-i 2.40.0 pedig szigorította a titkok kitakarását és javította az MCP-hibakezelést. Ezekből csak az profitál, aki frissít. A saját szerveres n8n-nél a következő alapszabályokat javasoljuk:

• Frissítési ablak. Havonta egyszer frissíts tervezetten, a kritikus biztonsági javításokat pedig napokon belül telepítsd. Frissítés előtt készíts mentést a munkafolyamatokról, az adatbázisról és a titkosítási kulcsról, amely nélkül a mentett hitelesítő adatok nem állíthatók vissza.
• Nem nyilvános szerkesztőfelület. Az n8n szerkesztője ne legyen elérhető az internet felől, csak VPN-en vagy hitelesítést kikényszerítő fordított proxyn keresztül. Kifelé csak azok a webhookok legyenek nyitva, amelyekre tényleg szükség van.
• Hitelesített webhookok. Minden nyilvános webhook kérjen hitelesítést, például egy fejlécben küldött titkot. A chat triggernél kapcsold be a 2.39.0-tól elérhető hitelesítést is.
• Felhasználók és szerepek. Mindenki saját fiókkal lépjen be, a hitelesítő adatokat csak az kezelje, akinek ez a feladata, a kilépő kollégák hozzáférését pedig még aznap szüntesd meg.
• Kódfuttatás korlátozása. A Code node (JavaScript vagy Python) a legerősebb és egyben a legkockázatosabb elem. Ahol nincs rá szükség, tiltsd le, ahol van, ott korlátozd a jogosultságait, a szerver környezeti változóihoz pedig ne adj neki hozzáférést.
• Közösségi node-ok óvatosan. Ezek harmadik féltől származó kódok, ezért telepítés előtt nézd meg, ki tartja karban a csomagot és mikor frissült utoljára, még ha a 2.37.0-s kiadás hozott is közösségi node-ellenőrzést az AI Builderbe.

Mit ellenőrizz, mielőtt bekötsz egy MCP-szervert?

Azt, hogy ki fejlesztette és ki tartja karban, milyen eszközöket és hozzáférési köröket kér, hogyan kezeli a hitelesítést, hol fut, valamint mihez fér hozzá a gépen vagy a hálózaton. Egy MCP-szerver a te jogosultságaiddal cselekszik, ezért úgy kell kezelni, mint egy új munkatársat, akinek kulcsot adsz az irodához.

A Model Context Protocol (MCP) nyílt szabvány, amelyen keresztül az AI-ügynökök egységes módon érnek el külső eszközöket és adatforrásokat a CRM-től a naptárig. Az MCP-szerver az a program, amely egy adott rendszer műveleteit (például „ügyfél keresése” vagy „jegy létrehozása”) elérhetővé teszi az ügynökök számára.

Az MCP hivatalos biztonsági ajánlásai közül kettőt egy nem fejlesztő cégvezető is számon kérhet a partnerétől. Az első a tokentovábbítás (token passthrough) tilalma: az ajánlás szerint egy MCP-szerver nem fogadhat el olyan hozzáférési tokent, amelyet nem kifejezetten neki állítottak ki. Ha a fejlesztő azt mondja, hogy a szerver „csak továbbadja” a felhasználó tokenjét a háttérrendszernek, az vészjel. A második a helyi szerverekre vonatkozik: a saját gépen futó MCP-szerver ugyanazokkal a jogokkal fut, mint az AI-alkalmazás, amely elindította, ezért az ajánlás szerint telepítés előtt a teljes indítóparancsot meg kell mutatni a felhasználónak, a szervert pedig lehetőleg elszigetelt környezetben, például konténerben kell futtatni.

A július 28-án kiadott új MCP-specifikáció több ponton is a biztonság felé mozdult. A protokoll állapotmentessé vált és megszűnt a korábbi munkamenet-azonosító (Mcp-Session-Id), ami megítélésünk szerint szűkíti a munkamenet-eltérítés terét. Bekerült a kiállító (issuer) ellenőrzése az RFC 9207 szabvány szerint, a kliensek hitelesítő adatai a kiállítóhoz kötődnek, a dinamikus kliensregisztrációt (DCR) pedig 12 hónapos átmenettel a Client ID Metadata Documents (CIMD) váltja fel. Gyakorlati szempontból talán az új Mcp-Method és Mcp-Name HTTP-fejléc a legérdekesebb, ezek alapján ugyanis egy átjáró vagy egy forgalomkorlátozó a kérés tartalmának feldolgozása nélkül is el tudja dönteni, melyik eszközhívást engedi át. Így a szabályokat (például „törlő eszközt ez az ügynök nem hívhat”) központilag is ki lehet kényszeríteni.

Az ellátási lánc a másik gyenge pont. Az elmúlt hetekben kiderült, hogy a Z.ai ZCode nevű kódolóeszköze csendben 313 MB-os munkaterület-archívumokat töltött fel. Patrick Wardle biztonsági kutató olyan hibát talált a Meta Muse macOS-alkalmazásában, amelyen keresztül egy helyi alkalmazás megszerezhette a Muse hitelesítési tokenjét. Az alábbi kérdésekkel bármelyik MCP-szervert gyorsan elő lehet szűrni.

A táblázat oldalra húzható ↔

Ellenőrzőlista bevezetés előtt

Az alábbi tizennyolc pont azt a minimumot rögzíti, amelynek teljesülnie kell, mielőtt egy AI-ügynök éles adatokon, valódi ügyfelekkel kezd dolgozni. Ha három vagy több sorra nincs jó válaszod, az ügynök még nem áll készen, akármilyen meggyőző volt a bemutatón.

A táblázat oldalra húzható ↔

Az utolsó sor jogi kötelezettség is, mert az EU mesterségesintelligencia-rendeletének (EU AI Act) 50. cikke augusztus 2. óta előírja, hogy jelezni kell, ha a felhasználó AI-rendszerrel lép kapcsolatba. A szolgáltatói sornál ne elégedj meg a marketingoldallal, mert egyes ingyenes csomagok a felhasználói promptokon is tanítanak, ahogy a Mistral Vibe ingyenes szintje is alapból teszi. Céges adat csak olyan csomagba kerüljön, ahol ez írásban kizárt.

Hogyan auditáld a már működő ügynökeidet egy délután alatt?

Úgy, hogy egy délutánra leülsz a fejlesztőddel vagy az üzemeltetőddel, majd nyolc lépésben végigmentek a leltáron, a kulcsokon, a verziókon, a hálózati kitettségen, a jogosultságokon, a naplókon, a vészféken és a költségkereteken. Egy 10 és 30 fő közötti cégnél ez jellemzően három-négy óra, a talált hibák javítása külön feladat.

• Készíts leltárt. Gyűjtsd össze az összes ügynököt és AI-t használó munkafolyamatot, beleértve az automatizációs platformokon futó folyamatokat, az egyedi fejlesztéseket és a CRM-be vagy a helpdeskbe épített AI-asszisztenseket. Minden tételnél rögzítsd, ki hozta létre, mire használják és ki a gazdája. A gazdátlan ügynök az első jelölt a leállításra.
• Térképezd fel a kulcsokat. Nézd végig a modellszolgáltatók felületén az összes API-kulcsot, azt is, mikor használták utoljára és melyik ügynökhöz tartoznak. A 30 napja nem használt vagy azonosíthatatlan kulcsokat vond vissza.
• Ellenőrizd a verziókat. Írd fel az n8n, az AI-átjáró és az MCP-szerverek pontos verzióját, majd vesd össze a gyártók biztonsági közleményeivel. A LiteLLM-nél az 1.84.0 a határ, az n8n-nél a nordflux.de ajánlása szerint legalább az 1.122.0-s, de inkább a legfrissebb verzió szükséges.
• Nézd meg a hálózati kitettséget. Próbáld megnyitni az n8n szerkesztőjét, az AI-átjáró adminfelületét és az MCP-szervereket a céges hálózaton kívülről, például mobilnetes telefonról. Ha bejelentkezési oldal vagy bármilyen válasz jön, a felület nyilvános, tehát el kell dönteni, hogy ennek így kell-e maradnia.
• Vesd össze a jogosultságokat a mátrixszal. Minden ügynöknél nézd meg, milyen fiókkal fut és milyen eszközök vannak bekapcsolva, ha pedig még nincs jogosultsági mátrixod, most készítsd el a tényleges állapot alapján.
• Tegyél próbát a naplókkal. Válassz ki egy véletlenszerű futást az elmúlt hétből és próbáld meg rekonstruálni, mi volt a bemenet, milyen eszközt hívott az ügynök, mi lett az eredmény és ki hagyta jóvá. Ha ez tíz percnél tovább tart, a naplózás hiányos.
• Próbáld ki a vészféket. Állítsd le az egyik ügynököt a leírt eljárás szerint és mérd az időt a döntéstől addig, amíg minden kulcsa érvénytelen lesz és minden futó végrehajtása leáll. Tizenöt perc fölött egyszerűsíteni kell az eljáráson.
• Állítsd be a költségkereteket, majd zárd le jegyzőkönyvvel. Minden modellszolgáltatónál legyen havi keret és riasztás. A délután eredményét egy rövid jegyzőkönyvben rögzítsd a talált hibákkal, a felelősökkel, a határidőkkel és a következő audit dátumával.

Tipp: a második audit már feleannyi ideig tart, ha a leltárt, a kulcslistát és a jogosultsági mátrixot egy közös, verziózott dokumentumban vezeted. Egy 5 és 50 fő közötti cégnek negyedévente egy ilyen délután bőven elég.

Mennyibe kerül a biztonság és mikor nem éri meg ügynököt építeni?

Saját becslésünk szerint egy jól körülhatárolt ügynöknél a biztonsági elemek a bevezetési munka nagyjából 30%-át teszik ki, utána havonta néhány óra karbantartást igényelnek. Nem éri meg ügynököt építeni, ha a feladat egyszerű szabályokkal is megoldható, ha ritkán fordul elő, vagy ha senki nem vállalja az ügynök gazdájának szerepét.

Vegyünk egy képzeletbeli 9 fős soproni ingatlanirodát, amely egy n8n-ben futó ügynököt tervez az érdeklődő levelek előminősítésére és a választervezetek elkészítésére. Tegyük fel, hogy a funkcionális fejlesztés 40 óra és egy külsős fejlesztő óradíja 15 000 Ft, ami összesen 600 000 Ft alapköltséget jelent. A biztonsági elemek becsült többletideje így alakul:

A táblázat oldalra húzható ↔

Ez 12 × 15 000 = 180 000 Ft egyszeri többletköltség, az alapfejlesztés 30%-a. A havi karbantartás (frissítések, a naplók szúrópróbás átnézése, a kulcsok ellenőrzése) becslésünk szerint 2 óra, vagyis havi 30 000 Ft. A második és a harmadik ügynöknél a többletköltség érezhetően kisebb, mert a naplózási, riasztási és vészfék-infrastruktúrát már nem kell újra felépíteni.

A mérleg másik oldalán ott van a korábbi kulcslopásos példa 1,6 millió forintja, az incidenskezelés belső munkaideje és a GDPR szerinti bírság, amelynek felső határa 10 millió euró vagy az előző évi világpiaci forgalom 2%-a, a súlyosabb jogsértéseknél 20 millió euró vagy 4%. A legdrágább tétel mégis gyakran az elvesztett bizalom, mert az ügyfél, akinek az adatait rossz címre küldte a géped, nem a bírság összegére fog emlékezni.

Nem éri meg ügynököt építeni, ha a folyamat egyértelmű szabályokkal leírható, mert egy hagyományos, szabályalapú munkafolyamat olcsóbb és kiszámíthatóbb. Akkor sem, ha a feladat havonta csak néhányszor fordul elő, ha a lényege pénzmozgás vagy törlés, amelyet nem tudsz jóváhagyáshoz kötni, vagy ha nincs, aki gazdája legyen az ügynöknek, figyelje a riasztásokat és döntsön, ha baj van. Minden más esetben a biztonság nem az ügynök ára, hanem a feltétele: az az ügynök, amelyet nem mersz élesíteni, semmit nem spórol, a védőháló nélkül élesített pedig csak az első hibáig.

Miben segít a Convergo?

A Convergo abban segít, hogy az AI-ügynökeid kiszámíthatóan és biztonságosan dolgozzanak. Az IT audit és digitális tanácsadás keretében átvilágítjuk a már futó ügynököket, n8n-példányokat, AI-átjárókat és MCP-szervereket, feltérképezzük a kulcsokat és a jogosultságokat, a talált hibákat pedig fontossági sorrendbe rendezett javítási tervbe foglaljuk. A workflow automatizáció során az új ügynököket eleve szűk jogosultsággal, emberi jóváhagyással, külön tárolt naplóval és kipróbált vészfékkel építjük meg. A support, üzemeltetés és tárhely szolgáltatásunkban a havi frissítési ablakot és a biztonsági közlemények figyelését is átvállaljuk, a havi 30 000 Ft-os Support csomag 3 fejlesztői órát tartalmaz. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük a jelenlegi helyzetet.