Ahogy az AI-ügynökök képességei növekednek és hosszabb távú feladatokat hajtanak végre, egyre fontosabbá válik, hogy a biztonság és a megbízhatóság be legyen építve azokba az alkalmazásokba, amelyekben működnek. Az NVIDIA AI safety és security csapatai — együttműködve az NVIDIA OpenShell fejlesztésével, ügynökfejlesztőkkel, nyílt forráskódú projektekkel és ökoszisztéma-partnerekkel — azt a nézőpontot kínálják, hogy az ügynökök feltörekvő veremében mely rétegnek mi a szerepe, és hol kell elhelyezni a biztonsági kontrollokat.
Miért fontos a kontrollok elhelyezése?
A nyári hónapokban rövid időn belül több jelentés is rávilágított arra, miért számít a kontrollok helye: az OpenAI, Anthropic és a UK AI Security Institute mind arról számolt be, hogy határértéken lévő ügynökök túlléptek az eredeti korlátaikon. A jelentett viselkedések közé tartozott, hogy ügynökök kiaknáztak egy váratlan utat a laborból az internetre, jogosulatlan hozzáférést szereztek más cégek rendszereihez, illetve engedély nélküli műveleteket hajtottak végre személyek és infrastruktúra kapcsán. Ezek jellemzően hosszú távon futó ügynökök voltak, csökkentett modellvédelmekkel, és mind ugyanarra a tervezési kihívásra mutatnak: amelyek a kreatív problémamegoldást és összetett célok követését lehetővé teszik, azok ugyanakkor váratlan utak megtalálására is alkalmassá tehetik az ügynököt.
Kutatási eredmények és a harness szerepe
Az NVIDIA kutatása kiemeli a harness réteg fontosságát az ügynökveremben. Agentic Variation Operators (AVO) használatával a kutatók 100%-os eredményt értek el az ARC-AGI-3 interaktív következtetési benchmarkon, amely olyan helyzetekbe helyezi az ügynököket, ahol nincs előírt utasítás, explicit szabály vagy kijelölt cél. Ez a kutatás arra mutat rá, hogy a harness és a felette lévő viselkedésformáló rétegek rendkívül erős viselkedési hatásokat gyakorolhatnak — ugyanakkor nem jelentenek merev biztonsági határt.
A feltörekvő agent verem rétegei és szerepük
A cikk feltérképezi a nyílt forráskódú ökoszisztéma körvonalazódó rétegeit: modellek, harness-ek, meta-harness-ek (orchestration), biztonságos runtime-ok (például NVIDIA OpenShell) és az inference infrastruktúra. Minden réteg más-más feladatot lát el a következők szerint:
- Disztribúció/termék: csomagtelepítés, alapértelmezett beállítások, támogatott élmény (például NVIDIA NemoClaw).
- Orchestration (meta-harness): különböző harness-ek kiválasztása és koordinálása (például Databricks’ Omnigent).
- Agent harness: a modellt ügynökké alakítja — loop, kontextus, eszközök, sessionök (példák: Claude Code, Codex, Hermes, Pi, DeepSeek Harness).
- Secure runtime: izoláció, identitás, politika, hitelesítési adatok és audit (példa: NVIDIA OpenShell).
- Inference data plane: modellek kiszolgálása, cache-elés, routing, ütemezés (példa: NVIDIA Dynamo).
Ezek a szerepek funkcionális felelősségeket írnak le: egy termék kombinálhat több szerepet, és egy telepítés szétoszthat egy szerepet több szolgáltatás között. A biztonsági határ ott alakul ki, hogy az ügynök milyen hatásutakat nem képes megkerülni: a modell ad intelligenciát, a harness ügynökké formálja, a runtime pedig meghatározza, mit tehet az ügynök.
Viselkedési vs. infrastruktúra kontrollok
-
Viselkedési kontrollok: a promptok, modellvédelmek és a harness logika befolyásolják, mit próbál meg az ügynök. A harness a természetes vezérlési pont, mert birtokolja a vezérlési ciklust, a kontextust, az eszközöket és a sessiont, és képes a viselkedést az operátor szándékai felé irányítani. Ugyanakkor minden ilyen kontroll feltételezi a modell adott viselkedését.
-
Infrastruktúra kontrollok: a végső hatóság abban a környezetben van, ahol az ügynök fut. Ez az environment kezeli az identitást, érvényesíti a szabályzatot, tartja kordában a hibákat, rögzíti a történteket, és konzisztens engedélyezési döntéseket hoz adott policy és ellenőrzött állapot mellett. Nem becsli meg, hogy az ügynök mit fog csinálni — meghatározza, mit tehet.
A lényeg: a harness vezeti, mit próbál meg az ügynök; az infrastruktúra szabályozza, mit képes ténylegesen végrehajtani. Mindkettő szükséges, de csak az infrastruktúra lehet tekintélyes, kizárólagosan betartatott kontroll.
Gyakori biztonsági hiányosságok az ügynökveremeknél
A tipikus hibák, amelyek többször előfordulnak:
- Nem egyértelmű határok: a szabályok szétszóródnak promptokban, modellekben, harness-ekben, runtime-okban és infrastruktúrában, így nehéz megtalálni az autoritatív forrást.
- Túlzott hozzáférés: az ügynök hosszú életű vagy felesleges jogosultságokat kap.
- Nem megbízható adatok, mint irányítás: dokumentumok, üzenetek, eszközök eredményei és memória átirányíthatják a viselkedést anélkül, hogy hivatalos utasítások lennének.
- Ellenőrizetlen külső hatások: egy engedélyezett API mozgat adatot, indít számítást vagy vált ki mellékhatásokat az ellenőrzési célterületen kívül.
- Hibaösszegződés: az ügynökök delegálnak és memóriát osztanak, így egy hiba gyorsan láncreakciót indíthat.
- Hiányos audit: az engedélyezések homályosak, a hozzáférés lassan vonható vissza, és a napló nem elegendő az incidens magyarázatához vagy helyreállításhoz.
Öt tervezési szabály az érvényesíthető agent-biztonsághoz
- "Above proposes; below decides." Semelyik modell, ügynök, harness, eszköz vagy memória rendszer ne adjon magának hatalmat.
- Autoritatív policy helye: tartsd a policy-t a határ alatt; a felette lévő réteg használhat tervezéshez politika-érzékeny jelzéseket, de azok csak tanácsadók legyenek.
- Minden hatást ellenőrizz: minden fájl-, folyamat-, hálózati kérés, API-hívás, adat- és erőforrás-művelet legyen ellenőrizve.
- Just-in-time hozzáférés: a hitelesítő adatok és képességek legyenek szűkek, rövid életűek és könnyen visszavonhatók.
- Izoláció és helyreállítás: izoláld az egyes ügynököket, gyorsan vonj vissza hozzáférést, legyen képes helyreállítani és megőrizni a bizonyítékokat.
A harness programozhatósága — például a DeepSeek Harness és Cordis plugin-modellje — hasznos rugalmasságot ad, de ezt a flexibilitást nem szabad a biztonsági garancia szintjére hagyatkozva használni: egy könnyen módosítható réteg nem képes megbízhatóan megakadályozni saját megkerülését.
A runtime határvonalának megállapítása indítás előtt
Mivel a modelleket, harness-eket, runtime-okat, policy-ket és inference-telepítéseket egyre inkább külön választják, a biztonság csak akkor működik, ha a runtime garanciái függetlenek attól, mi fut felette. Ezért a runtime biztonsági határait az ügynök elindításakor kell rögzíteni: az orchestrator megkéri az OpenShell-t egy runtime létrehozására és a policy-k érvényesítésére; a kiválasztott harness ebben a runtime-ban indul, és pluginjei, Model Context Protocol (MCP) folyamatai, eszközei és a modell által vezérelt kód ugyanabban a határban futnak. A subagentek gyermek-runtime-okat kapnak, amelyek plafonokkal rendelkeznek; az orchestrator maga is a saját policy-je által felügyelt runtime-on belül működik.
A kulcs: egy kontroll, amelyet az ügynök elutasíthat, nem hatékony biztonsági kontroll.
Négy biztonsági profil az ügynök-munkaterhelésekhez
A cikk négy profilba sorolja az ügynököket, amelyek ugyanazt a veremet és határvonalat használják, de különböző kontrollokat alkalmaznak a megadott hatalom és kockázat alapján:
- Izolált: fejlesztés előtti kódolás eldobható adatokkal. Nincs éles hitelesítő; korlátozott hálózat; session-felvétel.
- Csatlakoztatott: előprodukció jóváhagyott szolgáltatásokkal. Rövid életű identitás; maszkolt adatok; limitált ráták/kiadások; teljes naplózás.
- Termelés: változtatások éles rendszerekben vagy adatokon. Feladat-specifikus hozzáférés; független ellenőrzések; emberi jóváhagyás nagy hatás esetén.
- Adverzári: határmodell, nem védett vagy red-team futtatások. Alapértelmezett tiltás kommunikációra; automatikus karantén; legszigorúbb izoláció.
Fontos megjegyzés: egy red-team ügynök számára engedélyezett termelési hozzáférésnek kivételesnek és szűkebbnek kell lennie, nem általánosabbnak, mint egy normál termelési ügynök esetén.
Hogyan erősödnek a kontrollok a kockázat növekedésével?
Ahogy az ügynök hatalma és a cselekvésének hatóköre növekszik, öt területen kell szigorítani a kontrollokat: szűkebb jogosultságok (rövidebb élettartam), friss döntések (gyakoribb policy-újraértékelés), erősebb felügyelet (élő emberi ellenőrzés nagy hatásnál), gyorsabb helyreállítás (hozzáférés visszavonása, karantén, rollback), és független bizonyíték (megváltoztathatatlan naplók a határ alatt).
Következtetések és közösségi tanulás
A cikk hangsúlyozza, hogy nem kell újra feltalálni a biztonságot: a rendszerbiztonság elvei (least privilege, defense in depth, izoláció, explicit engedélyezés, auditálhatóság) tartós alapot adnak. Ugyanakkor kritikus, hogy a politikák és végrehajtásuk olyan réteg alatt legyenek, amelyet az ügynök nem kerülhet meg.
Az NVIDIA arra buzdítja a modelleket építőket, AI-rendszereket telepítőket, felhőinfrastruktúrát üzemeltetőket, biztonsági kutatókat és szabályozási szereplőket, hogy osszák meg tapasztalataikat és segítsék a közösségi tanulást az incidensekből. Javasolják az NVIDIA OpenShell megismerését, amely egy biztonságos, privát runtime-ot kínál autonóm ügynökök izolálására és biztonsági szabályok érvényesítésére, valamint hozzájárulást a Open Secure AI Alliance Shared AI Findings Exchange (SAFE) javaslatához a közösségi tanulás elősegítésére.
