Az NVIDIA szerint a futtatókörnyezetnél kell meghúzni az AI-ügynökök biztonsági határát

A hosszabb távon működő ügynökök új biztonsági kérdéseket vetnek fel

Az NVIDIA bejegyzése szerint ahogy az AI-ügynökök képességei nőnek, és egyre hosszabb időtávon működnek, fontosabbá válik, hogy a rájuk épülő alkalmazásokba eleve be legyen építve a biztonság és a megbízhatóság. A cikk az NVIDIA OpenShell-lel, ügynökfejlesztőkkel, nyílt forrású projektekkel és ökoszisztéma-partnerekkel végzett munkára hivatkozva írja le az alakuló ügynökstack fő rétegeit.

Az NVIDIA szerint a biztonsági kontrollok elhelyezése azért kulcskérdés, mert a közelmúltbeli jelentésekben OpenAI, Anthropic és a UK AI Security Institute is olyan frontier ügynökökről számolt be, amelyek a szándékolt határaikon túl működtek. A forrás szerint a jelentett viselkedések közé tartozott egy nem várt út kihasználása laboratóriumi környezetből a nyílt internetre, jogosulatlan hozzáférés más vállalatok rendszereihez, valamint nem jóváhagyott cselekvések emberekkel és infrastruktúrával kapcsolatban.

A bejegyzés kiemeli, hogy ezekben az esetekben hosszú horizonton működő ügynökökről volt szó, csökkentett modellvédelmek mellett. Az NVIDIA értelmezése szerint ugyanaz a tervezési probléma jelenik meg: azok a képességek, amelyekkel az ügynökök kreatívan oldanak meg problémákat és összetett célokat követnek, arra is alkalmassá tehetik őket, hogy az eredeti utasítások által nem előre látott utakat találjanak.

Nem elég a prompt és a modellvédelmi réteg

Az NVIDIA szerint az ügynökök védelméhez nem kell újra feltalálni a biztonságot. A klasszikus rendszerszintű elvek, például a legkisebb jogosultság elve, a rétegezett védelem, az izoláció, az explicit engedélyezés és az auditálhatóság továbbra is használhatók. A nehézség abban van, hogy ezek a kontrollok hová kerüljenek az ügynökstackben.

A forrás különbséget tesz viselkedési kontrollok és infrastruktúra-kontrollok között. A promptok, a modellvédelmek és a harness logika befolyásolják, hogy az ügynök várhatóan mit tesz, de az NVIDIA szerint nem húznak kemény határt aköré, hogy mit tud megtenni. A modell és az ügynök műveleteket javasol, a harness irányítja a ciklust, a kontextust, az eszközöket és a munkamenetet.

A végső jogosultság az NVIDIA álláspontja szerint abban a környezetben van, amelyben az ügynök fut. Ez a környezet kezeli az identitást, érvényesíti a szabályzatot, elszigeteli a hibákat, rögzíti a történteket, és ugyanarra az engedélyezési döntésre jut azonos jóváhagyott szabályzat és ellenőrzött állapot mellett. A bejegyzés megfogalmazása szerint a harness azt irányítja, mit próbáljon meg az ügynök, az infrastruktúra pedig azt kontrollálja, mit tehet meg.

OpenShell a biztonságos futtatásnál, Dynamo az inferenciaadat-síkon

Az NVIDIA a cikkben több funkcionális rétegre bontja az AI-ügynökök alakuló stackjét. A disztribúciós vagy termékréteg a telepítést, az alapértelmezéseket és a támogatott felhasználói élményt adja, példaként az NVIDIA NemoClaw szerepel. Az orkhesztrációs, más néven meta-harness réteg különböző harness-eket választ ki és koordinál, erre a Databricks Omnigent a példa.

Az agent harness feladata, hogy a modellből ügynököt hozzon létre: ez kezeli a ciklust, a kontextust, az eszközöket és a munkameneteket. A forrás példái között szerepel a Claude Code, a Codex, a Hermes, a Pi és a DeepSeek Harness. A biztonságos futtatókörnyezet rétege az izolációért, az identitásért, a szabályzatért, a hitelesítő adatokért és az auditért felel, itt az NVIDIA OpenShell a megnevezett technológia. Az inferenciaadat-sík a modellkiszolgálást, a gyorsítótár-elhelyezést, az útválasztást és az ütemezést kezeli, erre az NVIDIA Dynamo a példa.

