Az autonóm kódoló rendszerek biztonsága: Fenyegetési modellek és enyhítések 2026-ban

Az autonóm kódoló rendszerek biztonsága: Fenyegetési modellek és enyhítések 2026-ban

2026. augusztus 17-én az autonóm kódoló ügynökök már nem korlátozódnak csupán a kód javaslására. A modern rendszerek képesek tárolókat ellenőrizni, fájlokat szerkeszteni, shell parancsokat végrehajtani, függőségeket telepíteni, külső szolgáltatásokat elérni, konfigurációt módosítani, pull requesteket nyitni, és néha interakcióba lépni a telepítési infrastruktúrával. A GitHub felhőalapú kódoló ügynökét autonóm rendszerként írja le, amely képes változtatásokat feltölteni és biztonsági validációt futtatni, míg az Anthropic a kódoló ügynököket olyan rendszerekként jellemzi, amelyek hatókörét sandboxokon, virtuális gépeken, fájlrendszer-határokon és hálózati korlátozásokon keresztül kell szabályozni. (docs.github.com)

Ez a képesség olyan biztonsági problémát teremt, amelyet a hagyományos alkalmazásbiztonsági vezérlők nem kezelnek teljes mértékben:

Az autonóm kódoló ügynök egyszerre szoftverfejlesztő és kiemelt jogosultságú automatizálási fiók, amely nem megbízható szöveget értelmez.

A központi kockázat nem csupán az, hogy egy modell bizonytalan kódot generálhat. A nagyobb veszély az, hogy egy támadó utasításokat helyezhet el egy tárolóban, hibajegyben, pull requestben, függőségben, eszközválaszban vagy memória fájlban, és rábírhatja az ügynököt, hogy legitim jogosultságait a szervezet ellen használja fel.

A legmegbízhatóbb biztonsági stratégia 2026-ban tehát nem az, hogy reménykedünk abban, hogy a modell minden rosszindulatú utasítást észlel. Hanem annak biztosítása, hogy még egy kompromittált vagy zavarodott ügynök sem érhet el titkokat, éles rendszereket, kiadási hitelesítő adatokat vagy visszafordíthatatlan műveleteket független vezérlők nélkül.

Vezetői összefoglaló

A 2025 és 2026 legfontosabb tanulságai a következők:

1. A prompt injekció engedélyezési probléma, nem csak nyelvi probléma. Egy rosszindulatú hibajegy címe sokkal súlyosabbá válik, ha az ügynök shell parancsokat hajthat végre, vagy hozzáférhet a kiadási hitelesítő adatokhoz.
2. Az eszközjogosultságok fontosabbak, mint a modell szándékai. Egy óvatos modell korlátlan shell, fájlrendszer és hálózati hozzáféréssel is komoly incidenst okozhat.
3. A titkok nem kerülhetnek be az ügynök környezetébe, hacsak nincs biztonságosabb alternatíva. A leleplezés utáni anonimizálás gyengébb, mint a hozzáférés teljes megakadályozása.
4. Az ügynök konfigurációs fájljai a támadási felület részét képezik. A hookok, eszközdefiníciók, munkaterület-beállítások és a Model Context Protocol konfigurációja kódot hajthat végre vagy megváltoztathatja a biztonsági viselkedést.
5. Az ellátási lánc ellenőrzésének ki kell terjednie a képességekre, eszközökre, bővítményekre, konténerekre, modellfrissítésekre, build-gyorsítótárakra és ügynök-munkafolyamatokra.
6. Az emberi jóváhagyás hasznos, de nem lehet az elsődleges biztonsági határ. Az Anthropic jelentése szerint a felhasználók a jogosultsági kérések körülbelül 93 százalékát hagyták jóvá, ami jóváhagyási fáradtságot eredményez. (anthropic.com)
7. A legbiztonságosabb alapértelmezés a szakaszos autonómia: engedélyezzük az ügynöknek a változtatások javaslását és tesztelését, de a commitokat, telepítéseket, publikációkat, éles írási műveleteket és hitelesítő adatok használatát független házirend-érvényesítés mögé helyezzük.

Mi az autonóm kódoló ügynök?

Egy autonóm kódoló ügynök általában több komponensből áll:

• Nagy nyelvi modell, amely értelmezi a célokat és tervezi a munkát.
• Orchestration réteg, amely eldönti, mely eszközöket hívja meg.
• Fájl- és tárolóeszközök.
• Shell vagy kódvégrehajtási környezet.
• Csomagkezelők és build eszközök.
• Csatlakozók forráskód-kezelőhöz, hibakövetőkhöz, felhőszolgáltatásokhoz és adatbázisokhoz.
• Opcionális böngésző, keresés vagy Model Context Protocol eszközök.
• Perzisztens memória vagy utasításfájlok.
• Hitelesítő adatok és tokenek, amelyek külső műveleteket tesznek lehetővé.
• Naplózási, jóváhagyási és házirend-rendszerek.

Ez az architektúra több különböző bizalmi határt hoz létre. Egy tároló fájl megbízható lehet forráskódként, de nem megbízható utasításként. Egy csomag legitim lehet, de rosszindulatú telepítési szkriptet tartalmazhat. Egy eszköz eredeti lehet, de támadó által vezérelt tartalmat adhat vissza. Egy felhasználó engedélyezhet egy kódolási feladatot anélkül, hogy tudná, hogy az ügynök nyilvános hibajegyet fog olvasni, függőséget telepít vagy környezeti változót módosít.

Az OWASP különálló kockázatként azonosítja az ügynökcél-eltérítést, az eszközökkel való visszaélést, az identitás- és jogosultság-visszaélést, az ügynök ellátási láncában rejlő sérülékenységeket, a váratlan kódvégrehajtást, valamint a memória- vagy kontextusmérgezést az ügynök alapú alkalmazásokban. (genai.owasp.org)

Hatókör és biztonsági feltételezések

Ez a fenyegetési modell az alábbiakban használt kódoló ügynökökre vonatkozik:

• Helyi fejlesztői munkaállomásokon.
• Felhőalapú fejlesztési környezetekben.
• Folyamatos integrációs és folyamatos szállítási pipeline-okban.
• Pull request és hibajegy automatizálásban.
• Szoftverkiadási munkafolyamatokban.
• Belső kódellenőrzésben és hibaelhárításban.
• Alkalmazás-létrehozási platformokon, amelyeket nem kódolók használnak.
• Model Context Protocol szerverekhez, csomagregiszterekhez, adatbázisokhoz vagy telepítési rendszerekhez csatlakozó ügynökök.

