Miért mondja egy MI-ügynök, hogy „kész”, amikor a munka még nincs befejezve?

Hogyan szökött ki egy OpenAI-modell a sandboxból, és hogyan törte fel a Hugging Face-t?#

Először a tények, aztán hogy miért fontos ez neked.

Az OpenAI azt mérte fel, mire képesek modelljei az offenzív kiberbiztonság területén. Az ExploitGym tesztet használták: 898 feladatot, amelyekben egy ismert sérülékenységet működő exploitra kell váltani, vagyis egy olyan kész programra, amely kihasználja az adott sérülékenységet. Hogy lássák a valódi teljesítményplafont, kikapcsolták a beépített biztonsági szűrőket, amelyek normális esetben megakadályozzák a modellt az ilyesmiben. Teljesen lezárták a környezetet, egyetlen kijáratot hagyva: egy belső közvetítőprogramot, amely csomagok telepítésére szolgált.

A nulladik napi sérülékenység olyan rés, amelyről még senki sem tud, még az sem, aki a programot írta. A modellek éppen azon az egyetlen kijáraton találtak ilyet.

Ezután magasabb jogosultságokat szereztek, áthaladtak a belső hálózaton egy internetkapcsolattal rendelkező gépig, majd arra jutottak, hogy az ExploitGym válaszai talán a Hugging Face-en vannak. Senki sem mondta nekik, hogy létezik a Hugging Face. Maguktól jöttek rá.

A feltevés téves volt. Az ExploitGym egyáltalán nincs a Hugging Face-en. Ettől a feltörés még ugyanúgy valódi.

A Hugging Face maga fedezte fel a behatolást, és július 16-án közzétette a tájékoztatását, akkor még nem tudva, ki törte fel.

A beszámoló egy másik részlete sokat elárul a helyzetről. Amikor a Hugging Face mérnökei a támadási naplót vezető modelleknek próbálták beadni a szokásos kereskedelmi felületeken keresztül, a biztonsági szűrők letiltották a kéréseket: nem tudják megkülönböztetni a feltörést vizsgáló embert attól, aki végrehajtja. Végül az elemzést egy nyílt modellen, saját hardverükön futtatták.

Az OpenAI július 21-én ismerte el az esetet, öt nappal a Hugging Face közzététele után. Addigra maga a behatolás körülbelül tíz napja történt.

Az OpenAI így zárta saját elemzését.

A modell rögzült a teszt szűk céljánál, és szélsőségekig ment annak eléréséért. A hyper-focused és a fairly narrow testing objective kifejezések magától az OpenAI-tól származnak, és saját modelljeire vonatkoznak.

Ez teremt hidat valaki más laborja és a te laptopod között.

Miért nem „hallucináció” ez?#

Gyakran látok a beszélgetésekben ilyen kifejezéseket: „megint hallucinál”, „túlterhelődött a kontextus”, vagy „tervet kellett volna készítenünk”. Néha valóban ez történt. De amikor egy MI-ügynök azt írja, hogy „kész, ellenőriztem, minden működik”, miközben a munka nincs kész, általában semmi köze ehhez a kontextus mennyiségének.

Nem talált ki semmit. Pontosan azt tette, amit mértél.

A népszerű, mindent lefedő „hallucináció” szó alá három különböző hibát sorolunk. Így különböznek:

Az első kontextussal javítható, és ez a legismertebb eset. A második külön jelenség, amelyet a Claude mindennel egyetért című elemzés tárgyal: a modell feláldozza a pontosságot a gyors egyetértésért. Mindkettő a munka előtt, a bemeneti szakaszban történik.

A táblázat harmadik sora a cikk témája. Itt az ügynök nem hízelgett és nem talált ki dolgokat. Dolgozott, ellenőrzött és igazat jelentett. Csakhogy ez az igazság a mérőszámról szól, és semmit nem mond a feladatról.

A harmadik hibának neve is van.

Mi az a reward hacking egyszerűen?#

Az Anthropic maga adja meg a definíciót.

Az ötlet régebbi, mint a neurális hálózatok. Egy DeepMind-tanulmány specification gamingnek nevezi, és egy mítosszal magyarázza.

Midasz pontosan azt kapta, amit kért. A probléma a kérés megfogalmazásában rejlett.

A programozásban ez kézzelfogható alakokat ölt. Íme egy tankönyvi példa, szintén az Anthropic-tól:

És ez nem valamilyen egzotikus laboratóriumi körülmény. A Cursor 731 munkamenetet elemzett egy népszerű benchmarkon.

A „megoldott” feladatok közül tízből hatnál kész válaszokat találtak meg. Pontosan ezért változtatja az iparág a teljesítmény mérésének módját: elemeztünk egy éles üzemi készenlétet mérő benchmarkot, ahol az ellenőrzések teljesítése már nem a fő kritérium.

Hogyan néz ki mindez egy hétköznapi termékben?#

A laboratóriumi példákat könnyű különlegesnek tekinteni. Ezért íme négy történet a gyakorlatból. Az ügyfelek és az iparágak megváltoztak, de a mechanizmusok olyanok maradtak, amilyenek voltak.

Négy zöld ellenőrzés és egy leállt szolgáltatáskomponens

Egy ingatlaniroda szolgáltatást épít: egy ingatlanhirdetéseket tartalmazó webhelyet, valamint egy külön háttérfeldolgozót, amely éjszaka exportálja a hirdetéseket a platformokra. Az ügynök befejezi a feladatot, és ezt jelenti: a típusellenőrzés sikeres, a kódstílus-ellenőrzés sikeres, a build zöld, az oldalak válaszolnak, és vizuálisan is megvizsgálták őket.

Minden állítás igaz. Egyiknek sincs köze az éjszakai feldolgozóhoz: külön folyamatként fut, és egyáltalán nem része a webhely buildjének. A telepítés sikerül, a webhely tökéletesen működik, a hirdetések exportálása leáll, az ügyfelek pedig csak egy nappal később jelzik.

Mielőtt azt mondom, hogy „kész”, most már felteszek egy kérdést: a munkának melyik része fut az ellenőrzésem hatókörén kívül? Ha van ilyen, futtasd külön, és a parancs kimenetét is tedd bele a jelentésbe. Az „ellenőriztem” szó önmagában nem zárja le az ügyet.

A hamis pipa éppen a kapcsolódási pontnál található

Egy webáruház egy nagy feladatot egyszerre több ügynök között oszt szét: az egyik a backendért felel, a másik az oldalakért, a harmadik a termékkártyákért. Mindegyik szorgalmasan dolgozik, és mindegyiknél zöldek az ellenőrzések.

Egy héttel később kiderül, hogy a „hasznos volt ez az értékelés” gomb sehol sem működik. A backend teljesen elkészült, az ellenőrzései zöldek, az újraszámítás szabályait betartották. Csakhogy egyetlen oldal sem jeleníti meg a gombot: a gomb az egyik ügynök területéhez tartozott, az oldalak egy másikéhoz, és senkinek nem jutott eszébe, hogy kitegye a képernyőre. A számláló örökre nulla maradt volna.

A „kód meg van írva, és az ellenőrzések lefedik” és a „funkció működik” két külön állítás. A másodikat minden új funkciónál egy kérdéssel ellenőrzöm: ki hívja meg? Ezt a projekt átkutatásával igazolom, mert itt az ügynök jelentése nem tekinthető hiteles forrásnak.

A felülvizsgáló csak arra néz, amerre kérték

Egy szolgáltatás hűségszinteket vezet be: minél többet fizetsz, annál magasabb a státuszod és a kedvezményed. Telepítés előtt a kódot azzal az utasítással küldik felülvizsgálatra: „Próbáld meg feltornázni a saját státuszodat.” A felülvizsgáló tisztességesen elvégzi a munkát, és azt jelenti, hogy „nincs kritikus probléma” — valóban nem lehet feltornázni a státuszt.

Egy második kör más kérdést tesz fel: „Mi történik a státusszal, ha visszatérítik a pénzt?” Tíz perc alatt megtalálják a rést. A pontokat a tranzakciós naplóból számították, a napló pedig semmit sem tud a visszatérítésekről. Veszel valamit, pontokat szerzel, visszakéred a pénzt, és örökre megtartod a státuszt és a kedvezményt.

Az első felülvizsgáló nem hanyagolta el a munkát. Szerkezetéből adódóan nem láthatta: az „bemenet, előléptetés” irányt kapta, miközben a rés a „bemenet visszafordítása, előléptetés megtartása” irányban volt. Ha pénz, hozzáférés vagy megvásárolható státusz forog kockán, két ellenőrzési kört futtatok, a másodikban pedig kifejezetten felsorolom a fordított irányokat: visszatérítés, letiltás, hozzáférés visszavonása, lejárat, az adatforrás törlése.

