Az elmúlt hat hónapban a NVIDIA AI Red Team többféle AI‑ügynököt vizsgált, a egyszerű interaktív kódolóeszközöktől az „mindig bekapcsolt” autonóm digitális asszisztensekig. Bár az ilyen ügynökök — „digitális munkatársak” — nagy produktivitás‑nyereséget ígérnek (például hibajelentés átnézése, javítás implementálása és tesztelése, patch feltolása és ember értesítése), az LLM-ek és élő eszközök/céges adatok összekapcsolása jelentős kockázatot is hordoz: a segítő asszisztensből privilegizált szoftver válhat, amelynek támfelülete nem jól ismert.
Gyakori hibamódok
A Red Team értékeléseiben ismétlődő hibák jelentkeztek, függetlenül a használt keretrendszertől vagy harness‑tól. A leggyakoribbak a következők:
- Hozzáférés‑szabályozás hiánya az ügynökhöz.
- Olyan ügynökeszközök, amelyek tetszőleges kódvégrehajtást tesznek lehetővé.
- Hálózati kimeneti (egress) kontrollok hiánya.
- Titkok (tokenek, kulcsok) egyszerű szövegként való kitéve az ügynök számára.
A cikk példái többségében chat‑csatlakoztatott ügynökökön alapulnak, de a minták más típusú ügynökökre is érvényesek.
1) Implementáljon ügynök hozzáférés‑szabályozást
A leggyakoribb hibamód, hogy egy ügynök nem korlátozza a hozzáférést. A csapat több olyan ügynököt talált, amelyek felhasználói hitelesítőket tároltak és az intraneten belül bármely jogosult felhasználó számára elérhetők voltak. Ez lehetővé tette a jogosultságok visszaélését, illetve a hitelesítő adatok kinyerését és az ügynökön kívüli kontextusban való felhasználását.
Ajánlások:
- Alkalmazzon erős hozzáférés‑szabályozást a védelem első vonalaként.
- Szabályozza, hogy csak kifejezetten engedélyezett felhasználók érhessék el az ügynököt; az ilyen korlátozással rendelkező ügynökök tesztelése lényegesen nehezebb volt.
- Kövesse a legkisebb jogosultság elvét: az ügynök jogosultságai egyezzenek azokkal, amiket a meghívó felhasználó kap.
2) Korlátozza a kódvégrehajtást
Sok harness Bash‑t vagy általános parancsvégrehajtó eszközt tesz elérhetővé, mert ezek általánosak és sok rutinfeladatot lefednek. Ha a modell kimenete vezérli a parancsvégrehajtást, egy támadó — közvetlen bemenet vagy prompt‑injekció útján — parancsokat futtathat a környezetben. Ez adatkivitelhez vagy tartós végrehajtáshoz (például reverse shell) vezethet.
A gyakori kockázatcsökkentések (LLM‑as‑a‑judge, allowlistek vagy a modell implicit megbíztatása) korlátozott védelmet nyújtanak. Számos parancs, amelyet fejlesztési munkafolyamatok igényelnek (például pytest vagy npm install), könnyen átlépi ezeket a védvonalakat, ha a bemenetet támadó manipulálja.
Még parancssori eszköz nélkül is a fájlok olvasása/írása váratlan utakat nyithat a kódvégrehajtáshoz és jogosultságnöveléshez: például a ~/.bashrc, ~/.zshrc, ~/.gitconfig, hooks.json vagy skills fájlok módosítása később kódfuttatáshoz vezethet, ha azokat más folyamatok betöltik.
Ajánlások:
- Tekintse a tetszőleges kódvégrehajtást a legsúlyosabb kockázatnak egy hozzáférhető ügynöknél.
- Kerülje a parancssori eszközök kitettségét ahol csak lehet.
- Tiltsa a fájlírást a nem végrehajtható munkaterületen kívül az operációs rendszer szintjén.
- Ha parancssori végrehajtás szükséges, használjon szigorú, legkisebb jogosultságú allowlistet és izolált végrehajtó környezetet erős hálózati egress‑szabályozással.
- Fájlnév, dokumentumcím és egyéb külső adat feldolgozásakor sanitizálja és normalizálja az inputot, hogy elkerülje a path traversal vagy parancsinjekciós vektorokat.
3) Hálózati kimenet (egress) alapból tiltása
Kimenő hálózati kapcsolatok lehetővé teszik az adatkivitel és a fordított kapcsolatok (reverse shell, SOCKS) létrehozását. Amikor egress‑szabályokat érvényesítettek és a legkisebb jogosultság szerint engedélyeztek csak végpontokat, az interakcióink lassabbá és kevésbé megbízhatóvá váltak: az ügynök állapotának megőrzése, kimeneti szűrők megkerülése, és a munkamenetek újraindítása mind jelentős műveleti terhet jelentett.
Ajánlások:
- Alkalmazzon default‑deny hálózati kimeneti politikát, és csak a feladathoz szükséges legkisebb halmazú végpontokat engedélyezze.
- Érvényesítse ezeket a korlátozásokat minden hálózati határon, amit az ügynök érint, környezeti kontrollokkal, amelyekhez az ügynök nem fér hozzá.
4) Tartsa távol a titkokat az ügynöktől
Az ügynökök gyakran igényelnek titkokat (platform tokenek, API kulcsok, VCS tokenek, OAuth refresh tokenek). A szokásos tanács, hogy a titkokat környezeti változóként memóriában tartva ne írjuk lemezre, működik, ha csak az ön kódja fut a konténerben. Egy ügynök azonban, amely képes parancsot futtatni, lefuttathatja az env, printenv vagy /proc/self/environ parancsokat, és közvetlenül kiolvashatja ezeket.
A csapat több helyen is találkozott tokenekkel git repositorykban, .env fájlokban, bash történetben, .netrc fájlokban, OAuth 2.0 refresh tokenekben és környezeti változókban. Még ha a hálózati egress meg is akadályozta a közvetlen kimászást, az ügynök a chat‑felületen keresztül is képes volt titkokat felszínre hozni (a „frog‑boiling” vagy crescendo technikával), mivel a titkok az ügynök futtatási környezetében voltak elérhetők.
Ajánlások:
- Soha ne tegyen tartós titkokat elérhetővé az ügynök számára.
- Tárolja a titkokat dedikált titokkezelőben.
- Hozza elő a titkokat csak igény szerint, és csak azon folyamatok memóriájába, amelyek ténylegesen használják őket.
- Tartsa a titkokat távol az ügynök kontextusablakától és végrehajtási környezetétől.
- Ha feladathoz hitelesítő kell, használjon rövid élettartamú, szigorúan körülhatárolt tokent, és vonja vissza azt a feladat befejeztével.
Determinisztikus kontrollok előnyben — mi üt át a prompt‑védvonalakon
A legtöbb prompt‑alapú vagy LLM‑as‑a‑judge jellegű védelem probabilisztikus és gyakran kijátszható. Három technika rendre legyőzi ezeket:
- Social engineering az ügynöknél: ha a kérést valid, belső vagy „debugging” kontextusként tálalja a támadó, az ügynök gyakran végrehajtja a kéretlen műveletet, a csapat egy esetben reverse shell létrehozását is dokumentálta.
- „Frog‑boiling” (crescendo): többlépcsős, fokozatos rávezetés arra, hogy az ügynök végül titkokat vagy egyéb jogosultságokat adjon ki.
- Misdirection a legitim munkafolyamatok használatával, például egy csomag telepítésének kérése (pip install git+https://…), ahol a megtévesztő, weaponizált csomag telepítése kódvégrehajtást eredményez.
Ezek a módszerek rendszeresen aláássák a prompt‑szintű kontrollokat.
Javasolt architekturális kontrollok (rövid prioritási sorrend)
- Hozzáférés‑kontroll az ügynökhöz: csak autentikált, kifejezetten engedélyezett felhasználók férjenek hozzá.
- Futtassa a tetszőleges parancsvégrehajtást csak sandboxolt környezetben (például Docker, NVIDIA OpenShell vagy virtuális gép), megfelelő keményítéssel az escape ellen. A környezet ne legyen képes magát konfigurálni olyan fájlok írásával/modosításával, amelyek később betöltődnek.
- Default‑deny hálózati egress minden érintett határon, legkisebb jogosultságú allowlisttel a szükséges hálózati erőforrásokra.
- Ne tegye elérhetővé a titkokat nyugalmi állapotban vagy a végrehajtási környezetben; használjon titokkezelőt és rövid életű, körülhatárolt tokeneket, esetleg token‑broker megoldást.
- Csomagtelepítést engedélyezze csak ellenőrzött csomagtárolókból; alapértelmezésben tiltsa a tetszőleges URL/VCS telepítést.
- Legkisebb jogosultságú eszközök, MCP‑k, skills: csak a feladathoz szükséges komponensek legyenek elérhetők, különös tekintettel azokra, amelyek futtatnak, írnak vagy hálózathoz férnek.
- Legkisebb jogosultságú perzisztens tárolás: kerülje a volume mountokat, ahol nem lehet, szűkítse őket és soha ne mountoljon írható kötetet végrehajtási útvonalra.
- Használjon friss, frontier modelleket különösen LLM‑as‑a‑judge mintázatoknál; ezek kevésbé hajlamosak adverszári manipulációra, de nem hibabiztosak.
Következtetés
A NVIDIA AI Red Team tapasztalata azt mutatja, hogy az ügynökök védelméhez determinisztikus, architekturális kontrollokra van szükség. Teljesen autonóm rendszerek vállalati hitelesítőkkel jelentős kockázatot képviselnek és alaposan ki kell őket keményíteni: erős hozzáférés‑kontroll, sandboxok legkisebb jogosultsággal, default‑deny egress és titkok kizárása az ügynök hatóköréből. Bár a frontier modellek megnehezítik a manipulációt, elegendő idő és szaktudás mellett gyakorlatilag bármelyik LLM kijátszható.
A további útmutatásért a cikk hivatkozik a „How to Govern Autonomous Agents in Enterprise AI Factories” technikai blogra és a Secure Agent Workspace Reference Design‑ra, valamint említi a NVIDIA előadását a Black Hat USA rendezvényen: "Cost‑Effective, Private, Frontier‑Grade: AI Agent Exploitation with a Fine‑Tuned OSS Model". További bejegyzésekért olvassa a NVIDIA AI Red Team egyéb posztjait.
