Tool poisoning

V užším, dnes ustáleném významu se termínem tool poisoning rozumí konkrétní postup, při kterém útočník ukryje škodlivé pokyny přímo do popisu nebo metadat nástroje. Model si tyto popisy přečte dříve, než se rozhodne, který nástroj zavolat, a skryté pokyny splní, ačkoli je uživatel ve svém rozhraní vůbec nevidí.

Na rozdíl od data poisoningu, který narušuje trénink modelu, a od techniky prompt injection, která manipuluje s bezprostředním vstupem modelu za provozu, míří tool poisoning na ekosystém nástrojů a služeb, o něž se model opírá. Patří k nejzávažnějším hrozbám pro takzvané agentní AI systémy, které samostatně volají externí služby, vyhledávají informace a na základě vlastního rozhodnutí provádějí akce.

Původ a historie

Termín tool poisoning se ustálil na jaře roku 2025, kdy na tento způsob útoku upozornila bezpečnostní společnost Invariant Labs. Pojem od počátku souvisí s nástupem protokolu MCP (Model Context Protocol), otevřeného standardu, který modelům usnadňuje připojování nástrojů a služeb třetích stran. Právě snadnost, s jakou lze k modelu připojit cizí nástroj, otevírá prostor pro útok: model přebírá popisy nástrojů jako důvěryhodné instrukce, přestože pocházejí z nedůvěryhodného zdroje. Podstatné je, že nejde o chybu v samotném protokolu, ale o důsledek toho, že se modelu předkládají instrukce a data v jednom kanálu, aniž by je dokázal spolehlivě oddělit. Stejnou slabinu zneužívá i prompt injection.

Tool poisoning je v podstatě specializovanou podobou nepřímého útoku typu prompt injection. Útočník nejedná s modelem přímo, ale podstrčí mu škodlivé pokyny skrze obsah, který model čte, v tomto případě skrze popis nebo výstup jiného nástroje. Zásadní rozdíl je v tom, že klasická injekce ovlivní pouze jedinou relaci, otrávený nástroj působí opakovaně a ve všech relacích, které jej využívají, dokud zůstane v systému zapojen.

Podstata tool poisoningu

Současné velké jazykové modely (LLM) nejsou izolovaným systémem. Bývají zasazeny do složitějších architektur, které jim umožňují spolupracovat s externími zdroji: vyhledávat na internetu, číst z databází, analyzovat obrázky, spouštět kód, odesílat poštu, provádět platby nebo komunikovat s desítkami dalších služeb. Tato schopnost rozšiřuje možnosti modelu, zároveň však vytváří nové riziko. Dokáže-li útočník ovlivnit některý z nástrojů nebo jeho výstup, nepřímo řídí chování modelu.

Útok těží z předpokladu, že jsou externí nástroje považovány za důvěryhodné a jejich výstupy za přesné a nemanipulované. Pokud model tomuto předpokladu věří a na základě informací od nástroje rozhoduje, pak ten, kdo nástroj ovládá nebo dokáže upravit jeho výstup, fakticky ovládá i rozhodnutí modelu. Útočníkovi přitom nemusí být znám prompt, kterým je model řízen, ani nepotřebuje přímý přístup k modelu. Stačí mu ovlivnit jediný nástroj z těch, které model používá. Tool poisoning je proto obzvlášť zákeřný vektor, protože hranice mezi důvěryhodným a kompromitovaným nástrojem bývá nezřetelná a těžko rozpoznatelná.

Mechanismy a vektory útoku

Všechny podoby útoku mají společné jádro: do informací, které model o nástroji čte a jimž důvěřuje, se dostane podvržený obsah. Model se řídí popisem nástroje, přejímá jeho výstupy a předpokládá jeho bezvadnou funkci. Konkrétní podoba útoku závisí na architektuře systému a na tom, jak jsou nástroje zapojeny. Dva další činitelé, řetězení nástrojů a spouštění kódu, účinek útoku znásobují.