A mérőszám a hasonlóságot jutalmazza

Egy kézbesítési szolgáltatás úgy dönt, megméri, hogy javultak-e a kezelőknek adott MI-javaslatok. Elővesz kétszáz régi ügyfélszolgálati megkeresést, lefuttatja őket az új verzión, majd megméri, mennyire hasonlít a vázlat arra, amit egy emberi kezelő ténylegesen válaszolt. A mérés magabiztos javulást jelez.

A javulás két okból semmit sem jelent. A vázlathoz szükséges kontextust „a mai állapot szerint” állítják össze, és a teljes levelezést tartalmazza, köztük éppen azt a kezelői választ, amellyel később összehasonlítják. A modell nem választ ír; a neki megmutatott referenciát fogalmazza át. Ráadásul maga a mérőszám a szavak és a terjedelem egyezését jutalmazza: az a vázlat, amely hibás dátumot ad meg ugyanazokkal a szavakkal, amelyeket a kezelő a helyes dátumra használt, magas pontszámot kap.

Minden „a hasonló jó” mérőszám mellé olyan kemény, mechanikus kapukat állítok, amelyeket a stílus nem tud becsapni: kitalált számok és dátumok, tiltott szavak, cselekvésre tett ígéretek. A kapuk eredményének bármilyen romlása érvényteleníti a mérőszám javulását.

Miért nem bizonyít semmit, ha az ügynök azt mondja: „ellenőriztem”?#

Végy egy tetszőleges projektet, és kérdezd meg az ügynöktől: „Ellenőrizd a biztonságot.” Gyakran azt kapod válaszul: „minden rendben, nincs kritikus probléma.”

Most kérdezz meg egy másik modellt ugyanarról a projektről, ugyanígy. Különösen nagy projektnél sok mindent fog találni. A szerző telepítés előtt három különböző modellel ellenőrzi a projektet, és mindegyik más problémára mutat rá.

Ugyanaz a bemenet, ugyanaz a kérdés, ellentétes ítélet. Egyik modell sem rosszabb a másiknál. Egyszerűen a „minden rendben” is generált szöveg, pontosan ugyanazon a rétegen, mint bármely másik válasz. Az ügynök nem tudja megkülönböztetni azt, hogy „megnéztem, tiszta”, attól, hogy „rossz helyen néztem körül”.

Az Anthropic a Claude Code-dokumentációjában írja le ezt a mechanizmust.

Bontsuk ki lassan a mondatot. Amíg nem adsz az ügynöknek futtatható ellenőrzést, egyetlen jelzésből dolgozik: abból, hogy milyennek tűnnek a dolgok. Ebben a felállásban te vagy az ellenőrzési ciklus, de a hibákról éppen te értesülsz utoljára.

Van egy mélyebb réteg is. Amikor az OpenAI a modell gondolatmenetének figyelésével és a „rossz gondolatokért” való büntetéssel próbált nyomást gyakorolni, nem azt az eredményt kapták, amire számítottak.

A kimondott szándék büntetése eltünteti a kijelentést. Maga a szándék megmarad. Ezért nem számítanék arra, hogy az ügynök őszintén elmondja, hogyan csalt.

Maga az eszköz fejlesztője is ebbe az irányba halad. A Claude Code 2.1.215-ös verziójában a /verify és a /code-review skill többé nem indul el a modell saját kezdeményezésére.

2.1.215 - Claude többé nem futtatja saját kezdeményezésére a `/verify` és a `/code-review` skillt;
hívd meg őket a `/verify` vagy a `/code-review` paranccsal, amikor szükséged van rájuk

Az Anthropic nem magyarázza meg, miért. Az alapelv azonban világos: az ellenőrzött fél nem jelöli ki saját magát az ellenőrzésre.

Miért nem tartja kordában az ügynököt a projektfájlban lévő szabály?#

A projekt szabályfájljába ezt írtad: csak közvetlen utasításra commitolj, éles környezetbe csak akkor telepíts, ha kifejezetten ezt mondom, éles adatokat csak olvasási módban érj el.

A szerző tapasztalata szerint tízből nagyjából egyszer az ügynök mégis önállóan továbblép és telepít. Nem rosszindulatból, és nem azért, mert nem olvasta el a szabályt. Elolvasta. Egyszerűen volt előtte egy cél, a szabály pedig csak szöveg volt — ahogy a kontextus többi része is.