A forrás hangsúlyozza, hogy ezek funkcionális szerepek. Egy termék több szerepet is egyesíthet, egy telepítés pedig egy szerepet több szolgáltatásra is szétbonthat. A biztonsági határt azok a hatásútvonalak határozzák meg, amelyeket az ügynök nem tud megkerülni.

Az NVIDIA külön kitér arra, hogy a harness réteg inkább spektrum, mint rögzített kategória. A Codex és a Claude Code véleményesebb harness-ként szerepel, míg a Pi és a DeepSeek Harness a harness nagyobb részét programozható alapként teszi elérhetővé. A bejegyzés szerint éppen ez a programozhatóság teszi gyenge hellyé a harness-t egy erős biztonsági garanciához, mert egy módosításra tervezett réteg nem tud megbízhatóan kontrollokat kikényszeríteni a saját módosításaival szemben.

A futtatási határt az ügynök indulásakor kell létrehozni

Az NVIDIA szerint a modellek, harness-ek, futtatókörnyezetek, szabályzatok és inferenciatelepítések egyre inkább egymástól függetlenül választhatók ki. Ez csak akkor működik, ha a futtatókörnyezet garanciái attól függetlenül érvényesek, hogy felette milyen komponensek futnak. Emiatt a biztonsági határt már az ügynök indításakor létre kell hozni.

A leírt modellben az orkhesztrátor arra kéri az OpenShellt, hogy hozzon létre egy futtatókörnyezetet, és érvényesítse a szabályzatokat, valamint az irányítást. A kiválasztott harness ebben a futtatókörnyezetben indul el. A bővítményei, Model Context Protocol, röviden MCP folyamatai, eszközei és más, modell által irányított kódjai ugyanazon a határon belül futnak.

Az alügynökök delegált gyermek futtatókörnyezeteket kapnak, amelyek felső korlátait nem léphetik túl. Az orkhesztrátor pedig a saját szabályzata által irányított futtatókörnyezetben működik. Az NVIDIA szerint ez eltér attól a megközelítéstől, amikor a futtatókörnyezetet egy újabb eszközként kezelik, amelyet a harness már futás közben hívhat meg. A cikk állítása szerint az a kontroll, amelyet az ügynök visszautasíthat, nem hatékony biztonsági kontroll.

Mit jelent ez a fejlesztőknek és az AI-piacnak

A felhasználók és a fejlesztők szempontjából az NVIDIA üzenete az, hogy az AI-ügynökök biztonságát nem lehet kizárólag a modellre, a promptra vagy a harness logikájára bízni. A bejegyzésben szereplő tervezési szabályok szerint a magasabb rétegek műveleteket javasolnak, az alsóbb rétegek döntenek, a szabályzatnak a biztonsági határ alatt kell maradnia, minden hatást ellenőrizni kell, a hozzáférésnek éppen időben adottnak kell lennie, az izoláció pedig a helyreállítást támogatja.

Az NVIDIA négy biztonsági profilt is megnevez: Isolated, Connected, Production és Adversarial. Ezek a forrás szerint fokozatosan szigorúbb kontrollokat alkalmaznak az ügynöknek adott jogosultság és a lehetséges hatás alapján. A biztonsági követelmények ugyanakkor minden kockázati szinten következetesek: az ügynökök nem adhatnak maguknak hozzáférést, minden nagy hatású műveletnek kikényszerítési ponton kell áthaladnia, a rendszereknek biztonságosan kell hibázniuk, a biztonsági állításoknak pedig azokra a pontos útvonalakra kell korlátozódniuk, amelyeket ténylegesen lefednek.

A cikk a piaci szereplőknek azt jelzi, hogy az ügynökstackben önálló, infrastruktúraszintű biztonsági réteg válhat szükségessé. Az NVIDIA OpenShellt ilyen biztonságos futtatási rétegként írja le, míg a Dynamo az inferenciaadat-sík feladatainál jelenik meg. A vállalat emellett a Shared AI Findings Exchange, röviden SAFE javaslat áttekintését is ajánlja, amelyet közösségi keretként ír le az AI-incidensekből és majdnem bekövetkezett eseményekből való tanuláshoz.