• Otrávení popisu a metadat – Model se podle popisu nástroje a jeho vstupního schématu rozhoduje, který nástroj a jak zavolat. Vloží-li útočník do těchto metadat skryté pokyny, model je bere jako součást legitimního zadání a jedná podle nich. Nástroj se přitom navenek tváří neškodně: nese například prosté jméno a jeho popis začíná běžnou větou, kdežto škodlivá část je ukryta hlouběji, mimo dohled uživatele. Tato plocha je nejtypičtější tam, kde uživatel nebo vývojář připojuje k modelu cizí nástroj či server třetí strany. Stačí, aby jej útočník vydával za užitečný a do jeho metadat ukryl škodlivé pokyny. Právě tento případ bývá označován za otrávení nástroje v užším smyslu. Zvláštní variantou je takzvaný rug pull, tedy podvržení po schválení: server nejprve nabídne neškodnou verzi nástroje, kterou vývojář prověří a přijme, a teprve později ji vymění za škodlivou. Změny popisu si přitom uživatel zpravidla nevšimne, protože ho rozhraní na úpravu neupozorní.
• Podvržení dat a výstupů – Druhou útočnou plochou jsou data, která nástroj modelu vrací nebo která sám zpracovává. Pokud model volá například službu pro vyhledávání cen, může útočník, který tuto službu ovládá nebo dokáže upravit její odpovědi, vrátit nepravdivé údaje a přimět model k chybnému rozhodnutí. Tento mechanismus má řadu konkrétních podob podle toho, odkud nástroj data čerpá. Může jít například o manipulaci se zpracovávanými obrazovými daty a podvržení obsahu databází nebo webových zdrojů.  
• Kompromitace nástroje – Další možnost útoku představuje samotný nástroj a prostředí, ve kterém běží. Získá-li útočník přístup k serveru, na kterém nástroj běží, nebo k datům, s nimiž nástroj pracuje, může jej kompletně ovládnout. Veškeré výstupy pak nesou škodlivý nebo pozměněný obsah a model, který nástroji důvěřuje, jedná na základě kompromitovaných informací. Konkrétním vektorem jsou rozšíření a zásuvné moduly (pluginy) třetích stran: používá-li model takové moduly, může útočník, který je ovládá, vsunutím škodlivého kódu ovlivnit jeho chování. Tento případ je významný hlavně u systémů, jež dovolují uživatelům či vývojářům instalovat vlastní rozšíření.

Dopad útoku zesiluje řetězení nástrojů. Při postupném volání, kdy model nejprve informace vyhledá, pak je zpracuje a podle výsledku zavolá další nástroj, se výstup prvního nástroje stává vstupem druhého. Pokud je otráven první článek, pracuje každý další už s kompromitovanými daty. Útočník tak může kompromitací jediného článku ovlivnit všechny následující. 

Druhým akcelerátorem je spouštění kódu. Jestliže má model k dispozici funkce pro spouštění kódu nebo databázových dotazů, může ho útočník podstrčením vhodně připravených dat navést k vygenerování a spuštění škodlivého kódu, například nebezpečného SQL dotazu. Tento případ se prolíná s technikou prompt injection, hrozba je však vážnější, protože kód nespouští člověk, ale samostatně jednající model.

Praktické příklady a dopady

Jelikož je tato technika útoku zatím relativně nová, dokládají závažnost tool poisoningu především demonstrace metod, nikoli potvrzené případy reálných obětí. Bezpečnostní výzkumníci už předvedli několik útoků, které ukazují jeho ničivý potenciál. Předvedli například nástroj, jehož popis skrýval pokyn k vyhledání citlivých souborů a jejich odeslání útočníkovi. Model po připojení takového nástroje pokyn splnil, zatímco uživateli vrátil zcela běžně vypadající odpověď. Prostřednictvím otráveného nástroje bylo také možné získat obsah ze soukromých zdrojů. AI agent vyzvaný ke zpracování veřejně dostupného podnětu v něm narazil na skryté pokyny a na jejich základě odeslal data ze soukromých repozitářů útočníkovi. Podobně byla předvedena exfiltrace historie zpráv z komunikační aplikace.

Tool poisoning a agentní AI

Zvláštní pozornost si tool poisoning zaslouží u agentních systémů, které samostatně volají nástroje, vyhodnocují jejich výstupy, rozhodují a jednají. A přestože agentní AI jedná s minimem lidských zásahů, má její rozhodnutí bezprostřední důsledky ve skutečném světě. Útočníkovi přitom stačí ovlivnit pouze jediný z nástrojů, které agent používá. Pokud agent postrádá dostatečné mechanismy pro ověřování výstupů a pro rozpoznání odchylek, může být zcela ovládnut.

