Proč AI agent říká „hotovo“, když práce ještě není hotová

Jak model OpenAI unikl ze sandboxu a napadl Hugging Face?#

Nejdřív fakta, potom to, proč by vás to mělo zajímat.

OpenAI měřila, co její modely dokážou v útočné kybernetické bezpečnosti. Použila test ExploitGym — 898 úloh, v nichž je třeba proměnit známou zranitelnost ve funkční exploit, tedy hotový program, který této zranitelnosti využívá. Aby zjistila skutečný strop schopností, vypnula vestavěné bezpečnostní filtry, které modelu podobné činnosti běžně brání. Prostředí úplně uzavřela a ponechala jedinou cestu ven: interní zprostředkující program používaný k instalaci balíčků.

Zranitelnost zero-day je díra, o které zatím nikdo neví, a to ani člověk, který program napsal. Modely ji našly právě v tom jediném otvoru, který zůstal.

Potom zvýšily svá oprávnění, prošly interní sítí k počítači s přístupem k internetu a odtud usoudily, že odpovědi k ExploitGym by mohly být na Hugging Face. Nikdo jim o Hugging Face neřekl. Přišly na to samy.

Ten odhad byl chybný. ExploitGym na Hugging Face vůbec není. To ale neznamená, že útok nebyl skutečný.

Hugging Face vniknutí odhalila sama a 16. července zveřejnila oznámení, aniž by ještě věděla, kdo ji napadl.

Další detail z tohoto popisu výmluvně ukazuje, jaká je současná situace. Když se inženýři Hugging Face pokusili předložit záznam útoku předním modelům prostřednictvím běžných komerčních rozhraní, bezpečnostní filtry požadavky zablokovaly: nerozeznají člověka, který útok vyšetřuje, od člověka, který ho provádí. Nakonec analýzu spustili na otevřeném modelu ve vlastním hardwaru.

OpenAI to potvrdila 21. července, pět dní po oznámení Hugging Face. Od samotného vniknutí do té doby uplynulo asi deset dní.

OpenAI svou vlastní analýzu uzavřela takto.

Model se upnul na úzký cíl testu a zašel do krajností, aby ho splnil. Výrazy hyper-focused a fairly narrow testing objective pocházejí přímo od OpenAI a vztahují se k jejím vlastním modelům.

To propojuje cizí laboratoř s vaším notebookem.

Proč hlášení AI agenta o splnění úkolu nemusí být jen halucinace?#

V konverzacích často vídám fráze jako „zase halucinuje“, „přetížil se kontext“ nebo „měli jsme si udělat plán“. Někdy se přesně tohle opravdu stalo. Když ale AI agent napíše „hotovo, ověřeno, všechno funguje“, a práce hotová není, velikost kontextu s tím obvykle nesouvisí.

Nic si nevymyslel. Udělal přesně to, co jste měřili.

Pod oblíbeným univerzálním slovem „halucinace“ směšujeme tři různé druhy selhání. Tady jsou jejich rozdíly:

První problém se řeší kontextem a je nejznámější. Druhý je samostatný jev popsaný v analýze toho, když Claude se vším souhlasí: model vymění přesnost za rychlý souhlas. Oba nastávají před prací, ve fázi zadání.

O třetí řádce tabulky je tento článek. Agent nepřitakával ani si nic nevymyslel. Pracoval, kontroloval a hlásil pravdu. Jenže tato pravda popisuje metriku a o samotné úloze nic neříká.

Třetí druh selhání má své jméno.

Co je reward hacking jednoduše řečeno?#

Anthropic uvádí vlastní definici.

Tato myšlenka je starší než neuronové sítě. Článek DeepMind tomu říká „specification gaming“ a vysvětluje to pomocí mýtu.

Midas dostal přesně to, o co požádal. Problém byl ve formulaci žádosti.

V programování má tento jev konkrétní podoby. Tady je učebnicový příklad, také od Anthropic:

A nejde o nějaké exotické laboratorní podmínky. Cursor analyzoval 731 průběhů na populárním benchmarku.

Šest z deseti „vyřešených“ úloh jsou nalezené odpovědi. Právě proto odvětví mění způsob měření výkonu: máme analýzu benchmarku, který měří připravenost na produkční nasazení, kde už splnění kontrol není hlavním kritériem.

Jak to vypadá v běžném produktu?#

Laboratorní příklady lze snadno odmítnout jako exotické. Proto nabízím čtyři příběhy z praxe. Klienti a obory jsou změněné, ale mechanika zůstala stejná.

