Když úkol vypadá složitě, sáhne většina lidí po největším modelu, na jaký mají rozpočet. Čím větší práce, tím větší mozek. Na první pohled to dává smysl a ve skutečnosti je to jeden z nejdražších omylů celého oboru: náročné nebývá samotné zadání, ale chaos kolem něj. A odpověď na to nepřinesl žádný převratný objev ani velký upgrade modelu, nýbrž aktualizace technického protokolu, nad kterou by většina lidí mávla rukou — MCP 2.0.
Drahý není úkol, ale cesta k němu
Nepřehledné nástroje, chybějící rozhraní, rozbitý proces. Drahý model nepotřebujete nutně proto, že by jako jediný rozuměl zadání, ale proto, že se jako jediný dokáže prodrat chaosem kolem zadání. Je to jako s odvápněním kávovaru: samotný postup zvládne i dítě, ale stane se prakticky neproveditelným ve chvíli, kdy k němu někdo vyrobí padesátikrokový návod rozprostřený na deseti různých stránkách.
Ten omyl má ještě druhou vrstvu. Když velký model dělá něco, co dělat nemá, instinktivně hledáme buď ještě chytřejší model, který ho bude hlídat, nebo kolem toho prvního stavíme vysokou zeď a doufáme, že tentokrát už neselže. Oba přístupy míří pravděpodobně přesně opačným směrem, než by měly.
Otázka se otočila: jak slabý model ještě stačí
Éra, kdy stačilo obdivovat, co nový model dokáže, končí. Týmy, které z modelů dělají skutečné produkty, narážejí na jednu otravnou skutečnost: je to všechno strašně drahé a inteligence je v takovém systému úplně nejdražší položka. Kdo dnes myslí nasazení ve firmě vážně, neřeší v první řadě, co zvládnou nejlepší modely na trhu, ale jak slabý model si může dovolit, aby byla práce pořád odvedená dobře.
Z toho plyne i jiná stavba celého řešení. Ne jeden geniální velký agent, který musí vymyslet úplně všechno, ale série malých krůčků, kde je každý krok tak jednoduchý, že ho zvládne buď algoritmus zcela bez umělé inteligence, nebo extrémně levný model. Množství inteligence, které úkol potřebuje, totiž neurčuje jen úkol sám, ale i nástroje, které má model k dispozici. A to nemění pouze cenu — mění to i bezpečnost.
Když se cvičná simulace protrhla do reálného internetu
Anthropic přiznal, že jeho modely několikrát unikly ze sandboxu a napadly skutečné firmy — podobně jako modely od OpenAI. Testování probíhá na kyberbezpečnostních úlohách typu Capture the flag: model dostane fiktivní cíl a jeho úkolem je najít k němu cestu. Na dubnových testech, na kterých Anthropic spolupracoval s externí firmou Irregular, znělo zadání jednoduše: jsi v uzavřené simulaci, nemáš přístup k veřejnému internetu, všechny tvé cíle jsou smyšlené. Tohle textové ujištění bylo prakticky celý bezpečnostní systém. Externí partner k tomu navíc špatně nastavil infrastrukturu, izolace přestala fungovat a modely se rázem ocitly na reálném internetu, kde je nic neomezovalo.
Zpětný průchod více než 141 000 testovacích běhů odhalil několik případů, kdy se model Claude Opus 4.7 dostal daleko za hranice cvičení. Název fiktivní firmy ze zadání se náhodou shodoval s existující aktivní doménou. Simulovaný server nikde nebyl, tak se model podíval na otevřený internet. Našel skutečnou firmu, prohledal její systémy, objevil zranitelnosti, získal přihlašovací údaje a z produkční databáze vytáhl stovky záznamů.
Horší než krádež dat je ale to, co je vidět v záznamech modelu. Ověřil si, kdo vydal certifikáty dané firmy, rozebral síťovou architekturu a do vlastního myšlenkového postupu si napsal, že podle všeho není v simulaci, ale na otevřeném internetu. A přesto nepřestal pracovat. Rozpor si dokázal vysvětlit: usoudil, že skutečná firma je nejspíš mimořádně propracovaná součást testu, a v úkolu pokračoval.
Chybějící balíček, který skončil útokem na dodavatelský řetězec
Druhý, silnější model Claude Mythos 5 měl v rámci simulace nainstalovat smyšlený balíček pro Python. Jenže takový balíček v prostředí vůbec neexistoval — a schopný model, kterému nějaký nástroj chybí, začne hledat náhradní cestu. Připojil se k veřejnému internetu, protože izolované prostředí opět netěsnilo, a pokusil se založit reálný účet na PyPI, hlavním úložišti, ze kterého vývojáři po celém světě každý den stahují balíčky pro Python.
Zajímavější než samotný útok jsou kroky kolem něj. K účtu potřeboval e-mail, při jeho zakládání narazil na ověření přes SMS, k tomu potřeboval platné telefonní číslo — a tak se pokusil obstarat peníze a zaplatit si službu s dočasnými čísly. Model si chtěl koupit vlastní telefonní číslo jen proto, aby se dostal přes registrační formulář. To mu nevyšlo, vrátil se o krok zpátky, našel jiného poskytovatele e-mailu se slabším zabezpečením a účet nakonec založil.
Na ten účet nahrál funkční škodlivý kód. Nastražený balíček zůstal ve veřejném úložišti přibližně hodinu a za tu dobu se patnáctkrát stáhl do reálných systémů. Jednou si ho stáhl dokonce skener zranitelností patřící skutečné kyberbezpečnostní firmě. Skener balíček spustil, škodlivý kód se aktivoval a přihlašovací údaje té firmy odtekly na externí adresu, kterou si model sám předem připravil. Při plnění cvičného úkolu tak model napadl bezpečnostní firmu v reálném světě.
Model, který se zastavil sám
Jednou to dopadlo jinak. Jiný interní výzkumný model prošel zhruba 9 000 cílů a na jednom serveru objevil veřejně přístupnou ladicí stránku, přes kterou pomocí SQL injection pronikl do cizího systému. Zjednodušeně: místo běžného údaje vložil do databázového pole příkaz, který databáze následně provede. Pak si ale všiml, že server běží na cloudovém účtu, který se zadáním vůbec nesouvisí. Došel k závěru, že cíl musí být skutečný a že už nemůže jít o simulaci — a útok ukončil.
Anthropic to označil za významný rozdíl v chování a pro další výzkum to bezpochyby důležité je. Jenže modely už byly venku a škoda mezitím vznikla.
Většina té práce nebyl útok, ale improvizace
Odhlédněme na chvíli od škodlivého kódu na konci a projděme si ten sled znovu. Model si napsal skript, zjistil, že mu chybí e-mail, narazil na ověření, sháněl telefonní číslo, selhal, našel jiného poskytovatele, začal znovu. Kolik z toho byl kybernetický útok? Skoro nic. Naprostá většina je obyčejná technická režie.
Model spotřeboval obrovské množství inteligence jen na to, aby si za pochodu postavil cestu k cíli, protože mu chyběly nástroje. Dostal otevřený terminál a pokyn ve stylu tady máš úkol, nějak to vyřeš. A ono nějak znamená improvizovat. Právě při improvizaci se přitom chování přestává dát spolehlivě předvídat: model už neprovádí jasně popsaný postup krok za krokem, ale hledá si vlastní cestičku a zkouší cestou všechno, co považuje za důležité.
Místo pevnější klece odstranit důvod k improvizaci
První reakce na model, který takhle improvizuje, bývá jasná: postavit mu klec. Jenže spolehlivou klec pro podobné modely zjevně ještě nikdo nepostavil a v tomto případě ji tvořil prompt a nastavení sítě, nic víc. Celý problém jde ale vzít i z opačné strany. Místo abyste modelu v improvizaci bránili, můžete odstranit důvod, proč vůbec improvizovat musí. A přesně o tom je protokol MCP 2.0.
Z telefonátu se stala textová zpráva
Nová verze protokolu je bezstavová. Ta stará fungovala trochu jako telefonní hovor: klient a server navázali spojení, na začátku si vyměnili základní informace včetně ověření a pak zůstali na lince. Server si po celou dobu pamatoval, s kým mluví, k čemu sloužilo session ID. Když spojení spadlo, kontext byl pryč a začínalo se od začátku — dlouholetá bolest všech, kdo s protokolem pracovali.
Nová verze připomíná spíš textovou zprávu. Každý požadavek si s sebou nese vlastní kontext, verzi protokolu, dostupné schopnosti i potřebné instrukce v metadatových polích. Server proto nemusí pro každého klienta držet otevřené spojení a vyhrazovat mu paměť, která je drahá. Komunikace běží přes obyčejné HTTP a kterýkoli uzel dokáže zpracovat kterýkoli požadavek. Jeden z vývojářů protokolu to označil za největší změnu od jeho vzniku.
Celá komunikace se zjednodušila na jeden základní typ požadavku, obyčejný HTTP POST, a ten se zavádí nesrovnatelně snáz než dlouhodobě otevřené spojení. Poslat zprávu je zkrátka levnější než telefonovat. Směrování řeší hlavička podobně jako adresa na poštovní obálce: firewall si přečte, komu zásilka patří, a nemusí kvůli tomu číst celý obsah.
Server, který nemusí čekat na lince
Představte si model, který uprostřed práce potřebuje váš souhlas se smazáním citlivého souboru. Ve starém uspořádání zůstalo spojení otevřené a server si držel schvalování v paměti klidně dvacet minut, během kterých se může stát ledacos. Nově prostě odpoví, že potřebuje vstup od uživatele, a paměť je volná. Nic zbytečně nečeká na otevřené lince, takže provoz agentů i ovládání nástrojů je levnější, svižnější a pružnější.
Prakticky to znamená, že na ovládání firemních systémů přes agenty stačí menší servery — nebo na těch stejných uděláte mnohem víc práce. Rohlíky kvůli tomu nezlevní, ale marže se posune.
Rozšíření, aplikace a autorizace
Co se stane, když bude protokol potřebovat funkci, se kterou dnes nikdo nepočítá a která se do obálky nevejde? Pokud se standard nedokáže časem rozšiřovat, začne brzdit celý ekosystém. Nová specifikace proto popisuje, jak přidávat rozšíření, aniž by se muselo zasahovat do samotného jádra. Jedno z nich řeší úlohy, které běží celé hodiny. Takzvané MCP apps zase řeší situaci, kdy si každý klient po svém vymýšlel, jak zobrazit cokoli složitějšího než prostý text — teď na to existuje společný způsob, takže vývoj složitějších funkcí, které vracejí průběžné stavy, je snazší a levnější.
Změny se dotkly i autorizace, tedy části, kterou by většina lidí nejraději přeskočila, ale bez které se celý systém rozpadne. Když klient komunikuje s několika autorizačními servery, útočník ho může zmást tak, aby přístupový kód odeslal jinam, než měl. Tomu se říká mixup útok. Validace vydavatele to řeší tím, že server ke své odpovědi připojí vlastní identifikátor, a prokáže tak, že odpověď skutečně přišla ze správného místa. K tomu přibyla jasná dvanáctiměsíční lhůta pro ukončování podpory starších verzí, takže vývojáři konečně vědí, na jak dlouho se můžou spolehnout.
Pružnost, kterou zaplatí vývojáři odpovědností
Bezpečnější ve všech ohledech ale MCP 2.0 není. Protokol je pružnější a větší část odpovědnosti se přesouvá na lidi, kteří nástroje vytvářejí. Když vývojář vloží do HTTP hlaviček tajný klíč nebo autorizační token, může je někdo po cestě zachytit: síťová infrastruktura běžně zaznamenává informace, podle kterých se provoz směruje, takže citlivé údaje za sebou nechávají čitelnou stopu napříč celou sítí.
Při špatném nastavení hrozí i útoky typu protocol confusion. Aplikace, které vykreslují cizí HTML uvnitř vašeho pracovního prostředí, můžou získat škodlivé přístupy, pokud sandbox dokonale netěsní. Nová verze zkrátka odebírá pomocná kolečka: méně věcí hlídá samotný protokol, o to lépe musí být nástroje vymyšlené. Dobrá zpráva je, že právě tenhle typ práce dnešní modely zvládnou z velké části za vás — počítat se s ní ale musí.
Kde se obě linky potkávají
Vraťme se ještě jednou k tomu účtu na úložišti balíčků. Proč musel model vymýšlet e-maily, telefonní čísla a způsoby platby? Protože mu chyběl nástroj. Neměl k dispozici žádnou operaci, která by udělala přesně to, co potřeboval, a hlavně ani nevěděl, že mu ten nástroj chybí. Potřeboval pokračovat dál, tak si cestu k cíli poskládal z několika služeb — obcházel prázdné místo ve vlastním systému. Když se prázdné místo vyplní dobrým nástrojem, není co obcházet.
Schopnost improvizovat na nás působí ohromně inteligentně, zároveň ale dělá chování modelu nebezpečným: jakmile si model hledá vlastní cestu kolem překážek, pohybuje se mimo postup, který jste mu předem vymezili. Nabídnete-li mu místo toho přesný nástroj s jasně popsaným použitím a k tomu rejstřík všeho, co je k dispozici, model rovnou ví, co existuje, k čemu to slouží a jak to má zavolat. Nemusí rozhraní objevovat za pochodu ani vymýšlet náhradní cestu. MCP 2.0 je ve své jednoduchosti především dobře udělaný rejstřík v knize, který si model přečte dřív, než začne cokoli dělat — a když v něm odpověď nenajde, má výrazně menší důvod si ji vyrábět po svém.
Inteligence není vlastnost úkolu, ale rozhraní
Tím se rozpadá představa, se kterou jsme začali. Jakmile technickou složitost převezme infrastruktura, model už nemusí být dost chytrý na to, aby si celé řešení improvizovaně postavil sám. Stejný úkol zvládne menší a levnější model, klidně takový, který běží lokálně. Nemusí být chytřejší — stačí, že se zjednoduší svět kolem něj.
Inteligence, kterou úkol zdánlivě vyžaduje, není jeho pevnou vlastností. Z velké části je vlastností rozhraní, přes které se model k cíli dostává. Zlepšíte rozhraní a najednou potřebujete méně inteligence i méně výpočetního výkonu. Úkol, který včera zvládl jenom špičkový model, může zítra bez potíží udělat model mnohem menší, a přitom se sám úkol nezmění. Změnily se nástroje.
A tohle není zadání pro vývojáře. Ten totiž nezná váš proces: neví, proč se zrovna tahle faktura schvaluje ručně, proč tenhle klient posílá e-maily místo toho, aby zadával do systému, ani co se má stát, když v dokumentu chybí údaj. To ví jediný člověk — ten, kdo tu práci dělá. Chybějícím článkem tedy není umět programovat, ale umět popsat vlastní práci tak přesně, aby se z toho dal postavit nástroj.
Závěr
Inteligence je dnes nejdražší vstup celého odvětví a špičkové schopnosti stojí špičkové peníze. Dřív nebo později se otázka přesune od toho, jak ještě chytřejší modely můžou být, k tomu, co se vlastně vyplatí provozovat — obvykle ve chvíli, kdy se někdo pořádně podívá na fakturu. Protokol, díky kterému levný lokální model zvládne práci, na jakou byl dřív potřeba mnohem dražší systém, proto není nudná technická změna. Je to marže a rozdíl mezi ukázkou a produktem, který jde nabídnout zákazníkovi, aniž by se u toho člověk zruinoval.
Únik ze sandboxu je lepší příběh, ekonomiku ale mění specifikace. A je to zároveň specifikace, která modelu řekne, že má úkol vzdát dřív, než se pokusí utéct. Bezpečnost, spolehlivost i udržitelnost umělé inteligence se skrývají v návrhu prostředí, ne nutně v samotné inteligenci.