Příkladem může být AI agent spravující investiční portfolio, který volá nástroje pro zjišťování kurzů, rozbor trendů a uzavírání obchodů. Pozmění-li útočník nástroj pro kurzy, agent obdrží nepravdivé ceny a uzavře na jejich základě ztrátové obchody. Je-li otráven nástroj pro rozbor trendů, bude agent jednat podle zkreslených analýz. A když bude kompromitován nástroj pro uzavírání obchodů, lze agenta přimět k operacím, které nebudou v souladu s jeho zadáním. 

Obrana proti tool poisoningu

Obrana vyžaduje kombinaci zabezpečení nástrojů, ověřování jejich výstupů, sledování jejich chování a architektonická opatření zvyšující odolnost systému.

1. Prvním krokem je prověřování nástrojů ještě před jejich připojením. Popisy a metadata nástrojů je třeba chápat jako nedůvěryhodný vstup a kontrolovat je dříve, než se k modelu připojí. K tomu dnes slouží specializované skenery, které popisy nástrojů automaticky prohledávají a hledají v nich skryté pokyny. Důležité je připojovat jen nástroje z ověřených zdrojů, sledovat změny jejich popisů a varovat uživatele, pokud se popis po schválení změní.
2. Během provozu je nutné ověřovat výstupy nástrojů, protože model by neměl výstupům slepě věřit. Ověření může spočívat v porovnávání výsledků s dříve získanými informacemi nebo v kontrole věrohodnosti, která odhalí statisticky či logicky nepravděpodobný výsledek.
3. Důležitá je také redundance nástrojů. Místo spoléhání na jediný nástroj může model volat několik nástrojů s obdobnou funkcí. Shodují-li se jejich výstupy, je vyšší pravděpodobnost, že jsou správné. Pokud se výrazným způsobem liší, je třeba provést dodatečné kontroly. Tento přístup sice zvyšuje provozní náklady, ale výrazně posiluje odolnost modelu.
4. Nástroje by také měly být vzájemně odděleny a mít přístup jen k tomu, co nezbytně potřebují. Když dojde ke kompromitaci jednoho z nich, zůstane dopad omezen na jeho vlastní funkci a nešíří se dál. Přístup k nástrojům, které provádějí akce nebo pracují s citlivými daty, je třeba omezit a řídit se principem minimálních oprávnění.
5. Systém by měl chování nástrojů průběžně sledovat a vyhodnocovat odchylky od běžného stavu. Začne-li nástroj náhle vracet výsledky mimo obvyklý rozsah nebo reagovat nezvykle pomalu, může jít o indikátor kompromitace vyžadující prozkoumání.
6. Uživatelé i správci by měli znát rizika otrávení nástrojů a umět je rozpoznat. Vyplatí se zavést postupy pro ověřování nástrojů, kontrolu jejich výstupů a reakci na incidenty, pokud k otrávení dojde.
7. Výzkum nabízí i pokročilejší postupy. Patří k nim i kryptografické ověřování výstupů: pokud nástroj svůj výstup digitálně podepíše, model může ověřit jeho důvěryhodnost a integritu. Další možností je sémantický rozbor výstupů, který se snaží rozpoznat odchylky podle významu, nikoli jen podle formy. Lze tak zachytit výstup, který svým významem neodpovídá dříve získaným informacím nebo nese neobvyklé vzorce. Užitečné je rovněž cílené prověřování odolnosti (adversarial testing), kdy bezpečnostní tým soustavně testuje nástroje různými vstupy, aby odhalil jejich slabiny a ošetřil je.

Budoucí vývoj

Rostoucí míra nasazení agentních systémů v kritických aplikacích a rozšiřování ekosystému připojitelných nástrojů zvyšují riziko napadení modelu tool poisoningem nebo jinou technikou. Je proto důležité zaměřit se na vyšší odolnost a možnost kontroly systémů agentní AI a na rozpoznávání kompromitovaných nástrojů v reálném čase. Pozornost se obrací i k distribuovaným systémům, kde běží nástroje na různých serverech a v různých jurisdikcích, což dále komplikuje jejich zabezpečení a dohled nad nimi.

V delším horizontu bude úspěšnost obrany záviset na tom, zda se podaří vystavět architektury, které nestojí na bezvýhradné důvěře v externí nástroje, a vyvinout mechanismy pro průběžné ověřování jejich integrity. Tool poisoning i tak zůstává jednou z klíčových výzev pro bezpečnost a důvěryhodnost systémů agentní AI.