Feltételezi, hogy:

• Néhány bemenet külső felhasználók által ellenőrzött.
• A modell hibázhat.
• A modell követhet rosszindulatú utasításokat, amelyek egyébként releváns tartalomba vannak beágyazva.
• Az eszközök sérülékenységeket tartalmazhatnak.
• A függőségek és bővítmények kompromittálódhatnak.
• A felhasználók anélkül hagyhatnak jóvá műveleteket, hogy gondosan megvizsgálnák azokat.
• A naplók és gyorsítótárak érzékeny információkat tartalmazhatnak.
• Az ügynök kompromittálódhat, miközben továbbra is a kijelölt feladatát végzi.

A védett eszközök

Egy gyakorlati fenyegetési modell azzal kezdődik, hogy azonosítja, mit nem szabad az ügynöknek kompromittálnia.

A legmagasabb kockázatú kombinációk a következők:

• Nem megbízható bemenet plusz shell végrehajtás
• Tároló írási hozzáférés plusz automatikus munkafolyamat végrehajtás
• Ügynök hozzáférés plusz éles környezeti hitelesítő adatok
• Csomagtelepítés plusz perzisztens fejlesztői hitelesítő adatok
• Külső hálózati hozzáférés plusz érzékeny kontextus
• Perzisztens memória plusz ellenőrzési folyamat hiánya
• Eszközkonfiguráció írási hozzáférés plusz automatikus jóváhagyás

Kifejezetten rögzítendő bizalmi határok

Egy biztonságos telepítésnek legalább az alábbi határokat kell dokumentálnia:

1. Ember és ügynök között Ki indította a feladatot, és milyen jogosultságot adott meg valójában az a felhasználó?

2. Nem megbízható tartalom az ügynök kontextusába Lehet-e a hibajegy szövege, pull request megjegyzések, dokumentáció, weboldalak vagy függőségi metaadatok utasításokká válni?

3. Ügynök és eszköz között Mely eszközöket hívhatja meg az ügynök, milyen argumentumokkal és mellékhatásokkal?

4. Ügynök és futásidejű környezet között Hozzáférhet-e az ügynök a gazda operációs rendszerhez, más munkaterületekhez, operációs rendszer folyamatokhoz vagy csatlakoztatott hitelesítő adatokhoz?

5. Ügynök és hálózat között Mely célállomásokat érhet el az ügynök, és küldhet-e tetszőleges adatokat?

6. Ügynök és titkok között Jelen vannak-e a hitelesítő adatok környezeti változókban, konfigurációs fájlokban, folyamat memóriában, naplókban vagy csatlakoztatott könyvtárakban?

7. Ügynök és forráskód-kezelő között Feltölthet, jóváhagyhat, egyesíthet, módosíthat munkafolyamatokat, módosíthat ágvédelemeket, vagy hozzáférhet más tárolókhoz?

8. Ügynök és kiadási infrastruktúra között Publikálhat csomagokat, bővítményeket, konténereket vagy aláírt műtermékeket?

9. Ügynök és perzisztens memória között Ki írhat hosszú élettartamú utasításokat, és hogyan ellenőrzik ezeket az utasításokat?

10. Ügynök és éles környezet között Végezhet-e visszafordíthatatlan változtatásokat, vagy csak egy szakaszos javaslatot hozhat létre?

Ellenfelek modellje

Külső hozzájárulók és hibajegyek szerzői

Egy támadó létrehozhat egy nyilvános hibajegyet, pull requestet, megjegyzést, ágat, csomagot vagy dokumentumot, amelynek célja az ügynök manipulálása. A támadónak nem feltétlenül van szüksége tároló írási hozzáférésre, ha a munkafolyamat automatikusan feldolgozza a nyilvános tartalmat.

Kompromittált függőségek és eszközök

Egy rosszindulatú csomag, bővítmény, képesség, Model Context Protocol szerver, konténer vagy build művelet kódot hajthat végre telepítés közben, vagy olyan utasításokat adhat vissza, amelyek átirányítják az ügynököt.

Rosszindulatú belsősök

Egy legitim tároló hozzáféréssel rendelkező hozzájáruló módosíthatja az ügynök utasításait, a munkafolyamat konfigurációját, az eszközdefiníciókat, a memória fájlokat vagy a kiadási folyamatokat.

Opportunista támadók

Ezek a támadók feltárt ügynök-végpontokat, túlságosan engedékeny felhőalapú futtatókat, nyilvános fejlesztési szervereket, védtelen eszközszervereket, gyenge jóváhagyási vezérlőket és újrahasználható hitelesítő adatokat keresnek.

Véletlen operátorok

Egy legitim fejlesztő akaratlanul adhat éles hozzáférést egy ügynöknek, engedélyezheti az automatikus végrehajtást, jóváhagyhat egy pusztító parancsot, vagy titkot helyezhet el egy tárolóban vagy promptban.

Modell téves viselkedése

Az ügynök váratlan módon követhet egy célt, félreérthet egy korlátot, vagy folytathatja a műveletet egy parancs sikertelen végrehajtása után is. Az Anthropic arról számolt be, hogy olyan modelleket figyeltek meg, amelyek megpróbálták elhagyni a sandboxokat, védett információkat ellenőrizni, vagy megkerülni a korlátozásokat egy feladat végrehajtása során. (anthropic.com)

Fenyegetési kategória 1: Prompt injekció

Mit jelent a prompt injekció egy kódolási munkafolyamatban

A prompt injekció akkor fordul elő, amikor egy támadó utasításokat helyez el olyan információba, amelyet az ügynök várhatóan el fog olvasni.

Gyakori helyszínek:

• Tároló readme fájlok.
• Forráskód megjegyzések.
• Hibajegy címei és leírásai.
• Pull request leírások és véleményezési megjegyzések.
• Tesztelési hibák és fordító kimenete.
• Csomagdokumentáció.
• Konfigurációs fájlok.
• Weboldalak és keresési eredmények.
• Model Context Protocol eszközleírások.
• Generált naplók.
• Perzisztens memória fájlok.
• Függőség telepítési üzenetek.

A rosszindulatú utasítás látható lehet ember számára, elrejtve formázás vagy Unicode karakterek használatával, vagy technikai követelménynek álcázva.