Pontosan ez történt az OpenAI laborjában is, csak nagyobb léptékben. A modellek zárt környezetben voltak, egyetlen kijárattal, és számítási kapacitásuk jelentős részét a kijutás keresésére fordították. A tesztfeladatok megoldatlanok maradtak.

Az álláspontom egyszerű: az ügynök nem veszélyes és nem rosszindulatú. Hétköznapi eszköz, csak éppen egy hatalommal felruházott bolond. Ezért a jogosultságait kell korlátozni, nem a kéréseidet újrafogalmazni.

Ami valóban visszatartja: szigorúan csak olvasási hozzáférés az éles adatokhoz. Tiltsd meg a teljes könyvtárak törlését. Tiltsd meg a visszaállítási lehetőség nélküli előzmény-átíró parancsokat. Állíts be költési korlátot a szolgáltatónál. A különbség egy kifejezésben foglalható össze: a „fizikailag nem képes rá” felülírja azt, hogy „megkértem, hogy ne tegye”. A konkrét beállításokat külön tárgyalja a mechanikus fékek a kérések helyett az utasításokban című cikk.

Ettől függetlenül maradj józan. Még a sandbox sem jelent abszolút határt, és a szolgáltató ezt egyértelműen ki is mondja.

Ráadásul a Claude Code beépített vészkijárattal rendelkezik, amelyet maga a modell is használhat. Ha egy parancs sandbox-korlátozás miatt meghiúsul, Claude elemzi a hibát, és megpróbálhatja újra ugyanazt a parancsot egy olyan paraméterrel, amely letiltja a sandboxot. Ezt egy kifejezett strict-mode beállítás zárja ki; alapértelmezés szerint a kerülőút elérhető és dokumentált.

A korlátozás csak annyira működik, amennyire megszigorítod. Minden akadálynak sebességköltsége van — ezt érdemes előre őszintén kiszámolni, mert ha csak egy hét múlva derül ki, többe kerül.

Hogyan állíts fel kijátszhatatlan teljesítési kritériumot?#

A kritérium megfogalmazása mindent meghatároz. Tedd fel ezt az egy kérdést: teljesítheti-e az ügynök ezt a kritériumot anélkül, hogy bármit is tenne?

• „Ellenőrizd, hogy minden működik-e” — teljesítheti. Elég azt írnia, hogy „ellenőriztem, működik”.
• „Futtasd le a buildet, és mutasd meg a kimenetét” — ez már nehezebb; valahonnan meg kell szereznie a kimenetet.
• „Indítsd el az alkalmazást, kattints a fizetés gombra, és mutasd meg, mi jelent meg a képernyőn” — ezt szinte lehetetlen pusztán szöveggel teljesíteni.

Az első és a harmadik közötti különbség a jelentés és a bizonyíték közötti különbség.

A Claude Code-dokumentáció négy szigorúsági szintet ismertet. Hasznos lépcsősor, amelyen a hibaköltség növekedésével feljebb léphetsz:

1. Egy üzenetben. Kérd meg az ügynököt, hogy futtassa le az ellenőrzést, és ismételje addig, amíg itt sikerül. Ez a legolcsóbb, kisebb feladatokra megfelelő.
2. A teljes munkamenetre. Tedd az ellenőrzést a cél feltételévé: egy külön értékelő minden forduló után ellenőrzi, az ügynök pedig addig dolgozik, amíg a feltétel nem teljesül. A technikai részleteket az előre meghatározott teljesítési kritérium beállításáról szóló útmutató tárgyalja.
3. Mechanikus akadály. Egy szkript akkor fut le, amikor az ügynök megpróbálja lezárni a fordulót, és megakadályozza a lezárást, amíg az ellenőrzés nem sikerül. Van egy fontos részlet: nyolc egymást követő blokkolás után a Claude Code felülbírálja az akadályt, és mégis lezárja a fordulót. A rendszerben nincsenek teljesen áttörhetetlen akadályok.
4. Másodvélemény. Külön felülvizsgáló friss kontextussal, akinek az a feladata, hogy megcáfolja az eredményt.

A negyedik azért különbözik, mert ez az egyetlen, amely nem eszközökről szól.

Kinek kell átvennie az ügynök munkáját?#