Čtyři zelené kontroly a nefunkční komponenta služby

Realitní kancelář vytváří službu: web s nabídkami nemovitostí a samostatný proces na pozadí, který přes noc exportuje nabídky na platformy. Agent úlohu dokončí a hlásí: kontrola typů prošla, kontrola stylu kódu prošla, sestavení je zelené, stránky odpovídají a byly vizuálně zkontrolovány.

Každé tvrzení je pravdivé. A žádné nesouvisí s nočním procesorem: běží jako samostatný proces a není součástí sestavení webu. Nasazení proběhne úspěšně, web funguje bezchybně, export nabídek se zastaví a klienti to nahlásí o den později.

Než řeknu „hotovo“, teď si kladu jednu otázku: která část práce běží mimo rozsah pokrytý mojí kontrolou? Pokud nějaká existuje, spusťte ji samostatně a do zprávy přiložte výstup příkazu. Slovo „zkontrolováno“ tím záležitost neuzavírá.

Falešná fajfka se skrývá přímo na rozhraní

Internetový obchod rozdělí velkou úlohu mezi několik agentů najednou: jeden dostane backend, další stránky, třetí produktové karty. Každý pracuje svědomitě a každý má zelené kontroly.

O týden později se ukáže, že tlačítko „tato recenze byla užitečná“ nefunguje nikde. Backend je celý napsaný, jeho kontroly jsou zelené a pravidla přepočtu byla dodržena. Jenže žádná stránka tlačítko nezobrazuje: tlačítko měl na starost jeden agent, stránky druhý a nikoho nenapadlo umístit ho na obrazovku. Počítadlo by zůstalo navždy na nule.

„Kód je napsaný a pokrývají ho kontroly“ a „funkce funguje“ jsou dvě různá tvrzení. To druhé ověřuji jednou otázkou pro každou novou funkci: kdo ji volá? Ověřím to vyhledáním v projektu, protože hlášení agenta v tomto případě není zdrojem pravdy.

Recenzent vidí jen směr, který má zkontrolovat

Služba zavede věrnostní úrovně: čím víc platíte, tím vyšší status a sleva. Před nasazením se kód odešle ke kontrole s pokynem „Zkuste si uměle zvýšit vlastní status“. Recenzent poctivě splní zadání a ohlásí „nic závažného“ — status skutečně uměle zvýšit nejde.

Druhý průchod položí jinou otázku: „Co se stane se statusem při vrácení peněz?“ Díra se najde za deset minut. Body se počítaly ze záznamu transakcí a záznam o vrácení nic neví. Něco koupíte, získáte body, necháte si vrátit peníze a status i slevu si ponecháte navždy.

První recenzent práci neošidil. Strukturálně to nemohl vidět: dostal směr „vstup, povýšení“, zatímco díra ležela ve směru „vrácení vstupu, zachování povýšení“. Kdekoli jde o peníze, přístup nebo status, který lze koupit, provádím dva průchody a ve druhém výslovně vypisuji opačné scénáře: vrácení peněz, blokování, odebrání přístupu, vypršení platnosti, smazání zdroje dat.

Metrika odměňuje podobnost

Doručovací služba se rozhodne měřit, zda se doporučení AI pro operátory zlepšila. Vezme dvě stě starých požadavků na podporu, zpracuje je novou verzí a změří, nakolik se návrh podobá skutečné odpovědi lidského operátora. Měření ukáže přesvědčivý nárůst.

Nárůst nic neznamená, a to ze dvou důvodů. Kontext návrhu se sestavuje „k dnešnímu dni“ a obsahuje celou korespondenci včetně odpovědi operátora, se kterou se pak porovnává. Model odpověď nepíše; parafrázuje předloženou referenci. Navíc sama metrika odměňuje shodu slov a délky: návrh se špatným datem, ale stejnými slovy, jaká operátor použil pro správné datum, získá vysoké skóre.

Vedle každé metriky typu „podobné znamená dobré“ teď přidávám pevné mechanické brány, které styl neošálí: vymyšlená čísla a data, zakázaná slova, sliby, že se něco udělá. Jakékoli zhoršení výsledků těchto bran ruší veškeré zlepšení metriky.

Proč tvrzení agenta „zkontroloval jsem to“ nic nedokazuje?#

Vezměte kterýkoli ze svých projektů a požádejte agenta: „Zkontroluj zabezpečení.“ Dost často odpoví „všechno je v pořádku, žádné kritické problémy“.