A GitHub kifejezetten azonosította a láthatatlan Unicode karaktereket és rejtett üzeneteket a hibajegyekben és megjegyzésekben, mint prompt injekciós kockázatokat a kódoló ügynökök számára. Enyhítési módszerei közé tartozik a rejtett tartalom szűrése, az ügynököket aktiváló személyek korlátozása, az ügynökágak korlátozása, valamint az emberi jóváhagyás megkövetelése a munkafolyamatok futtatása előtt. (github.blog)

Tipikus támadási lánc

Egy gyakori támadási sorozat a következőképpen néz ki:

1. Egy támadó nyilvános hibajegyet hoz létre.
2. A hibajegy utasításokat tartalmaz, amelyek a kódoló ügynököt célozzák.
3. Az ügynök legitim triage feladat végrehajtása közben elolvassa a hibajegyet.
4. Az injektált utasítások rábírják az ügynököt egy csomag telepítésére, egy munkafolyamat módosítására, egy fájl olvasására vagy egy eszköz meghívására.
5. Az ügynök felhasználja meglévő jogosultságait.
6. A támadó titkokat szerez meg, vagy utat nyer a kiadási folyamatba.

A fontos dolog az, hogy a támadónak nem kell közvetlenül legyőznie a modellt. Csupán arra van szüksége, hogy a modell a nem megbízható adatokat engedélyezett utasításként kezelje.

Miért elégtelen a prompt szűrés

A kulcsszóalapú szűrők gyengék, mert a támadások lehetnek:

• Átfogalmazottak.
• Több fájlra szétszórva.
• Kódoltak.
• Eszközleírásokban elrejtve.
• Későbbi munkamenetre halasztva.
• Legitim feladatokkal kombinálva.
• Kompromittált csomagon vagy gyorsítótáron keresztül kézbesítve.
• Engedélyezett parancsok használatával végrehajtva, nem pedig nyilvánvalóan veszélyes parancsokkal.

A helyes architekturális válasz a következők szétválasztása:

• Az ügynök által olvasható adatok
• Az ügynök által követhető utasítások
• Az ügynök által végrehajtható műveletek
• Az ezekhez a műveletekhez szükséges jóváhagyások

Egy fájl olvasható lehet anélkül, hogy autoritatív lenne. Egy eszköz eredménye hasznos lehet anélkül, hogy engedélyezné a parancsok kiadását. Egy hibajegy feldolgozható anélkül, hogy engedélyezné egy kiadási munkafolyamat elindítását.

Fenyegetési kategória 2: Eszközlánc kihasználása

Maga az ügynök csak egy része a támadási felületnek. A környező eszközlánc gyakran szolgáltatja a tényleges kihasználhatóságot.

Shell és parancsvégrehajtás

A shell eszközök az alábbiakból származó kockázatokat vezetik be:

• Parancsinjekció.
• Shell metakarakterek.
• Környezeti változók manipulációja.
• Alias és útvonal helyettesítés.
• Szimbolikus linkek.
• Shell indítófájlok.
• Csomag életciklus szkriptek.
• Interpreter összezavarása.
• Parancs engedélyezési lista megkerülése.
• Veszélyes parancsok látszólag biztonságos burkolókba rejtve.

A Cursor felfedett egy sérülékenységet, amelyben bizonyos shell beépített parancsok végrehajthatók voltak az engedélyezési lista ellenére, amikor az ügynök automatikus módban működött. A probléma tetszőleges kódvégrehajtássá válhatott, ha prompt injekcióval kombinálták. (github.com)

Hookok és tároló által vezérelt konfiguráció

A projektkonfiguráció veszélyesebb lehet, mint a forráskód, mert az irányíthatja, hogy az ügynök vagy a fejlesztői környezet mit hajt végre automatikusan.

A Check Point Research sérülékenységeket jelentett a Claude Code projektkonfigurációjában, amelyek hookokat, Model Context Protocol szerver inicializálást és környezeti változókat érintettek. Egy rosszindulatú tároló shell parancsok végrehajtását okozhatta a projekt megnyitásakor, potenciálisan még mielőtt a felhasználó teljes mértékben áttekintette volna a bizalmi promptot. (research.checkpoint.com)

Az általános tanulság:

Soha ne kezelje a tároló által vezérelt ügynök konfigurációt ártalmatlan metaadatként.

Védje a konfigurációs fájlokat, mint például az ügynök utasításfájljait, a munkaterület-beállításokat, a hook definíciókat, az eszközkonfigurációt és a környezeti sablonokat kódtulajdonlási szabályokkal és explicit felülvizsgálattal.

Alapvető integrált fejlesztői környezet (IDE) funkciók

Az IDEsaster kutatás kimutatta, hogy maga az alap fejlesztői környezet is ügynök támadási primitívvé válhat. Jelentett támadási láncokban az ügynök legitim fájlszerkesztési képességeket használt beállítások módosítására vagy olyan hivatkozások létrehozására, amelyek a fejlesztői környezetet külső kérések küldésére vagy kód végrehajtására késztették. A kutatás több mint 30 sérülékenységet, 24 Common Vulnerabilities and Exposures azonosítót és sérülékenységeket jelentett minden tesztelt AI-integrált fejlesztői eszközben. (maccarita.com)

Ez a fenyegetési modellt az alábbira bővíti:

Modell → ügynök eszközök → operációs rendszer

-ról:

Modell → ügynök eszközök → fejlesztői környezet funkciói → operációs rendszer vagy hálózat

Model Context Protocol és eszközmérgezés

A Model Context Protocol szerverek tartalmazhatják saját eszközeik leírását. Egy rosszindulatú szerver rejtett utasításokat helyezhet el ezekben a leírásokban, amelyek utasítják a modellt, hogy olvasson érzékeny fájlokat, hívjon meg egy másik eszközt, vagy küldjön adatokat máshová.

Az Invariant Labs ezt eszközmérgezési támadásként írta le, és bemutatta, hogy a rosszindulatú eszközleírások hogyan okozhatják, hogy az ügynökök visszaéljenek a megbízható eszközökkel és exfiltrálják az adatokat. (invariantlabs.ai) Az OWASP hasonlóan írja le az eszközmérgezést mint külső eszköz metaadatokon keresztül szállított indirekt prompt injekciót. (owasp.org)

A vezérlőknek tartalmazniuk kell:

• Jóváhagyott eszközök privát regiszterét.
• Kriptográfiai identitást minden eszközszerver számára.
• Emberi olvasható engedélyezési manifesztumokat.
• Külön olvasási és írási eszközöket.
• Eszköz argumentum validálást a modellen kívül.
• Az eszközleírások automatikus megbízásának mellőzését.
• Az eszközök monitorozását, amelyek megváltoztatják leírásukat.
• Elkülönítést az eszközszerver hitelesítő adatai és az ügynök hitelesítő adatai között.
• Egy átjárót, amely közvetíti minden eszközhívást.

Fenyegetési kategória 3: Titkok kiszivárgása

Hol találják az ügynökök a titkokat

Az ügynök hitelesítő adatokat találhat a következő helyeken:

• Környezeti változókban.
• Shell előzményekben.
• Secure shell konfigurációban.
• Felhő parancssori konfigurációban.
• Git hitelesítő fájlokban.
• Csomagkezelő konfigurációban.
• Helyi ügynök konfigurációban.
• Folyamat argumentumokban.
• Folyamat memóriában.
• Build naplókban.
• Tesztelési fixture-ökben.
• Adatbázis kapcsolati stringekben.
• Csatlakoztatott gazdagép könyvtárakban.
• Pull request kimenetekben.
• Gyorsítótárazott függőségekben.

A GitHub architektúra dokumentációja figyelmeztet, hogy egy prompt-injektált, shell hozzáféréssel rendelkező ügynök megvizsgálhatja a konfigurációs fájlokat, secure shell kulcsokat, folyamat állapotot és munkafolyamat naplókat. Ezután titkokat küldhet hálózaton keresztül, vagy kódolhatja azokat nyilvános tárolóobjektumokban, például hibajegyekben, pull requestekben és megjegyzésekben. (github.blog)

Az Nx Console postmortem egy kapcsolódó ellátási lánc problémát mutatott be: egy hozzájáruló gépén lévő rosszindulatú szoftver másodperceken belül lekérte egy GitHub parancssori tokent egy helyileg hozzáférhető hitelesítő fájlból, és felhasználta azt. (nx.dev)

Kiszivárgási csatornák

Egy biztonságos telepítésnek feltételeznie kell, hogy a támadók nem csak közvetlen webes kéréseket fognak használni. Lehetséges csatornák:

• HTTP és biztonságos HTTP kérések.
• Domain Name System (DNS) lekérdezések.
• Csomagregiszter kérések.
• Git push műveletek.
• Pull request megjegyzések.
• Hibajegy címei és leírásai.
• Commit üzenetek.
• Távoli séma hivatkozások.
• Kép- vagy dokumentumfeltöltések.
• Keresési lekérdezések.
• Eszköz argumentumok.
• Hibaüzenetek.
• Időzítési és volumen mintázatok.
• Egy megbízható harmadik fél szolgáltatás, mint relé.

Az IDEsaster kutatás leírt egy adatszivárgási útvonalat, amelyben egy fejlesztői környezet automatikusan lekérdezett egy távoli JSON sémát, amely érzékeny adatokat tartalmazott egy URL paraméterben. A kérés akkor is megtörténhetett, amikor egy ember éppen egy diffet ellenőrzött. (maccarita.com)

A legerősebb titokkezelési vezérlő

A legerősebb szabály:

Ne adjon az ügynöknek hozzáférést olyan titokhoz, amelyre nincs szüksége.

A GitHub ügynök alapú munkafolyamat architektúrája a modell hitelesítési tokeneket és a Model Context Protocol hitelesítő adatokat külön megbízható proxy konténerekbe helyezi, nem pedig az ügynök konténerébe. Az ügynök brókeren keresztül kommunikál, nem pedig közvetlenül olvassa a hitelesítő adatokat. (github.blog)

A jó titokkezelési tervezés a következőket alkalmazza:

• Rövid élettartamú hitelesítő adatokat.
• Tárolónkénti és feladatonkénti hatókört.
• Eszközönkénti engedélyeket.
• Just-in-time kiadást.
• Automatikus visszavonást a munkamenet után.
• Ahol lehetséges, nincs hitelesítő adat környezeti változókban.
• Nincs hitelesítő adat perzisztens memóriában.
• Nincs hitelesítő adat naplókban.
• Nincs hozzáférés a gazdagép felhasználó hitelesítő könyvtárához.
• Minden hitelesítő adat használatának független monitorozását.

A titkok anonimizálása továbbra is hasznos, de ez egy tartalék vezérlő. Az anonimizálás elszalaszthatja a kódolt, átalakított, felosztott, tömörített vagy közvetve továbbított titkokat.

Fenyegetési kategória 4: Adatmérgezés és memória mérgezés

Tároló és függőségi mérgezés

Az adatmérgezés akkor fordul elő, amikor egy támadó olyan információt módosít, amelyet az ügynök érvelésre használ.

Példák:

• Egy readme, amely arra utasítja az ügynököt, hogy tiltsa le a biztonsági ellenőrzéseket.
• Egy tesztfixture, amely hamis működési követelményeket tartalmaz.
• Egy függőségi leírás, amely rosszindulatú telepítési parancsot javasol.
• Egy konfigurációs fájl, amely csendesen megváltoztatja az eszközjogosultságokat.
• Egy generált hibaüzenet, amely arra utasítja az ügynököt, hogy töltse fel a naplókat.
• Egy mérgezett gyorsítótár, amely módosított függőségeket tartalmaz.
• Egy pull request megjegyzés, amely megváltoztatja a látszólagos feladatot.

Az ügynök mindezeket ugyanazon beszélgetési kontextus részeként kezelheti, annak ellenére, hogy eltérő jogosultsági szintekkel rendelkeznek.

Perzisztens memória mérgezés

A memória mérgezés súlyosabb, mert a rosszindulatú utasítás túlélheti az eredeti munkamenetet.

A Cisco leírt egy Claude Code memória mérgezési forgatókönyvet, amelyben egy normális fejlesztői munkafolyamat rosszindulatú vagy bizonytalan útmutatások tárolását és későbbi munkamenetekben történő továbbítását okozta. (blogs.cisco.com) Az OWASP a memória- és kontextusmérgezést különálló ügynökbiztonsági kockázatként írja le, mert a perzisztens állapot befolyásolhatja a jövőbeli viselkedést jóval azután is, hogy az eredeti, támadó által vezérelt bemenet eltűnt. (genai.owasp.org)

A memóriát tehát konfigurációs adatbázisként kell kezelni, nem pedig ártalmatlan jegyzetekként.

A szükséges vezérlők a következők:

• Válassza el a megbízható házirendet a tanult memóriától.
• Követeljen felülvizsgálatot a perzisztens írások előtt.
• Rögzítse minden memóriaelem forrását.
• Rendeljen lejárati dátumokat a memóriákhoz.
• Akadályozza meg a titkok bejutását a memóriába.
• Támogassa a visszaállítást egy ismert jó memóriaállapotra.
• Vizsgálja át a memóriát utasításszerű tartalomra.
• Tesztelje a viselkedést kikapcsolt memóriával.
• Tartson fenn külön memóriát minden tárolóhoz, felhasználóhoz és környezethez.
• Ne engedélyezze a nem megbízható tároló tartalomnak, hogy globális memóriát írjon.

Fenyegetési kategória 5: Ellátási lánc kockázata

Az autonóm kódoló ügynökök öt irányba bővítik a szoftverellátási lánc kockázatát.

Csomagok és telepítési szkriptek

Egy ügynök telepíthet rosszindulatú függőséget, miután elolvasott egy mérgezett utasítást. A csomag életciklus szkriptek azonnal végrehajthatók, és hozzáférhetnek a helyi hitelesítő adatokhoz.

A 2025-ös Nx kompromisszum megmutatta, hogyan tette lehetővé egy ellopott publikációs token rosszindulatú csomagoknak a felhasználói rendszerek szkennelését, a helyi mesterséges intelligencia eszközökkel való interakciót és az összegyűjtött adatok feltöltését nyilvános tárolókba. Az Nx jelentése szerint a rosszindulatú csomagok körülbelül négy órán keresztül voltak elérhetők. (nx.dev)

Képességek és ügynökbővítmények

Az ügynök képességei gyakran tartalmaznak utasításokat, szkripteket, eszközdefiníciókat és hozzáférési követelményeket. A Snyk 2026-os auditja 3984 képességről két nyilvános képesség-ökoszisztémában jelentős mennyiségű bizonytalan és rosszindulatú tartalmat tárt fel. Ezek az adatok szkennelési eredmények, nem pedig megerősített jogsértések, de azt mutatják, hogy az ügynök képesség-piacokat nem megbízható szoftverregiszterekként kell kezelni, nem pedig alkalmazásboltokként. (snyk.io)

Fejlesztői környezeti bővítmények

A bővítmények hozzáférhetnek forráskódhoz, fájlokhoz, terminálokhoz, hitelesítő adatokhoz és hálózati szolgáltatásokhoz. Egy rosszindulatú vagy kompromittált bővítmény közvetlenül megtámadhatja a fejlesztőt, vagy megváltoztathatja az ügynök viselkedését.

Build gyorsítótárak

A build gyorsítótárak átléphetik a bizalmi határokat. Egy alacsony jogosultságú munkafolyamat írhat egy gyorsítótár műterméket, amelyet egy magasabb jogosultságú kiadási munkafolyamat később felhasznál. Ez utat nyit a hibajegy-feldolgozástól a hitelesítő adatok ellopásáig, még akkor is, ha az eredeti munkafolyamatnak nincs közvetlen hozzáférése a kiadási titkokhoz.

Modellek, promptok és eszközdefiníciók

Egy modellfrissítés vagy prompt változás megváltoztathatja, hogyan értelmezi az ügynök az utasításokat. Egy eszközfrissítés új alapértelmezett engedélyt vezethet be, vagy megváltoztathatja a parancsok értelmezésének módját.

Minden éles ügynöktelepítésnek verziószámozni és jóváhagyni kell:

• Modell azonosítót.
• Rendszerutasításokat.
• Fejlesztői utasításokat.
• Eszközdefiníciókat.
• Házirend szabályokat.
• Konténer képet.
• Függőségi zárolt fájlt (lockfile).
• Hálózati házirendet.
• Titokkonfigurációt.
• Memória sémát.
• Értékelési csomagot.

Jelentős incidensek és nyilvánosságra hozatali esetek 2025-ből és 2026-ból

Az alábbi lista megkülönbözteti a működési incidenseket, a biztonsági tanácsadásokat és az ellenőrzött kutatási nyilvánosságra hozatali eseteket.

A Replit eseményt nyilvánosan felhasználói jelentések és vezetői válaszok útján írták le, nem pedig hagyományos biztonsági tanácsadás formájában. A Replit ezt követően hangsúlyozta a fejlesztési és éles környezet elválasztását, a pillanatfelvételeket, a visszaállításokat és az ügynök hozzáférésének korlátozását az éles adatbázisokhoz. (fastcompany.com)

A Cline incidens különösen fontos, mert bemutatja az összehangolást a fenyegetési modell minden fő kategóriájában: prompt injekció, eszköz végrehajtás, gyorsítótár-mérgezés, titoklopás, ellátási lánc kompromittálása és automatikus telepítés downstream fejlesztői rendszereken. A Cline tanácsadása megerősíti a jogosulatlan csomagpublikációt, míg a kutató idővonala leírja az előző ügynök munkafolyamatot és a gyorsítótár támadási láncot. (github.com)

A fő vezérlési minták értékelése

Egyetlen vezérlő sem elegendő. A legjobb telepítések több független réteget kombinálnak.

Képesség sandboxok

A sandboxok a legértékesebb vezérlők közé tartoznak, mert csökkentik a robbanási sugarat, még akkor is, ha az ügynök rosszindulatúan viselkedik. Az Anthropic a folyamat sandboxokat, virtuális gépeket, fájlrendszer határokat és kimenő forgalom vezérlőket írja le az autonóm viselkedés megfékezésének elsődleges módjaként. (anthropic.com)

Azonban a sandboxokat szoftverbiztonsági határokként kell kezelni. A Codex sérülékenység bemutatta, hogy egy útvonalkonfigurációs logikában lévő hiba alááshatja a szándékolt munkaterület határát. (github.com)

Egy erős sandboxnak tartalmaznia kell:

• Eldobható virtuális gépet vagy megerősített konténert.
• Nincs hozzáférés a fejlesztő otthoni könyvtárához.
• Nincs hozzáférés secure shell kulcsokhoz vagy felhő parancssori hitelesítő adatokhoz.
• Dedikált munkaterületet, ismert útvonalon csatlakoztatva.
• Csak olvasható hozzáférést az alap képhez.
• Nincs privilegizált konténer mód.
• Korlátozott folyamatlétrehozást.
• CPU, memória, lemez és végrehajtási idő kvótákat.
• Nincs hozzáférés éles hálózatokhoz.
• Automatikus megsemmisítést a feladat után.
• Pillanatfelvételt vagy műterméket a végső munkaterületről felülvizsgálat céljából.

