IVSZ AI Kompetencia Központ hírek

Kódoló agent a fő ágban: három alapmű, amelyet minden fejlesztőcégnek ismernie kell

Written by Cseresnyés Dóra | 2026. okt. 19. 12:57:38

Amikor a rendszer már cselekszik

Egy kódoló agent egy hibajegy alapján önállóan átírja a kódot, és a sikeres tesztek után beolvasztja a változtatást a fő ágba, ahonnan az automatikusan élesbe kerül. Másnap kiderül, hogy a módosítás egy ritkán használt fizetési folyamatot elrontott az ügyfélnél, és amikor a felelőst keresik, senki sem tudja megmondani, ki engedte el az agentet ekkora mozgástérrel.

A legtöbb szervezet AI szabályzata olyan modellekre készült, amelyek válaszolnak, és a válasz sorsáról egy ember dönt. Az agent ezzel szemben tervez, eszközöket hív, memóriát tart fenn, és delegált jogosultsággal jár el más rendszerekben. A kockázat így a modell kimenetéről átkerül a jogosultságokra és arra a hatásra, amely a lánc végén keletkezik.

Az alábbiakban három alapművet mutatunk be, amelyeket minden agentet bevezető vagy már használó szervezetnek érdemes ismernie. Mindegyik más oldalról közelít, együtt mégis teljes képet adnak arról, mire kell figyelni a governance és a biztonság területén egyaránt.

Szingapúr: kinek mit kell eldöntenie

Szingapúr infokommunikációs hatósága, az IMDA, 2026. január 22-én a davosi Világgazdasági Fórumon mutatta be a Model AI Governance Framework for Agentic AI keretrendszert, amely a világon az első kifejezetten agentekre szabott governance keretrendszer. A 2026 májusában kiadott 1.5 verziót júniusban már frissítették. Önkéntes jó gyakorlatról van szó, haszna mégis jóval túlnyúlik Szingapúron, mert a saját fejlesztésű és a külső szállítótól vásárolt agentekre egyaránt alkalmazható.

A keretrendszer négy dimenzióra épül. Először fel kell mérni és le kell határolni a kockázatokat, vagyis előre rögzíteni kell, mit tehet meg az agent és mihez fér hozzá. Ezután érdemi emberi felelősséget kell kijelölni az életciklus minden szereplőjére a fejlesztőktől a végfelhasználókig, olyan felügyelettel, amely képes megállítani vagy felülbírálni az agent lépéseit. A harmadik dimenzió a technikai kontrolloké és folyamatoké a fejlesztéstől a folyamatos monitorozásig, a negyedik pedig a végfelhasználók tájékoztatása és felkészítése.

Különösen hasznos, hogy az IMDA az automatizálási torzítást is kockázatként nevezi meg. Ez az a helyzet, amikor egy korábban megbízhatóan működő rendszerben a felhasználók túlzottan megbíznak, és éppen ezért már nem néznek rá elég alaposan.

OWASP: hol sebezhető az agent

A biztonsági oldalon az OWASP GenAI Security Project munkája adja a közös nyelvet. A Top 10 for Agentic Applications 2026 listát 2025. december 9-én tették közzé több mint száz szakértő közreműködésével, és tíz olyan kockázati kategóriát rögzít, amely kifejezetten az önállóan tervező és cselekvő rendszerekre jellemző. A lista élén az agent céljának eltérítése áll, amikor egy e-mailbe vagy dokumentumba rejtett utasítás átírja azt, amit az agent el akar érni. Ugyanilyen tanulságos az agentic ellátási lánc kockázata, hiszen az agent külső eszközökre és más agentekre támaszkodik, és ezek bármelyike beviheti a rendszerbe a sérülékenységet.

Fontos összefüggés, hogy ez a lista kiegészíti az OWASP korábbi, LLM alkalmazásokra vonatkozó Top 10 listáját. A legtöbb agent maga is LLM alkalmazás, így annak kockázatait is örökli a saját újakon felül. A szingapúri keretrendszer technikai kontrollokról szóló dimenziója itt kap gyakorlati tartalmat, mert az OWASP mondja meg, mit kell pontosan ellenőrizni.

Spanyolország: a kettes szabály

A spanyol adatvédelmi hatóság, az AEPD 2026. február 18-án tette közzé az agentic AI-ról szóló útmutatóját, az egyik első olyan európai felügyeleti dokumentumot, amelynek fő tárgya az agentek működése. Az útmutató megkülönbözteti a javaslatot tevő és a végrehajtó agenteket, és minél nagyobb az önállóság, annál erősebb felügyeletet vár el. A hatóság válasza strukturális: a kockázatot governance és tervezés kerétében kell kezelni, utolsó pillanatban végzett ellenőrzésekkel ez nem oldható meg.

Fejlesztőknek a legkézzelfoghatóbb rész a kettes szabály (Rule of 2), amelyet eredetileg böngészőbiztonsági elvként ismertek, és amelyet az AEPD az agentekre fogalmazott át minimális küszöbként. Lényege, hogy három kockázati tényező közül egyszerre legfeljebb kettő lehet jelen. Ha az agent ellenőrizetlen forrásból kap bemenetet, és érzékeny adatokhoz is hozzáfér, akkor emberi felügyelet nélkül nem hajthat végre semmit. Ha pedig önállóan cselekszik, a másik két feltétel közül legfeljebb az egyik teljesülhet. Az a kódoló agent tehát, amely külső forrásból érkező hibajegyek alapján dolgozik és közben a CI/CD titkos kulcsait is látja, emberi jóváhagyás nélkül már nem olvaszthatna be a fő ágba.

Miért governance kérdés ez egy fejlesztőcégnél

Egy fejlesztőcégben könnyű ezeket a kérdéseket a biztonsági csapatra hagyni, hiszen az OWASP lista ismerős terep. A kódoló agent jogosultságai azonban döntések, amelyekhez gazda kell: hozzáférhet-e a CI/CD folyamat titkos kulcsaihoz, és beolvaszthat-e emberi jóváhagyás nélkül a fő ágba. A technikai kontroll csak akkor ad jó választ ezekre, ha előbb valaki eldöntötte, mi a helyes válasz, és vállalja érte a felelősséget. Amikor pedig az ügyfélnél hiba történik, az ügyfél azt fogja kérdezni, ki döntött.

A hagyományos és a generatív AI-ra kidolgozott szabályzatok és etikai elvek nem elegendők egy olyan technológiánál, amely órákon vagy napokon át önállóan végez feladatokat, ezért a passzív felügyelet helyett automatizált technikai kontrollra és rendszerszintű governance-ra van szükség. Egy fejlesztőcégnek ez ismerős nyelv, hiszen a szabályt itt is kódba és folyamatba kell önteni, és ez egybecseng a szingapúri megközelítéssel is: a felelősség kijelölése akkor ér valamit, ha mögötte működő és ellenőrzött kontroll áll.

A legtöbb szervezetben ez a munka már nem a bevezetés előtt kezdődik, mert az agentek dolgoznak, sokszor egy szállítói platform beállításaiként vagy egy csapat saját kísérleteként. Egy beállítás azt mutatja, minek kellene történnie. Az ellenőrzött kontroll azt igazolja, hogy valóban ez történik, akkor is, ha az agent szokatlan bemenetet kap, vagy ha egy külső komponens közben megváltozott. Éppen a jól működő agentnél a legnagyobb a kísértés, hogy a beállításokat elegendőnek tekintsük.

Aki ma utólag pótolja ezt a munkát, egy már éles rendszer kockázatát csökkenti, és ez legalább annyit ér, mint egy gondosan előkészített új bevezetés.