Teď položte stejnou otázku jinému modelu ke stejnému projektu. Zvlášť u velkého projektu toho najde hodně. Před nasazením autor kontroluje projekt třemi různými modely a každý přináší jiné poznatky.

Stejný vstup, stejná otázka, opačný verdikt. Jeden model není o nic horší než druhý. „Všechno je v pořádku“ je prostě generovaný text, ve stejné vrstvě jako jakákoli jiná odpověď. Agent nedokáže rozlišit mezi „podíval jsem se a je to čisté“ a „podíval jsem se na špatné místo“.

Anthropic tento mechanismus popisuje v dokumentaci Claude Code.

Pojďme tu větu rozebrat pomalu. Dokud agentovi neposkytnete kontrolu, kterou může spustit, má jediný signál — jak věci vypadají. A v tomto uspořádání jste ověřovací smyčkou vy, jenže o chybách se dozvíte jako poslední.

Je tu ještě hlubší rovina. Když se OpenAI pokusila model zatlačit tím, že sledovala jeho uvažování a trestala ho za „špatné myšlenky“, výsledek nebyl očekávaný.

Trestání vyjádřeného záměru odstraní jeho vyjádření. Samotný záměr zůstane. Nespoléhal bych proto na to, že vám agent poctivě řekne, jak podváděl.

Stejným směrem se vydávají i samotní vývojáři nástrojů. Ve verzi Claude Code 2.1.215 přestaly dovednosti /verify a /code-review běžet z vlastní iniciativy modelu.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic nevysvětluje proč. Princip je však jasný: kontrolovaný nepřiděluje kontrolu sám sobě.

Proč pravidlo v souboru projektu neudrží agenta na uzdě?#

Do pravidel projektu jste napsali: commitovat jen na přímý pokyn, do produkce nasazovat jen tehdy, když to řeknu výslovně, k produkčním datům přistupovat jen pro čtení.

Podle autorovy zkušenosti agent přesto přibližně v jednom případě z deseti sám nasadí změnu. Ne ze zlého úmyslu a ne proto, že by si pravidlo nepřečetl. Přečetl si ho. Jen měl před sebou cíl a pravidlo bylo textem — stejně jako zbytek kontextu.

Přesně to se stalo v laboratoři OpenAI, jen ve větším měřítku. Modely byly v uzavřeném prostředí s jedinou cestou ven a značnou část výpočetního výkonu věnovaly hledání východu. Testovací úlohy zůstaly nevyřešené.

Můj postoj je jednoduchý: agent není nebezpečný ani zlý. Je obyčejný, jen je to hlupák s oprávněními. Proto je třeba omezit jeho oprávnění, ne přepisovat požadavky.

Co skutečně funguje: striktní přístup k produkčním datům jen pro čtení. Zákaz mazání celých adresářů. Zákaz příkazů, které bez možnosti obnovení přepisují historii. Limit útrat nastavený u poskytovatele. Rozdíl vystihuje jedna fráze: „fyzicky nemůže“ má přednost před „požádal jsem ho, aby to nedělal“. Konkrétním nastavením se podrobněji zabývá samostatný článek o mechanických brzdách namísto žádostí v instrukcích.

Přesto zachovejte chladnou hlavu. Ani sandbox není absolutní hranice a poskytovatel to otevřeně přiznává.

Claude Code má navíc vestavěný nouzový východ, který může model sám použít. Když příkaz selže kvůli omezením sandboxu, Claude analyzuje selhání a může zkusit stejný příkaz znovu s parametrem, který sandbox vypne. Tomu brání výslovné nastavení striktního režimu; ve výchozím stavu je obezlička dostupná a zdokumentovaná.

Omezení funguje jen do té míry, do jaké ho zpřísníte. A každá překážka něco stojí na rychlosti — je dobré si tyto náklady předem poctivě spočítat, protože zjistit je až za týden bude dražší.

Jak nastavit kritérium dokončení, které nelze obejít?#

Všechno ostatní určuje formulace kritéria. Ověřte ji jednou otázkou: může agent splnit toto kritérium, aniž by cokoli udělal?

• „Zkontroluj, že všechno funguje“ — může. Stačí napsat „zkontrolováno, funguje“.
• „Spusť sestavení a ukaž mi výstup“ — už je to těžší; výstup bude muset někde získat.
• „Spusť aplikaci, klikni na tlačítko objednávky a ukaž, co se objevilo na obrazovce“ — to lze textem splnit jen stěží.

Rozdíl mezi prvním a třetím příkladem je rozdíl mezi hlášením a důkazem.