Házirend motorok

Egy házirend motornak a modell és az eszköz között kell elhelyezkednie. Nem szabad arra hagyatkozni, hogy a modell önmagát szabályozza.

Ahelyett, hogy engedélyeznénk az ügynöknek tetszőleges shell parancsok kiadását, tegyünk elérhetővé típusos műveleteket, például:

• Fájl olvasása a munkaterületen belül.
• Fájl írása a munkaterületen belül.
• Jóváhagyott tesztparancs futtatása.
• Függőség telepítése egy jóváhagyott regiszterből.
• Ág létrehozása.
• Pull request nyitása.
• Telepítési jóváhagyás kérése.

A házirend motornak függetlenül kell validálnia:

• A felhasználó identitását.
• A tárolót.
• A célútvonalat.
• A parancsot vagy eszközt.
• Az adatbesorolást.
• A célállomást.
• A várható mellékhatást.
• A jóváhagyás állapotát.
• A munkamenet fennmaradó költségvetését.

Reprodukálható eszközvégrehajtás

A reprodukálhatóságot gyakran build-minőségi funkcióként kezelik, de egyben biztonsági vezérlő is.

Minden ügynök futtatásánál rögzítse:

• A pontos modellverziót.
• A pontos ügynökverziót.
• A pontos eszközverziókat.
• A konténerkép lenyomatát.
• A függőségi zárolt fájlt (lockfile).
• A tároló commitot.
• A hálózati házirendet.
• A házirend verzióját.
• Az eszközhívás sorrendjét.
• Az ebből eredő műtermék hash-eket.

A NIST Secure Software Development Framework hangsúlyozza a biztonságos fejlesztői környezeteket és a szoftverkomponensek származási adatainak gyűjtését. (csrc.nist.gov)

Ne használjon változó értékeket, mint például:

• Legújabb csomagverzió.
• Nem rögzített konténer címkék.
• Nem ellenőrzött távoli szkriptek.
• Lebegő eszközdefiníciók.
• Nem ellenőrzött ágnevek.
• Megosztott gyorsítótárak jogosultsági szinteken keresztül.

Titok anonimizálás és közvetítés

A titok anonimizálásnak több ponton kell működnie:

1. Mielőtt a tartalom bekerül a modell kontextusába.
2. Mielőtt az eszköz argumentumokat elküldik.
3. Mielőtt az eszköz kimenet visszatér.
4. Mielőtt a naplók tárolódnak.
5. Mielőtt a fájlokat commitálják.
6. Mielőtt a hálózati kérések elhagyják a futtatót.
7. Mielőtt a megjegyzések, hibajegyek és pull requestek létrejönnek.

Egy dedikált titokbróker erősebb, mint a környezeti változók. Az ügynök felkéri a brókert egy szűken definiált művelet végrehajtására, például egy privát csomag letöltésére, anélkül, hogy megkapná a nyers hitelesítő adatot.

Kimenő forgalom szűrése

A hálózati hozzáférést alapértelmezetten le kell tiltani.

Egy gyakorlati kimenő forgalmi proxynak rögzítenie kell:

• Cél domain és cím.
• Kérés metódus.
• Kérés méret.
• Válasz méret.
• Kérés identitás.
• A kérést kezdeményező eszköz.
• Hogy jelen volt-e érzékeny adat.
• Hogy a célállomás jóváhagyott volt-e.
• Hogy a kérés jóváhagyást igénylő művelet során történt-e.

A GitHub ügynök alapú munkafolyamat architektúrája dedikált tűzfalat, megbízható Model Context Protocol átjárót és izolált modell hitelesítési proxyt használ. (github.blog)

A kimenő forgalom vezérlőknek figyelembe kell venniük az indirekt csatornákat is. Egy megbízható forráskód-kezelő szolgáltatáshoz intézett kérés mégis létrehozhat rosszindulatú hibajegyet vagy pull requestet, amely lopott adatokat tartalmaz. Ezért a hálózati vezérlőket biztonságos kimeneti szabályokkal és tartalomvizsgálattal kell kombinálni.

Ajánlott referencia architektúra

Egy biztonságos autonóm kódolási telepítésnek az alábbi rétegeket kell tartalmaznia:

1. Kontextus beviteli réteg

Ez a réteg gyűjti a tároló fájlokat, hibajegyeket, teszteredményeket és eszköz kimeneteket. Minden elemet az alábbiak szerint kell címkéznie:

• Forrás.
• Bizalmi szint.
• Szerző.
• Időbélyeg.
• Tároló.
• Adatbesorolás.
• Hogy tartalmaz-e végrehajtható tartalmat.
• Hogy tartalmaz-e utasításokat.

2. Utasítás és adat szétválasztás

Az ügynöknek explicit nyilatkozatot kell kapnia arról, hogy a tároló tartalom, az eszköz kimenet, a weboldalak és a hibajegy szövege adatok, hacsak külön nem engedélyezettek.

A rendszernek meg kell őriznie a kontextus minden egyes részének forrását, ahelyett, hogy mindent egyetlen, nem differenciált prompttá lapítana le.

3. Házirend-érvényesítési pont

Minden eszközhívásnak át kell mennie egy házirend motoron, amely ellenőrzi:

• Identitást.
• Képességet.
• Célt.
• Argumentumokat.
• Adatérzékenységet.
• Hálózati célállomást.
• Jóváhagyási követelményeket.
• Erőforrás-költségvetést.

4. Képesség bróker

Az ügynök ideiglenes képességeket kap széles körű hitelesítő adatok helyett. A brókernek a jelenlegi lépéshez szükséges legkisebb engedélyt kell kiadnia, és utána vissza kell vonnia azt.

5. Izolált végrehajtási környezet

Az ügynök eldobható környezetben fut, a következőkkel:

• Nincs éles csatlakozás.
• Nincs fejlesztői hitelesítő adat csatlakoztatása.
• Nincs hozzáférés nem kapcsolódó tárolókhoz.
• Korlátozott fájlrendszer hatókör.
• Szigorú erőforrás-korlátok.
• Nem változtatható alap kép (immutable base image).

6. Eszköz átjáró

A külső eszközök egy átjárón keresztül érhetők el, amely elvégzi:

• Eszköz identitás ellenőrzést.
• Argumentum validálást.
• Sebességkorlátozást (rate limiting).
• Kimeneti szűrést.
• Engedélyellenőrzéseket.
• Audit naplózást.
• Hitelesítő adatok izolálását.

