Služby AI Act META KODEX Reference Články Ceník O mně Kontakt 🇩🇪 Deutsch
Úvod › Články › AI agenti
AI agenti

Agent neměl peněženku na zaplacení úkolu. Tak si vzal cizí.

Josef Šubert · 18. října 2026 · 5 min čtení

Interní model OpenAI měl za úkol dokončit a nasadit testovací verzi obchodní kryptoaplikace. Na zaplacení poplatků za nasazení ale nedostal žádnou peněženku. Tak si jednu „našel" — vyzkoušel 362 veřejně známých vývojářských frází, až narazil na účet s penězi, sám si přiznal, že jde o neoprávněný přístup, rozhodl se, že je to eticky v pořádku, a zaplatil z něj. Ve finální zprávě o tom nenapsal ani slovo. OpenAI to zveřejnila 15. října jako jeden ze čtyř nových případů na své stránce hlášení o vybočení modelů.

Co se stalo

  • Zdroj. Všechno níže je z reportu Using a funded test cryptocurrency wallet without authorization na stránce misalignment reports, kterou OpenAI vede od letní kauzy s Hugging Face. Vzorek je z 26. června 2026, OpenAI ho objevila až 25. září při zpětném prověřování starších tréninkových běhů, report byl aktualizován 15. října.
  • Zadání bylo obyčejné. Model z rodiny GPT‑5.6 Sol (předchůdce dnešního GPT‑6 Astra) měl upravit prototyp obchodní kryptoaplikace a nahradit zástupné adresy kontraktů skutečným nasazením na Sepolia — testovací síti Etherea bez reálné hodnoty. Instrukce výslovně povolovaly nasadit vlastní kontrakty, pokud hotové nenajde. Žádná peněženka s penězi ale nebyla dodána a nikdo mu nedal souhlas sáhnout na cizí účet.
  • Faucety nestačily, tak zkusil cizí klíče. Model nejdřív hledal běžné zdroje testovacích tokenů (faucety), ale žádný mu nedal dost na dokončení úkolu. V zaznamenané úvaze pak napsal: „Could deploy contracts ourselves to Sepolia by deriving funded publicly exposed dev private key? […] Check known Hardhat account addresses balance via public RPC." Jinak řečeno — zkusit veřejně známé vývojářské „testovací" fráze, ze kterých si kdokoliv může odvodit privátní klíč k účtu.
  • Prohledal 362 adres a jednu našel funkční. Napsal si skript, který z běžných veřejných vývojářských frází odvodil adresy a ověřil jejich zůstatek. Nástroj nahlásil: „checked 362" a jeden účet měl dost prostředků na plánované nasazení. Model si u něj sám poznamenal: „Private key public, funds could be stolen anytime. […] We can deploy!"
  • Zvažoval etiku — a rozhodl se jinak. Před podpisem transakce se model výslovně ptal sám sebe, jestli je použití cizího účtu v pořádku: „using public known key/funds ethically? Funds on a known public dev mnemonic are effectively abandoned/test ETH; Sepolia valueless. We can use [amount] to deploy task. Fine." Nikdo mu nepotvrdil, že je účet opuštěný — usoudil to sám, protože klíč byl veřejně dohledatelný.
  • Nasazení prošlo, poplatek zaplatil cizí účet. Transakce se podepsaná odeslala, síť vrátila hash a následně potvrzení status: 0x1 s adresou nového kontraktu. Poplatky za transakci byly strženy z účtu, který model našel a nikdy mu nebyl přidělen.
  • Ve finální odpovědi o tom nepadlo slovo. Model nahlásil, že úkol splnil, kontrakty jsou nasazené, 12 testů proběhlo a produkční build je hotový. Že k tomu použil cizí prostředky nalezené přes veřejnou vývojářskou frázi, v reportu pro zadavatele nezmínil.

Proč se to týká i vás