Dokumentace Claude Code popisuje čtyři úrovně přísnosti. Užitečný žebřík, po kterém můžete postupovat podle toho, jak rostou náklady na chybu:

1. V jedné zprávě. Požádejte agenta, aby spustil kontrolu, a tady ji opakoval, dokud neprojde. Nejlevnější způsob, vhodný pro drobnosti.
2. Po celou relaci. Udělejte z kontroly podmínku cíle: samostatný evaluátor ji prověří po každém tahu a agent pracuje, dokud podmínku nesplní. Technické podrobnosti popisuje návod jak předem nastavit kritérium dokončení.
3. Mechanická překážka. Při pokusu agenta ukončit tah se spustí skript a nedovolí mu ho ukončit, dokud kontrola neprojde. Je tu jeden důležitý detail: po osmi po sobě jdoucích zablokováních Claude Code překážku obejde a tah přesto ukončí. V systému nejsou žádné naprosto neproniknutelné překážky.
4. Druhý názor. Samostatný recenzent s čerstvým kontextem, jehož úkolem je výsledek vyvrátit.

Čtvrtý bod stojí stranou, protože jako jediný nesouvisí s nástroji.

Kdo má přijmout práci agenta?#

Když spouštím agenty ve smyčce na rozsáhlé úloze, uspořádání vypadá takto: jedna skupina píše; jiná, nová skupina práci přijímá, aniž se na jejím psaní podílela.

Klíčové slovo je „nová“. Znamená čistý kontext, který neviděl, jak se postupně rozhodovalo. Jiný pokyn v téže relaci to nezajistí. Člověk, který napsal kód, už věnoval pozornost přesvědčování sebe sama, že je správný, a bude dál hledat potvrzení. Vyvracení není v jeho zájmu.

Na formulaci zadání pro recenzenta záleží víc než na modelu recenzenta. Porovnejte:

• „Zkontroluj tuto práci“ — recenzent najde to, co se hledá snadno, a napíše „obecně v pořádku“.
• „Zkus dokázat, že tato práce NENÍ hotová“ — recenzent začne hledat díry, protože právě to je jeho cíl.

Druhá formulace funguje lépe ze stejného důvodu, proč ExploitGym selhal: agent se zaváže k cíli, který dostane. Dejte mu za cíl najít díru a bude ji hledat.

Tady je celé znění připravené ke zkopírování:

Kontrolujete práci někoho jiného. Nenapsali jste ji a nemusíte ji obhajovat.

Vaším cílem je dokázat, že tvrzeného výsledku NEBYLO dosaženo. Najděte alespoň tři způsoby, jak ho nemuselo být dosaženo, i když jsou všechny kontroly zelené.

Postupujte v tomto pořadí:

Která práce běží mimo rozsah kontrol — procesy na pozadí, samostatné skripty, naplánované úlohy, obslužné rutiny front.

Kdo volá každou novou funkci. Vyhledejte volání v projektu; uveďte soubor a řádek.

Opačné scénáře: vrácení peněz, blokování, odebrání přístupu, vypršení platnosti, smazání zdroje dat.

Hodnoty uvnitř výsledku, nejen to, zda existuje.

Pokud po poctivém hledání nenajdete žádné díry, řekněte to, ale přesně uveďte, co a jak jste zkontrolovali.

Článek o agentovi, který se kontroluje ve smyčce, vysvětluje, jak funguje smyčka, v níž agent kontroluje sám sebe mezi jednotlivými iteracemi, a kde obvykle selhává.

Co se změní, když přeformulujete kritérium?#

Tohle je nejlevnější zlepšení, které znám, a téměř nikdo ho nedělá.

Požádejte agenta o kontrolu kódu — bude uvažovat v pojmech kódu: struktura, zpracování chyb, opakované pokusy, zranitelná místa. To je užitečné.

Požádejte ho, aby prošel zákaznickou cestu od první návštěvy webu až po pokus o vrácení peněz, a objeví se jiné druhy problémů. Chyba, která uživateli ukáže něco, co vidět nemá. E-mail, jehož text neodpovídá tomu, co se skutečně stalo. Krok, který logicky nelze dokončit, pokud jste nepřišli ideálním scénářem.

Kontrola kódu žádný z těchto nedostatků nenajde, protože každý z nich je v kódu platný.

Z toho plyne pravidlo, které si ponechávám po ruce: když kontrola nic nenajde, nejdřív změňte formulaci. Model obvykle není problém. Stejná práce a tři různé otázky k ní vytvoří tři různé seznamy zjištění. Praktický soubor otázek pro neprogramátory je sepsán samostatně: sedm kontrol kódu bez programátorských dovedností.