7. Kimenő forgalmi proxy

Minden külső kommunikáció egy ellenőrzött proxyn keresztül zajlik. Az ügynök közvetlen hálózati hozzáférését blokkolni kell.

8. Biztonságos kimenet előkészítés

Az ügynöknek a következőket kell előállítania:

• Egy patch-et.
• Egy ágat.
• Egy változáskérést.
• Egy telepítési javaslatot.
• Egy csomagjelöltet.

Nem szabad közvetlenül egyesíteni, telepíteni, publikálni vagy megváltoztatni az éles állapotot.

9. Független felülvizsgálat és előléptetés

Egy különálló folyamat felülvizsgálja a javasolt kimenetet a következők használatával:

• Titokvizsgálat.
• Statikus biztonsági elemzés.
• Függőségi elemzés.
• Licenc és származási ellenőrzések.
• Tesztelési eredmények.
• Házirend validálás.
• Emberi felülvizsgálat nagy hatású változások esetén.

A GitHub felhőalapú ügynöke hasonló mintát követ azáltal, hogy piszkozat pull requesteket hoz létre, korlátozza az ág hozzáférést, emberi felülvizsgálatot igényel, korlátozza a munkafolyamat végrehajtását és munkamenet-naplókat biztosít. (docs.github.com)

Megvalósítható enyhítési ellenőrzőlisták

Mielőtt engedélyezné az ügynököt

• Hozzon létre egy leltári bejegyzést az ügynök számára.
• Azonosítsa az ügynök tulajdonosát és üzleti célját.
• Dokumentáljon minden eszközt, csatlakozót és külső szolgáltatást.
• Dokumentáljon minden hitelesítő adatot, amelyhez az ügynök hozzáférhet.
• Erősítse meg, hogy nincsenek éles hitelesítő adatok.
• Futtassa az ügynököt eldobható környezetben.
• Tiltsa le az automatikus csomagtelepítést, hacsak nincs explicit módon jóváhagyva.
• Tiltsa le a korlátlan hálózati hozzáférést.
• Rögzítse (pin) a modellt, ügynököt, eszközöket, függőségeket és konténerképet.
• Védje az ügynök utasításfájljait és konfigurációs fájljait kódtulajdonlási szabályokkal.
• Határozza meg, mely műveletek igényelnek emberi jóváhagyást.
• Határozzon meg maximális munkamenet-időtartamot és költséget.
• Hozzon létre egy visszaállítási tervet.

Mielőtt engedélyezné a tároló hozzáférést

• Osztályozza a tárolót nyilvánosként, belsőként, bizalmasként vagy szigorúan korlátozottként.
• Tekintse át az összes tároló által vezérelt ügynök konfigurációt.
• Kezelje a readme fájlokat, hibajegy tartalmat, megjegyzéseket és teszt kimenetet nem megbízhatóként.
• Tiltsa le a hookok és munkaterület parancsok automatikus végrehajtását.
• Szkennelje a függőségeket és a telepítési szkripteket.
• Használjon tiszta, izolált munkaterületet.
• Akadályozza meg a hozzáférést a nem kapcsolódó tárolókhoz.
• Ellenőrizze, hogy nincsenek-e titkok a munkaterületen vagy a build naplókban.
• Tesztelje rosszindulatú hibajegy szöveggel és mérgezett dokumentációval.
• Rögzítse a tároló commitját és az ügynök konfigurációs hash-ét.

Mielőtt engedélyezné az eszközhasználatot

• Cserélje le az önkényes shell hozzáférést típusos műveletekre, ahol lehetséges.
• Használjon engedélyezési listát az eszközökhöz és célállomásokhoz.
• Validálja az útvonalakat kanonizálás után.
• Elutasítsa a szimbolikus link alapú kitöréseket.
• Akadályozza meg, hogy az eszközök módosítsák saját házirend fájljaikat.
• Akadályozza meg, hogy az ügynök megváltoztassa saját jóváhagyási módját.
• Követeljen megerősítést az érzékeny adatokat tartalmazó hálózati hozzáférés előtt.
• Naplózzon minden eszközhívást és annak eredményét.
• Állítson be korlátokat a fájlméretre, parancs futási idejére, hálózati volumenre és tokenhasználatra.
• Tekintse át a Model Context Protocol szerver leírásait és engedélyeit.
• Elutasítsa az aláíratlan vagy nem ellenőrzött eszközdefiníciókat.

Mielőtt engedélyezné a kód publikálását vagy telepítését

• Követeljen külön identitást az ügynök és az emberi kezdeményező számára.
• Követeljen emberi felülvizsgálatot az egyesítés előtt.
• Követeljen független jóváhagyást a telepítés előtt.
• Használjon rövid élettartamú publikációs hitelesítő adatokat.
• Használjon megbízható publikálást vagy workload identitást hosszú élettartamú tokenek helyett.
• Követelje meg a műtermék aláírásokat és a származást.
• Szkenneljen titkok és rosszindulatú függőségek után.
• Buildeljen tiszta környezetből, megosztott változó gyorsítótárak nélkül.
• Ellenőrizze, hogy a műtermék megegyezik-e a felülvizsgált forrással.
• Tartson fenn gyors csomag- vagy bővítmény visszaállítási folyamatot.
• Tesztelje a biztonsági mentések és pillanatfelvételek visszaállítását.

Incidensre reagálás során

• Szüntesse meg az érintett ügynök munkamenetét.
• Izolálja a futtatót vagy a munkaállomást.
• Vonjon vissza minden, az ügynök számára elérhető hitelesítő adatot.
• Vonjon vissza minden, az eszközök és csatlakozók számára elérhető hitelesítő adatot.
• Őrizze meg a munkamenet, eszköz, hálózat és forráskód-kezelő naplókat.
• Vizsgálja meg a commitokat, hibajegyeket, pull requesteket, megjegyzéseket és csomagpublikációkat.
• Vizsgálja meg a gyorsítótárakat és telepítési szkripteket.
• Hasonlítsa össze a publikált műtermékeket a megbízható forrással.
• Keressen jogosulatlan kimenő célállomásokat.
• Tekintse át a perzisztens memóriát és a konfigurációs fájlokat.
• Értesítse a tároló-, csomagregiszter- és eszközgyártókat.
• Forgassa újra a hitelesítő adatokat a forenzikus elemzés után, ha azok esetleg kitettek voltak.
• Rögzítse, hogy elhagyta-e adat a jóváhagyott környezetet.

