Prompt helyett hozzáférés: mit adunk át az AI agenteknek?
Az elmúlt két évben megszoktuk, hogy az AI eszközöket promptoljuk. Beírunk egy kérést, kapunk rá valamilyen választ, a lényeg pedig az, hogy a felelősség végig nálunk marad. Mi döntjük el, hogy felhasználjuk-e az eredményt, és mi ellenőrizzük, hogy valóban helyes-e a visszakapott munka.
Az agentek viszont már nem így működnek. Elolvassák a leveleinket, böngésznek, parancsokat futtatnak, fájlokat írnak, üzenetet küldenek a nevünkben, és ütemezve, külön kérés nélkül is elindulnak.
Ez nem fokozatbeli különbség. Egy chatbotnál az a kérdés, hogy mit írunk neki. Egy agentnél az, hogy mihez adunk hozzáférést, és mi az, ami megállítja, ha félreérti a feladatot.
Mit adunk át valójában?
Az ilyen agentek legismertebb példája az OpenClaw (korábban Clawdbot, majd Moltbot), egy nyílt forráskódú, lokálisan vagy egy saját szerveren futtatható agent, amely a 2025 novemberi megjelenése után hetek alatt a GitHub egyik leggyorsabban növekvő projektjévé vált. De ugyanebbe a kategóriába tartoznak a vállalati eszközök is: a Microsoft 365 Copilot, a fejlesztői agentek vagy az agentikus böngészők.
Amit ilyenkor kiadunk a kezünkből, az nem ugyanaz, mint egy szokásos szoftverjogosultság. Egy szövegszerkesztő determinisztikus, vagyis ugyanarra a bemenetre mindig ugyanazt csinálja. Egy agent nem az. Ugyanazt a kérést kétszer kiadva más-más lépéssorozatot választhat, és ezeknek a lépéseknek a nagy részét nem látjuk.
Ehhez jön az a technikai sajátosság, ami miatt mindez biztonsági kérdés, nem csupán minőségbeli. A klasszikus szoftverekben az adat és a kód elkülönül egymástól. Egy nyelvi modellre épülő agentnél viszont a fejlesztői utasítás, a felhasználó kérése és a feldolgozott tartalom ugyanabban a szövegfolyamban érkezik meg, és a modellnek nincs megbízható eszköze arra, hogy eldöntse, mi az, amit végre kell hajtania, és mi az, amit csak el kell olvasnia.
Erre a hiányzó határvonalra épül a prompt injection. A támadó szándékosan úgy fogalmaz meg egy utasítást, és olyan tartalomba helyezi el, amit az agent később elolvas, hogy a modell a saját feladatának higgye. Vállalati környezetben a veszélyesebb változat az indirekt prompt injection, ahol a felhasználó semmi rosszat nem tesz, csak megnyit egy weboldalt vagy összefoglaltat egy levelet, a káros utasítás pedig az adatokkal együtt érkezik.
Érzékelhető, hogy miért nincs erre megbízható technikai megoldás. Nem azért, mert még nem találták ki, hanem mert a szűrésnek olyan különbséget kellene felismernie, ami magában a szövegben nincs benne. Ugyanaz a mondat lehet ártalmatlan idézet és végrehajtandó parancs is, attól függően, hogy honnan érkezett. Ezt viszont a modell nem látja át.
Mindez nem azt jelenti, hogy ezek az eszközök használhatatlanok. A felderítést, a kutatást, az első piszkozatok elkészítését és az ismétlődő adminisztratív munkát valóban gyorsítják, és a legtöbb szervezetben már ma is ott vannak, sokszor jóváhagyás nélkül. A kérdés tehát nem az, hogy beengedjük-e őket, hanem az, hogy tisztában vagyunk-e vele, mihez adtunk nekik hozzáférést.
Amikor az agent lett a támadási felület
1. EchoLeak
2025 júniusában az Aim Labs kutatói súlyos sérülékenységet hoztak nyilvánosságra a Microsoft 365 Copilot kapcsán. Az EchoLeak néven ismertté vált hibát (CVE-2025-32711) széles körben az első dokumentált, kattintás nélküli támadásként tartják számon egy AI agent ellen.
A támadáshoz elég volt egyetlen, ártalmatlannak tűnő e-mailt küldeni a szervezet bármelyik munkatársának. A címzettnek nem kellett megnyitnia a levelet, nem kellett kattintania, nem kellett tennie semmit. Amikor a Copilot legközelebb a beérkező üzenetekből is kontextust gyűjtött egy válaszhoz, beolvasta a levélbe rejtett utasítást, és végre is hajtotta: OneDrive-fájlokat, SharePoint-tartalmat és Teams-üzeneteket továbbított egy külső címre. A Microsoft szerveroldalon javította a hibát, és a közlése szerint éles kihasználásra utaló jelet nem talált.
A kutatók a jelenséget LLM Scope Violationnek nevezték el: a kívülről érkező, nem megbízható bemenet ráveszi a modellt, hogy olyan belső adatokhoz nyúljon, amelyekhez a támadónak semmilyen jogosultsága nincs. A Copilot közben pontosan azt tette, amire tervezték.
2. Az AI-böngészők: elég egy összefoglalót kérni
2025 augusztusában a Brave biztonsági csapata publikálta, mi történik, ha egy AI alapú böngészőt megkérünk arra, hogy foglalja össze az éppen megnyitott oldalt. A Perplexity Comet úgy adta át az oldal tartalmát a modellnek, hogy közben nem különítette el a felhasználó utasítását az oldalról származó, nem megbízható szövegtől. A demójukban egy Reddit hozzászólásba rejtett utasítás elég volt ahhoz, hogy a böngésző a felhasználó bejelentkezett munkamenetével kiolvassa az e-mail-címét és egy egyszer használatos jelszavát, majd kiküldje őket. Az utasítást fehér háttéren fehér betűszínnel, illetve HTML kommentben rejtették el.
Ősszel ugyanez a csapat folytatta a kutatást, ekkor már képekbe rejtett utasításokkal: például halványkék szöveggel sárga háttéren, amit ember nem vesz észre, a szövegfelismerés viszont igen. Elég volt egy ilyen oldalról képernyőképet készíteni és rákérdezni a tartalmára: a tesztelt böngészők megnyitották a felhasználó levelezését, kiolvasták a legutóbbi e-mail tárgyát, és beleírták egy kérésbe, amit a kutatók által kontrollált címre küldtek.
A Brave saját összegzése szerint itt nem egyetlen termék hibázott, hanem az agentikus böngészők egész kategóriáját érinti a probléma. A same-origin policy, vagyis az az évtizedes alapfeltevés, hogy az egyik oldal nem cselekedhet a másik nevében, gyakorlatilag hatástalanná válik, mert az asszisztens a felhasználó hitelesített jogosultságaival fut.
3. OpenClaw: minden kulcs egy fájlban
Az OpenClaw a konfigurációját, a hosszú távú memóriáját és a beszélgetéseit helyi Markdown és JSON fájlokban tárolja. Ezekben ott vannak az API-kulcsok, a jelszavak és az OAuth tokenek, olvasható formában. Ez önmagában még kezelhető lenne, ha a fájlokhoz csak a gép tulajdonosa férne hozzá.
Csakhogy ez nem így alakult. A SecurityScorecard 2026. február 9-én nagyjából 40 000 olyan példányt talált, amelynek a vezérlőfelülete kívülről elérhető volt az internetről, közel 29 000 egyedi IP-címen. A megfigyelt telepítések 63%-a sérülékeny volt, mintegy 12 800 esetben távoli kódfuttatásra is. Az egész szimplán azért történhetett meg, mert az alapértelmezett konfiguráció minden hálózati interfészen figyelt, nem csak a loopback-en.
4. A skillek, egy kritikus ellátási lánc
Az agentek képességeit úgynevezett skillekkel lehet bővíteni, amelyeket bárki megoszthat. Ezek jellemzően nem lefordított kódot tartalmaznak, hanem utasításokat. A Snyk 2026 februárjában a legnagyobb ilyen piactér 3 984 skilljét vizsgálta meg. Ezek 7,1%-ában találtak olyan skillt, amely olvasható formában vezet át API-kulcsokat és jelszavakat a modell kontextusán és a naplófájlokon keresztül, 76 skillben pedig ténylegesen rosszindulatú kódot igazoltak. Ugyanezeket a skilleket a fejlesztői agentek is használják, tehát nem egyetlen termék problémájáról van szó.
Egy csomagfüggőséget ma már kevesen húznak be ellenőrzés nélkül éles rendszerbe. Egy skillt viszont már igen.
Hogyan csökkenthető a kockázat?
1. Izoláljuk, és számoljunk azzal, hogy előbb-utóbb bedől. A Microsoft Defender biztonsági kutatócsapata 2026. február 19-én közzétett útmutatójában úgy fogalmazott, hogy az OpenClaw-t nem megbízható kódfuttatásként kell kezelni, amely ráadásul tartós hitelesítő adatokkal rendelkezik, és emiatt nem való személyi vagy vállalati munkaállomásra. Ha egy szervezet mégis kipróbálná, akkor dedikált virtuális gépen, célra létrehozott, nem privilegizált hitelesítő adatokkal és nem érzékeny adatokon tegye. Az érvelésük lényege, hogy ha az agent külső tartalmat olvas és kiegészítőket telepít, akkor előbb-utóbb biztosan feldolgoz rosszindulatú bemenetet is. Ezért a kontrolloknak nem a megelőzésre, hanem a kár korlátozására kell irányulniuk: monitorozásra és egy előre kidolgozott újraépítési tervre. Az ajánlás konkrét terméknek szól, az elv viszont
2. Az agent is identitás. Legyen saját, nevesített fiókja, szűkre szabott jogosultságokkal, visszavonhatóan és auditálhatóan. Ahol elég az olvasási jog, ott ne kapjon íráshoz.
3. Bontsuk szét a három feltételt. Simon Willison szerint akkor lesz komoly baj, ha egy AI-rendszer egyszerre fér hozzá bizalmas adatokhoz, dolgoz fel nem megbízható tartalmat, és rendelkezik külső kommunikációs csatornával. Mivel a bemenet szűrése nem működik megbízhatóan, a védekezés az, hogy a három feltétel közül elveszünk egyet. A gyakorlatban ez általában két külön agentet és két külön jogosultsági kört jelent, nem pedig egyetlen, mindenhez értő digitális titkárt.
4. Naplózzunk, és tegyünk be jóváhagyási pontokat. Az agent eszközhívásait ugyanúgy naplózni kell, mint a privilegizált parancsokat: mit hívott meg, milyen paraméterrel, milyen eredménnyel.
Visszafordíthatatlan műveleteknél, tehát törlésnél, kifizetésnél, jogosultságkiosztásnál vagy éles telepítésnél pedig legyen technikai kényszer az emberi jóváhagyás.
5. A kiegészítők is függőségek. A skillek, pluginek és MCP-szerverek az ellátási lánc ugyanolyan elemei, mint bármelyik csomagfüggőség, azzal a különbséggel, hogy jellemzően hitelesítő adatokhoz és a fájlrendszerhez is hozzáférnek. Kell hozzájuk engedélyezési lista, verziórögzítés, és olyan szabály, amely megtiltja, hogy az agent felügyelet nélkül telepítsen magának új képességeket.
A jogosultságoknál dől el
Az AI agentek nem rosszak, és nem is haszontalanok. Csak nem abba a kategóriába tartoznak, amelybe a legtöbb szervezet besorolja őket. Nem egy újabb SaaS-ről van szó, amit engedélyeztetni kell, hanem sokkal inkább egy új munkatársról, aki gyors, fáradhatatlan, és mindent elhisz, amit leírva talál.
Az első két példában ezért nem is kellett senkinek feltörnie semmit: a rendszer pontosan azt tette, amire tervezték. A másik kettőben a régi hibák tértek vissza, rossz alapbeállítás, ellenőrizetlen függőség..., csak most olyan szoftverben, amely a mi jogosultságainkkal cselekszik. A lényegi döntés így egyik esetben sem az eszköz kiválasztásánál születik meg, hanem ott, hogy mihez fér hozzá, kinek a nevében cselekszik, és mi az, ami megállítja, ha ő magától nem állna meg.