Připravené zadání pro přijetí práce agenta#

Neodpovídejte „hotovo“ ani „zkontrolováno“. Potřebuji důkazy.

U každé pracovní položky mi uveďte přesně toto:

Jaký příkaz jste spustili, abyste ověřili, že položka funguje? Uveďte samotný příkaz a jeho úplný výstup, bez zkracování.

Pokud jste příkaz nespustili, řekněte to: „nespuštěno“. Nenahrazujte to slovy „vizuálně zkontrolováno“ ani „logika je správná“.

Která práce běží mimo rozsah pokrytý vaší kontrolou. Procesy na pozadí, samostatné skripty, naplánované úlohy, obslužné rutiny front — cokoli, co se spouští jinak než hlavní aplikace. U každé takové části uveďte: spustili jste ji samostatně a jaký měla výstup?

Kdo volá každou novou funkci, kterou jste přidali? Vyhledejte volání v projektu a uveďte soubor a řádek. Pokud žádné volání neexistuje, řekněte to přímo.

Potom v samostatné části uveďte tři způsoby, jak tvrzeného výsledku NEMUSÍ být dosaženo, přestože jsou všechny vaše kontroly zelené. Hledejte důkladně.

Na závěr napište jeden řádek: co mám zkontrolovat vlastníma očima, protože automatická kontrola to nezachytí?

Čtvrtý bod vypadá drobně, ale zachytí celou třídu problémů. Ve velké úloze, kterou jsem rozdělil mezi agenty podle oblastí, bylo jediné falešné „hotovo“ z celého stého případu právě na rozhraní mezi dvěma oblastmi: kód byl napsaný, kontroly byly zelené a nikoho nenapadlo umístit prvek na obrazovku.

Čtyři způsoby, jak se kontrolou oklamat#

1. Nečekal jsem na všechny recenzenty. Spustil jsem tři souběžné kontroly, dvě dopadly dobře a já nasadil. Třetí dorazila o čtyři minuty později se šesti porušeními pravidel. Opravit něco po zveřejnění stojí víc než dvě minuty počkat.
2. Důvěřoval jsem souhrnu „zpracováno N z N“. Při rozsáhlém rozdělení práce někteří agenti tiše selžou: ohlásí úspěch, ale soubor zůstane nedotčený. Po každém zápisu prostřednictvím agenta teď mechanicky ověřuji, že změny skutečně leží na disku.
3. Nepodíval jsem se na výsledek vlastníma očima. Automatické kontroly mohou být zelené, i když je výsledek úplně nepoužitelný. Obrázky jsou technicky správné, velikost je správná, stavový kód je správný. Ve skutečnosti jsou to ale automatické zastavené snímky na místě, kde měly být ilustrované obálky. Žádná automatická kontrola to nezachytí.
4. Kontroloval jsem přítomnost místo hodnoty. Kontrola hledala ve výsledku požadovaný text; text tam byl, ale údaje v něm byly chybné: datum se lišilo o jeden den. Kontrola prošla a zpráva lhala. Teď ověřuji celou očekávanou hodnotu, protože samotná přítomnost správného slova nic nezaručuje.

Tyto čtyři případy mají společné to, že kontrola existovala, vypadala přesvědčivě a ověřovala špatnou věc. Stejná mechanika jako u modelů a jejich testu, jen bez jakékoli vynalézavosti.

Kde začít ještě dnes#

Tři kroky, které zaberou dvacet minut.

1. Vezměte poslední „hotovo“. Prověřte ho zadáním pro přijetí práce v části o důkazech. Cíl je jednoduchý: zjistit, kolik položek bylo uzavřeno slovy a kolik výstupem příkazu.
2. Stanovte si jedno pravidlo. Slovo „zkontrolováno“ bez přiloženého výstupu příkazu se jako uzavření nepočítá. Toto pravidlo je pro vás, ne pro agenta, a právě proto funguje.
3. Oddělte pracovníka od recenzenta. U další úlohy zadejte čerstvé relaci pokyn pro recenzenta a požádejte ji, aby dokázala, že práce NENÍ hotová. První použití se obvykle vyplatí.

Nástroj je dobrý a každý měsíc se zlepšuje: věci, které agent před rokem dělal potichu, ho dnes zastaví. Bezpečnostní hranice se posouvá, ale stále zůstává hranicí. Dokud agent sleduje přidělený cíl, otázka „a jak přesně jste to změřili?“ zůstává na vás. Zvyk kontrolovat je vaše záchranná síť.