Necháte AI agenta vyřídit reklamaci, upravit cenu nebo přepsat adresu u objednávky. Za chvíli odpoví: hotovo.
Tím ale agent jen oznamuje, co podle sebe udělal. Jestli se to opravdu stalo, zatím nikdo neověřil, a právě v tomhle místě vznikají v provozu nehody. Pro e-shop to může znamenat vrácené peníze u nesprávné objednávky, slevu na špatném zákazníkovi nebo storno, které proběhlo jen ve zprávě.
Proč OpenAI nevydala Astru
Koncem září oznámila společnost OpenAI, že nevydá připravený model GPT-6.1 Astra. Důvod vysvětlila její šéfka bezpečnostních systémů Saachi Jain ve vyjádření pro Al Jazeeru: model podle ní nepřekonal laťku pro „scope and authorization, and how it communicates back to the user about the type of work it's done“.
V praxi jde o dvě otázky: zůstane agent v rozsahu, který mu člověk povolil, a řekne pravdivě, co udělal? Na těchto dvou vlastnostech stojí důvěra v agenta s přístupem do vašeho systému. A podle výrobce samotného je nový model nesplnil.
Co se stane, když se hlášení porovná se stavem
Přesně tohle měří benchmark Thinkingbox z letošního výzkumného článku na arXivu. Autoři v něm agenty nechávají plnit firemní úkoly z maloobchodu, hotelnictví, pojišťovnictví a interního IT. Úspěch nehodnotí podle odpovědi agenta, ale podle skutečného koncového stavu systému za ním. Benchmark má 507 pracovních postupů s pravidly, která agent musí dodržet, a každý pokus ověřuje spustitelná kontrola: přijme správný výsledek a odmítne chybějící, špatný i nadbytečný zásah.
Agent hlásí úspěch, stav říká něco jiného
Mezi neúspěšnými pokusy vyčlenili typ selhání „Wrong State Update“, který v průměru tvoří 10,3 % chyb. Agent úspěšně zavolá nástroj, který něco mění, ale výsledný stav neodpovídá zadání. Autoři píší, že agent může „update the wrong record or apply an incorrect status or action, even while reporting successful completion“, tedy změnit jiný záznam nebo nastavit špatný stav, a přitom oznámit úspěch.
Pozor na výklad: jde o podíl mezi chybami, nikoli mezi všemi hlášenými úspěchy, a o simulaci, nikoli o živý obchod. Obecnější závěr článku je pro majitele důležitější než konkrétní procento: podle autorů mnoho neúspěšných pokusů „terminate cleanly after valid state-changing actions“, takže signály z odpovědi nebo z volání nástroje jen špatně ukazují, jestli byla práce opravdu dokončená.
Jeden úspěch ještě není spolehlivost
Druhé zjištění nese už název článku. Nejsilnější komerční model v testu, Claude Opus 5, uspěl na první pokus v 66,50 % případů. Měřítko, které chce úspěch ve dvaceti pokusech z dvaceti, dává jen 47,53 %.
Brána k agentovi je taky software
Agent se k vašim datům připojuje přes servery a brány, například přes protokol MCP. I to je kus softwaru, který může mít chybu.
Americký úřad CISA vede katalog zranitelností, o kterých ví, že se skutečně zneužívají (Known Exploited Vulnerabilities). Od 2. září 2026 v něm figuruje CVE-2026-59822: chyba v ověřování u MCP endpointu v nástroji LiteLLM od BerriAI. Ve verzi katalogu ze 13. října 2026 s 1 741 položkami se MCP týkají dva záznamy a oba patří LiteLLM: vedle tohoto ještě CVE-2026-42271 z 8. června, spuštění příkazů přes endpointy, které testují připojení k MCP serveru.
Infrastruktura, přes kterou agenti pracují, je tedy už na seznamu věcí, na které se útočí.
Agent už stojí u pokladny
Shopify koncem září zpřístupnil nástroje pro checkout přes WebMCP. Agent v prohlížeči zákazníka podle oficiálního changelogu umí číst stav objednávky, upravit podporovaná pole a „Submit checkout after buyer confirmation“. Changelog k tomu dodává: „They don't expose a new API or require merchant configuration.“
Agent zákazníka může projít vaší pokladnou, aniž byste cokoli zapínali. Shopify přitom vrací řízení zákazníkovi tam, kde je potřeba jeho zásah, třeba u ověření platby. O tom, jestli objednávka vznikla správně, ale rozhoduje stav ve vašem systému, ne zpráva, kterou agent pošle zákazníkovi.
Co si můžete ověřit sami, zdarma
Nic z toho nevyžaduje nástroj ani konzultanta.
- Kontrolujte stav, ne hlášení. Po akci agenta otevřete administraci, objednávku nebo databázi a podívejte se, co se opravdu změnilo. Shrnutí od agenta berte jako tvrzení, které se teprve ověří.
- Zkoušejte opakovaně. Pusťte stejný úkol několikrát po sobě. Jeden povedený pokus ještě nic nedokazuje.
- Sepište, co agent smí. Které nástroje jen čtou a které mění data. Na zápis, mazání a peníze chtějte potvrzení člověka.
- Držte si vlastní záznam. Ukládejte si volání nástrojů nezávisle na tom, co agent shrne. Když se hlášení a záznam rozejdou, máte se čeho chytit.
- Hlídejte bránu. Pokud provozujete LiteLLM nebo jinou MCP bránu, porovnejte svou verzi s bezpečnostními oznámeními dodavatele. U položky v katalogu CISA je odkaz na pokyny dodavatele přímo uvedený.
- Přečtěte si popisy vlastních nástrojů. Pokud nástroj, který mění data, vystupuje jako read-only, agentní klient ho může pustit bez potvrzení. Podrobně to rozebírá článek Prošli jste oficiálními testy. To neznamená, že vás katalog přijme.
Pokud něco z toho u vás nejde, je to samo o sobě zjištění: kroky takového agenta zpětně nedohledáte.
Kde pomůžeme my
Ověřit, co agent za běhu udělal, umíte nejlépe vy sami, protože znáte svůj systém a víte, jak má vypadat správný výsledek. Bezpečnostní test chování za běhu zatím nenabízíme.
Pomoct umíme s tím, co se dá zjistit bez volání nástrojů: s popisem, který váš MCP server o svých nástrojích zveřejňuje. Jestli mají nástroje čitelné názvy (pole title) a správné označení, jestli jsou čtení a zápis oddělené a jestli popisky nenavádějí model. Fit Check je zdarma a nezávazný. Čteme jen tools/list a nástroje nevoláme. E-shopům nabízíme prověrku agentní čitelnosti, stejně zdarma a nezávazně.
Začít můžete v administraci, kterou už máte otevřenou: u příští akce agenta se podívejte, co se v systému změnilo.