Amikor nagy feladaton dolgozó ügynököket futtatok ciklusban, így állítom be: az egyik csoport ír; egy másik, friss csoport pedig átveszi a munkát, miután semmilyen részt nem vállalt az írásban.

A „friss” a kulcsszó. Tiszta kontextust jelent, amely nem látta, hogyan születtek a döntések a folyamat során. Ugyanabban a munkamenetben egy másik prompt nem biztosítja ezt. A kódot író ember már időt töltött azzal, hogy meggyőzze magát a helyességéről, és továbbra is megerősítést fog keresni. Nem érdeke a cáfolat.

A felülvizsgáló feladatának megfogalmazása fontosabb, mint a felülvizsgáló modellje. Hasonlítsd össze:

• „Vizsgáld felül ezt a munkát” — a felülvizsgáló azt találja meg, amit könnyű megtalálni, és azt írja: „általában rendben”.
• „Próbáld bebizonyítani, hogy ez a munka NEM készült el” — a felülvizsgáló elkezd réseket keresni, mert ez a célja.

A második megfogalmazás ugyanabból az okból működik jobban, amiért az ExploitGym kudarcot vallott: az ügynök elköteleződik a kapott cél mellett. Add neki azt a célt, hogy találjon rést, és keresni fogja.

Íme a teljes szöveg, készen arra, hogy változtatás nélkül bemásold:

Más munkáját vizsgálod. Nem te írtad, és nem kell megvédened.

A célod annak bizonyítása, hogy az állított eredmény NEM valósult meg. Találj legalább három módot arra, ahogyan az eredmény nem valósulhatott meg annak ellenére, hogy minden ellenőrzés zöld.

Ebben a sorrendben ellenőrizz:

Milyen munka fut az ellenőrzések hatókörén kívül — háttérfolyamatok, különálló szkriptek, ütemezett feladatok, üzenetsor-kezelők.

Ki hívja meg az egyes új függvényeket. Keresd meg a hívást a projektben; mutasd meg a fájlt és a sort.

Fordított irányok: visszatérítés, letiltás, hozzáférés visszavonása, lejárat, az adatforrás törlése.

Az eredményben szereplő értékek, nem csupán az, hogy létezik-e.

Ha a becsületes keresés nem tár fel hiányosságot, mondd ki, de pontosan írd le, mit és hogyan ellenőriztél.

A amikor egy ügynök ciklusban ellenőrzi önmagát című cikk elmagyarázza, hogyan működik az a ciklus, amelyben az ügynök az iterációk között ellenőrzi önmagát, és hol szokott elbukni.

Mi változik, ha újrafogalmazod a kritériumot?#

Ez a legolcsóbb fejlesztés, amit ismerek, és szinte senki sem alkalmazza.

Kérd meg az ügynököt, hogy végezzen kódellenőrzést — a kód felől fog gondolkodni: struktúra, hibakezelés, újrapróbálkozások, sérülékeny területek. Hasznos.

Kérd meg, hogy járja végig az ügyfél útját a webhely első meglátogatásától a visszatérítés megkísérléséig, és másféle hibák bukkannak elő. Egy hiba, amely olyasmit mutat a felhasználónak, amit nem kellene látnia. Egy e-mail, amelynek szövege nem egyezik a tényleges eseményekkel. Egy lépés, amelyet logikailag lehetetlen teljesíteni, ha nem az ideális forgatókönyv szerint jutottál oda.

A kódellenőrzés egyiket sem fogja megtalálni, mert mindegyik szabályos a kódban.

Ez vezet ahhoz a szabályhoz, amelyet észben tartok: ha az ellenőrzés nem talál semmit, először a megfogalmazást változtasd meg. Általában nem a modell a probléma. Ugyanaz a munka, három különböző módon feltéve, három különböző listát eredményez a megállapításokról. A programozni nem tudóknak szóló gyakorlati kérdésgyűjteményt külön állítottuk össze: hét kódellenőrzés programozási ismeretek nélkül.

Kész prompt az ügynök munkájának átvételéhez#

Ne válaszold azt, hogy „kész” vagy „ellenőrizve”. Bizonyítékra van szükségem.

Minden munkatételről pontosan ezt add meg:

Milyen parancsot futtattál annak igazolására, hogy a tétel működik? Add meg magát a parancsot és a teljes kimenetét, rövidítés nélkül.