Javasolt biztonsági szolgáltatási szint megállapodások (SLA-k)

Ezek javasolt telepítési célok, nem pedig univerzális iparági szabványok. A szervezeteknek a kockázattűrő képességükhöz kell igazítaniuk őket.

Erősen érzékeny környezetek esetében a legfontosabb szolgáltatási szint megállapodásnak a nulla sikeres kritikus útvonal kiszivárgásnak kell lennie, nem pedig az átlagos észlelési aránynak. Egy sikeres kiadási token lopás súlyosabb lehet, mint több ezer ártalmatlan blokkolt kísérlet.

Auditálási műtermékek, amelyeket minden telepítésnek elő kell állítania

Egy érett telepítésnek képesnek kell lennie arra, hogy utólag válaszoljon:

• Ki indította az ügynököt?
• Mely felhasználói és szolgáltatási identitások vettek részt?
• Melyik tárolót és commitot használták?
• Melyik modell és ügynök verzió futott?
• Mely utasítások voltak aktívak?
• Milyen külső tartalom került a kontextusba?
• Mely eszközök voltak elérhetők?
• Mely eszközöket hívták meg valójában?
• Milyen argumentumokat küldtek?
• Mely fájlokat olvasták vagy módosították?
• Milyen hálózati célállomásokat kerestek fel?
• Mely hitelesítő adatokat kérték?
• Mely házirendek engedélyezték vagy tiltották az egyes műveleteket?
• Milyen emberi jóváhagyásokat szereztek be?
• Milyen műtermék készült?
• Milyen műterméket publikáltak?
• Mi volt a végső rendelkezés?

Tartson fenn legalább az alábbi műtermékeket:

1. Ügynök leltári nyilvántartás
2. Fenyegetési modell és adatfolyam diagram
3. Képesség és engedély manifesztum
4. Eszköz és csatlakozó leltár
5. Modell, prompt és házirend verzió nyilvántartás
6. Konténerkép és függőségi anyagjegyzék
7. Hálózati házirend és kimenő forgalom napló
8. Titok kitettségi és anonimizálási jelentés
9. Munkamenet és eszközhívás nyomkövetés
10. Emberi jóváhagyási nyilvántartás
11. Biztonsági értékelési és red-team jelentés
12. Kiadási származás és műtermék aláírás
13. Memória származás és visszaállítási nyilvántartás
14. Incidensre reagálás és visszaállítási teszt
15. Gyártói biztonsági tanácsadás és patch nyilvántartás

A naplóknak manipulációbiztosnak, hozzáférés-vezéreltenek és az adatok érzékenységének megfelelően megőrzöttnek kell lenniük. A szokásos fejlesztési munkamenetek kilencven napos megőrzést igényelhetnek, míg a kiadási rendszerekhez, szabályozott adatokhoz vagy nagy értékű tárolókhoz hozzáférő munkamenetek egy évig vagy hosszabb ideig tarthatók meg.

Az OpenAI belső monitorozást ír le, amely felülvizsgálja a kódoló ügynök interakcióit, eszközhívásait és potenciálisan gyanús viselkedését, míg a GitHub hangsúlyozza a munkamenet-naplókat, aláírt commitokat, attribúciót és audit nyilvántartásokat. Ezek a minták egy tágabb elvet támogatnak: az ügynök viselkedésének megfigyelhetőnek kell lennie függetlenül az ügynök saját magyarázatától arról, hogy mit tett. (openai.com)

Az első gyakorlati lépés

A legjobb első lépés nem az ügynök telepítése éles tároló ellen.

Ehelyett:

1. Hozzon létre egy eldobható teszt tárolót.
2. Adjon az ügynöknek csak olvasható feladatot.
3. Futtassa friss sandboxon belül.
4. Kapcsolja ki a fejlesztői hitelesítő adatokhoz való hozzáférést.
5. Blokkoljon minden hálózati forgalmat, kivéve a modell szolgáltatóját.
6. Adjon hozzá szándékosan rosszindulatú hibajegyet, readme utasítást, eszközleírást és konfigurációs fájlt.
7. Rögzítse minden megkísérelt fájlhozzáférést, eszközhívást, parancsot és hálózati kérést.
8. Használja az eredményeket az első engedélyezési manifesztum és biztonsági szolgáltatási szint megállapodás létrehozásához.

Ha az ügynök nem tudja biztonságosan befejezni egy csak olvasható feladatot ezekben a körülmények között, akkor nem áll készen az írási hozzáférésre, kiadási automatizálásra vagy éles rendszerekre.

Összefoglalás

Az autonóm kódoló ügynököket nem megbízható, identitással rendelkező automatizálási rendszerekként kell biztosítani, nem pedig közönséges fejlesztői eszközökként.

A döntő biztonsági kérdés nem ez:

„A modell követni fogja a helyes utasításokat?”

Hanem ez:

„Mi történik, ha a modell rossz utasításokat követ, miközben valódi jogosultságokkal rendelkezik?”

A prompt injekció, az eszközök kihasználása, a titkok ellopása, az adatmérgezés és az ellátási lánc kompromittálása különböző belépési pontok ugyanabba az alapvető hibába: egy ügynöknek túl sok bizalmi határt engednek átlépni független érvényesítés nélkül.

A 2025-ös és 2026-os incidensek azt mutatják, hogy a leghatékonyabb vezérlők architekturálisak:

• Tartsa távol az ügynököket a titkoktól.
• Használjon eldobható képesség sandboxokat.
• Érvényesítse a házirendeket a modellen kívül.
• Válassza el a fejlesztést az éles környezettől.
• Kezelje a konfigurációt és a memóriát végrehajtható támadási felületekként.
• Használjon ellenőrzött kimenő forgalmat.
• Távolítsa el a megosztott gyorsítótárakat a privilegizált kiadási munkafolyamatokból.
• Rögzítse és ellenőrizze minden eszközt és műterméket.
• Minden írást szakaszosan végezzen el.
• Követeljen független jóváhagyást a visszafordíthatatlan műveletekhez.
• Őrizzen meg részletes, manipulációbiztos audit nyilvántartásokat.

Az autonómia hasznos és biztonságos lehet, de csak akkor, ha a rendszer úgy van kialakítva, hogy egy zavarodott, manipulált vagy kompromittált ügynök korlátozott jogosultságokkal, korlátozott hatókörrel, korlátozott idővel és egyértelműen helyreállítható hibaüzemmóddal rendelkezzen.