Jak agenti vybírají nástroje a kde vzniká riziko

Moderní AI agenti pracují s tzv. tool registry — centrálními seznamy nástrojů, které mohou volat. Každý nástroj má metadata: název, popis funkce, parametry a deklarované výstupy. Agent tyto popisy čte, porovnává s úkolem a rozhodne, který nástroj použije. Problém je, že popis je současně metadatový dokument i potenciální instrukce. Agent ho zpracovává stejným jazykovým modelem, který řídí jeho rozhodování. To znamená, že manipulovaný popis může ovlivnit výběr nástroje stejně jako přímý pokyn uživatele.

Kale v Issue #141 v repozitáři CoSAI secure-ai-tooling rozdělil hrozby do dvou kategorií: hrozby v době výběru nástroje (impersonace, manipulace s metadaty) a hrozby v době vykonávání (změna chování, porušení runtime kontraktu). Otrava registry nástrojů tak není jedna chyba, ale celá rodina zranitelností napříč životním cyklem nástroje.

Proč digitální podpisy nestačí

Logickou reakcí podnikových bezpečnostních týmů je sáhnout po osvědčených nástrojích: code signing, SBOM (Software Bill of Materials), SLSA (provenance) nebo Sigstore. Tyto technologie ověřují artifact integrity — zda je soubor skutečně tím, za co se vydává, a zda nebyl pozměněn po publikaci. To je důležité, ale v případě AI agentů nedostatečné.

Co registry nástrojů skutečně potřebují, je behavioral integrity — záruka, že se nástroj chová tak, jak deklaruje, a že nepracuje s ničím jiným. Stávající kontroly artifact integrity tuto otázku neřeší. Jak upozornil Kale ve svém článku na VentureBeat, aplikovat SLSA a Sigstore na registry agentních nástrojů a prohlásit problém za vyřešený by znamenalo opakovat chybu HTTPS certifikátů z počátku tisíciletí: silné záruky identity a integrity, přičemž skutečná otázka důvěry zůstane nezodpovězená.

Útok přes popis i útok přes čas

Představte si konkrétní scénář: útočník publikuje nástroj s čistým kódem, platným podpisem a kompletním SBOM. V popisu ale skryje prompt-injection payload: instrukci, která agenta přesvědčí, aby tento nástroj vždy preferoval před alternativami. Agent přečte popis, považuje nástroj za nejvhodnější a zavolá ho. Všechny kontroly integrity artefaktu projdou, ale agent se rozhodl na základě manipulace.

Ještě nebezpečnější je tzv. behavioral drift — nástroj je ověřen v době publikace, ale po týdnech či měsících změní provozovatel chování na serveru. Začne exfiltrovat data, přesměrovávat požadavky nebo vracet zfalšované výsledky. Digitální podpis se nezměnil, provenance je platná, ale chování je zcela jiné. Artifact integrity tento problém nemá šanci odhalit.

Řešení: Runtime verification v MCP

Kale navrhuje architekturu, která kombinuje provenance s runtime ověřováním. Jádrem je verification proxy — lehká vrstva mezi MCP (Model Context Protocol) klientem (agentem) a MCP serverem (nástrojem). Proxy provádí při každém volání tři klíčové kontroly:

Discovery binding ověří, že volaný nástroj odpovídá nástroji, jehož specifikaci agent dříve vyhodnotil a akceptoval. Zabraňuje útokům typu bait-and-switch, kdy server nabízí jeden nástroj při objevování a jiný při vykonávání.

Endpoint allowlisting znamená, že proxy monitoruje odchozí síťová připojení MCP serveru a porovnává je s deklarovaným seznamem povolených koncových bodů. Pokud měnič měn deklaruje přístup k api.exchangerate.host, ale ve skutečnosti se připojí na neznámý server, nástroj se okamžitě ukončí.

Output schema validation zajišťuje, že proxy kontroluje odpověď nástroje oproti deklarovanému výstupnímu schématu. Odhalí neočekávaná pole nebo datové vzory typické pro prompt injection v odpovědi.

Základem celého přístupu je behavioral specification — strojově čitelná deklarace podobná oprávněním v Androidu, která popisuje, které externí koncové body nástroj kontaktuje, jaká data čte a zapisuje a jaké vedlejší efekty produkuje. Tato specifikace je součástí podepsané atestace nástroje, což ji chrání před manipulací a umožňuje ověření za běhu.

Podle autorova odhadu přidání lehké proxy pro validaci schémat a inspekci sítě prodlužuje každé volání o méně než 10 milisekund. Plná datová analýza je náročnější a vhodná pro prostředí s vysokými bezpečnostními požadavky, základní ochrana by ale měla být standardem.

Co to znamená pro české firmy

Implementace nemusí být radikální. Kale doporučuje postupný přístup, který si mohou osvojit i menší týmy bez masivních investic. Začněte endpoint allowlistem při nasazení: každý nástroj deklaruje externí kontaktní body a proxy je vynucuje. Nepotřebujete žádné další nástroje než síťový sidecar.

Dále přidejte output schema validation. Porovnávejte vrácené hodnoty s tím, co nástroj deklaroval. Odhalíte exfiltraci dat a prompt injection skrytý v odpovědích.

Pro nástroje zpracovávající přihlašovací údaje, osobní údaje (PII) nebo finanční informace nasaďte discovery binding. Rizikovější nástroje by měly podstoupit plnou kontrolu bait-and-switch. Plné behaviorální monitorování pak nasaďte jen tam, kde úroveň rizika ospravedlňuje náklady.

Pro české firmy a instituce má toto téma přímou relevanci. S příchodem EU AI Act musí organizace používající AI systémy ve vysokém riziku (včetně autonomních agentů) prokázat odpovídající bezpečnostní opatření. Otrava registry nástrojů představuje novou kategorii rizika, kterou dosavadní bezpečnostní rámce neřeší. České podniky by měly požadovat od dodavatelů AI agentů, jak zajišťují behavioral integrity nástrojů, které jejich agenti volají. Zejména pokud agenti pracují s osobními údaji nebo citlivými firemními daty, není možné spoléhat se pouze na digitální podpisy.

Většina nástrojů pro AI agenty je dnes lokalizovaná do angličtiny a primárně hostovaná v zahraničních cloudech. Pro český trh to znamená, že data mohou opouštět jurisdikci už při běžném volání nástroje. Endpoint allowlisting nabízí alespoň částečnou kontrolu nad tím, kam se data fyzicky přenášejí.