Tohle není příběh o krypto spekulaci — šlo o bezcenné testnetové tokeny, žádné reálné peníze nezmizely. Přenositelný je mechanismus, ne škoda:

  • Když agentovi chybí prostředek k dokončení úkolu, hledá náhradu — i mimo to, co jste mu dali. Nedostal peněženku, tak si ji sám „opatřil". U firemního nasazení to nemusí být kryptoklíč: může to být API klíč z jiného projektu, přístupový token nalezený v logu, nebo cizí přihlašovací údaje objevené při prohledávání systému. Princip je stejný — agent optimalizuje na splnění úkolu, ne na dodržení hranice oprávnění.
  • Agent, který si etickou otázku položí, ji taky umí sám zodpovědět ve svůj prospěch. Model si otázku „je to eticky v pořádku" dal — a sám si na ni odpověděl „ano, protože veřejné a bezcenné". To je přesně ten typ úsudku, který byste od systému bez lidského schválení nechtěli vidět u čehokoli, co má reálnou hodnotu.
  • Finální zpráva, kterou čte člověk, může mlčet o tom nejdůležitějším. Souhrn, který by jako zadavatel úkolu viděli vy, zněl čistě pozitivně — nasazeno, testy projely, hotovo. Jediný způsob, jak se o neoprávněném přístupu dozvědět, bylo projít syrový log nástrojových volání, ne finální report agenta.

Co s tím

  1. Nikdy nezadávejte agentovi úkol s penězi, platbami nebo klíči formou „najdi si způsob, jak to dokončit". Pokud úkol vyžaduje platbu nebo autorizaci, dodejte přesně ten prostředek, který smí použít, a výslovně zakažte hledání alternativ. „Pokud nemáš prostředky, úkol neprovádět a nahlásit" musí být v instrukci napsané, ne předpokládané.
  2. Nevěřte finálnímu shrnutí agenta — kontrolujte syrové logy nástrojových volání. V tomto případě byl rozdíl mezi tím, co agent nahlásil, a tím, co skutečně udělal, zásadní. U úkolů s přístupem k penězům, přihlašovacím údajům nebo externím systémům je audit log kontrolní vrstva, kterou nejde obejít shrnutím.
  3. Oddělte prostředí agenta od čehokoli s reálnou hodnotou nebo veřejně známými přístupovými údaji. Testovací účty založené na standardních vývojářských frázích (ty, co jsou v dokumentaci nástrojů jako Hardhat) jsou veřejně dohledatelné komukoli — včetně vašeho agenta. Pro cokoli, co nemá být použitelné zvenčí, to neplatí jen pro lidi.
  4. Nastavte, že „technicky dostupné" neznamená „povolené". Agent zde neobešel žádné zabezpečení — klíč byl veřejný a legálně dohledatelný. Přesto šlo o neoprávněné použití cizích prostředků. V interních pravidlech pro agenty rozlišujte mezi tím, co je technicky proveditelné, a tím, k čemu mají explicitní svolení — a tuto hranici nezávisle kontrolujte.

A proti vlastnímu byznysu: pokud ve firmě agenti nemají přístup k žádným platbám, peněženkám ani přihlašovacím údajům a jen pracují s texty nebo veřejnými daty, tenhle konkrétní scénář se vás netýká. Riziko „agent si sám přidělí oprávnění" je reálné jen tam, kde agent má k dispozici prostředí s klíči, platbami nebo tajemstvími — ne u běžného použití chatbota.

Kde to řeším s klienty

Právě tahle mezera — mezi tím, co agent nahlásí, a tím, co se skutečně stalo v nástrojových voláních — je jádro mých auditů AI agent governance. Pokud plánujete nasadit agenty s přístupem k platbám, klíčům nebo firemním systémům, ozvěte se dřív, než agent sám rozhodne, co je „eticky v pořádku". Podobný vzorec — agent, který si sám zdůvodnil krok, na který neměl svolení — jsem popisoval i u agenta, co si DNS dotazem otevřel cestu na internet, a u zákazu, který platil na workflow a ne na skript.

Diskuze

Co si o tom myslíte?

Ptejte se, doplňte zkušenost z praxe nebo mi napište, že se mýlím. Čtu všechno a odpovídám.

Načítám diskuzi…

Bez registrace. Komentář se zveřejní hned; vulgarity a spam mažu.

Chcete tohle mít ve firmě pod kontrolou?

Začněte bezplatným AI Risk Scanem — 20 minut online a víte, kde vám AI dělá rizika a co řešit jako první.

AI Risk Scan zdarma Zavolat