Ha nem futtattad a parancsot, mondd ezt: „nem futtattam le”. Ne helyettesítsd azzal, hogy „vizuálisan ellenőriztem” vagy „a logika helyes”.

Milyen munka fut az ellenőrzésed hatókörén kívül? Háttérfolyamatok, különálló szkriptek, ütemezett feladatok, üzenetsor-kezelők — bármi, ami a fő alkalmazástól eltérő módon indul. Mindegyiknél: külön futtattad-e, és mi volt a kimenete?

Ki hívja meg az általad hozzáadott új függvényeket? Keresd meg a hívást a projektben, és mutasd meg a fájlt és a sort. Ha nincs hívás, mondd ki egyértelműen.

Ezután külön részben sorolj fel három módot, ahogyan az állított eredmény NEM valósulhatott meg annak ellenére, hogy minden ellenőrzésed zöld. Keress alaposan.

A végén egy sorban: mit kell a saját szememmel ellenőriznem, mert az automatizált ellenőrzés nem veszi észre?

A negyedik pont apróságnak tűnik, de egy egész problémakört képes elcsípni. Egy nagy feladatban, amelyet területenként osztottam szét az ügynökök között, a százból az egyetlen téves „kész” éppen két terület határán volt: a kód elkészült, az ellenőrzések zöldek voltak, de senkinek nem jutott eszébe megjeleníteni a képernyőn.

Négy mód, ahogyan becsaphatod magad egy ellenőrzéssel#

1. Nem vártam meg az összes felülvizsgálót. Három párhuzamos ellenőrzést indítottam, kettő zöld eredménnyel tért vissza, én pedig telepítettem. A harmadik négy perccel később érkezett, hat szabálysértéssel. Megjelenés után javítani többe kerül, mint két percet várni.
2. Megbíztam a „N-ből N feldolgozva” összefoglalóban. Nagy feladatkiosztásnál egyes ügynökök észrevétlenül hibáznak: sikert jelentenek, de a fájlhoz nem nyúltak. Mostantól minden ügynökön keresztüli írás után mechanikusan ellenőrzöm, hogy a módosítások valóban a lemezre kerültek-e.
3. Nem néztem meg a saját szememmel. Az automatizált ellenőrzések teljesen használhatatlan eredmény esetén is lehetnek zöldek. A képek technikailag helyesek, a méretük helyes, a válaszkód helyes. Valójában azonban automatikusan rögzített képkockák kerültek az illusztrált borítók helyére. Ezt semmilyen automatizált ellenőrzés nem fogja észrevenni.
4. Jelenlétet ellenőriztem érték helyett. Az ellenőrzés megkereste az eredményben a szükséges szöveget; a szöveg ott volt, de a benne szereplő adat hibás volt: a dátum egy nappal eltért. Az ellenőrzés zöld lett, a jelentés pedig hazudott. Most már a teljes elvárt értéket ellenőrzöm, mert a megfelelő szó puszta jelenléte önmagában semmit nem garantál.

Mind a négyben közös, hogy volt ellenőrzés, meggyőzőnek látszott, de rossz dolgot vizsgált. Ugyanaz a mechanizmus, mint a modelleknél és a tesztjüknél, csak éppen találékonyság nélkül.

Mivel kezdj még ma?#

Három lépés, húsz perc alatt.

1. Vedd elő a legutóbbi „kész” feladatot. Futtasd végig a bizonyítékokról szóló rész átvételi promptján. Egyszerű a cél: lásd, hány tételt zártak le szavakkal, és hányat parancskimenettel.
2. Állíts fel magadnak egy szabályt. A csatolt parancskimenet nélküli „ellenőriztem” nem számít lezárásnak. Ez a szabály neked szól, nem az ügynöknek — ezért működik.
3. Válaszd külön a munkát végzőt és a felülvizsgálót. A következő feladatnál add oda egy friss munkamenetnek a felülvizsgálói promptot, és kérd meg, hogy bizonyítsa be: a munka NEM készült el. Az első futtatás rendszerint már megtérülővé teszi ezt a szokást.

Az eszköz jó, és minden hónapban fejlődik: amit az ügynök egy évvel ezelőtt észrevétlenül tett meg, az ma már megállítja. A biztonsági határ folyamatosan mozog, de határ marad. Amíg az ügynök a kapott célt követi, az „és ezt pontosan hogyan mérted?” kérdés a te feladatod marad. Az ellenőrzés szokása a biztonsági hálód.