Jak Bright Security detekuje injekce ANSI sekvencí v MCP serverech

Bright Security popisuje třídu útoku, při níž mohou ANSI řídicí sekvence skrýt část obsahu před uživatelem, zatímco agentní systém ji dál předá modelu.

23. července 2026 Martin Šuránek

Bright Security popisuje třídu injekčního útoku, která může zasáhnout MCP servery předávající neočištěný externí nebo uložený text do polí zpracovávaných modelem. Nejde o potvrzenou zranitelnost všech MCP serverů ani o chybu samotného protokolu. Využitelnost závisí na konkrétní implementaci a na tom, zda řídicí znaky projdou celým zpracováním až do kontextu modelu.

Co jsou ANSI escape sekvence

ANSI escape sekvence jsou řídicí znaky původně určené pro terminály. Začínají bajtem ESC s hexadecimální hodnotou 0x1B a mohou měnit barvy, skrývat text, mazat část obrazovky nebo přesouvat kurzor.

Terminál tyto sekvence interpretuje a uživateli zobrazí pouze výsledný efekt. Agentní vrstva ale může modelu předat i znaky nebo text, které v uživatelském rozhraní nejsou vidět. To vytváří rozdíl mezi tím, co vidí člověk, a tím, co zpracuje model.

Model sám běžně nevykonává systémové příkazy. Může ale skryté instrukce následovat a agent může v jejich důsledku zavolat dostupné nástroje nebo provést akci v rozsahu svých oprávnění.

Dvě popsané varianty útoku

Bright Security rozlišuje dvě hlavní varianty.

  1. Direct-fetch AESI: MCP nástroj načte obsah z útočníkovy URL a předá ho modelu. Pokud server řídicí sekvence neodstraní, mohou se skryté instrukce dostat do kontextu agenta.

  2. Stored AESI: Payload je nejprve uložen v externím nebo interním systému a do agenta se dostane až při pozdějším načtení MCP nástroje, zdroje nebo promptu. Riziko proto nemusí vzniknout při samotném uložení obsahu, ale až při jeho dalším použití.

Jak Bright Security útok detekuje

Firma argumentuje, že dynamické testování aplikací je pro tuto třídu problému vhodné, protože ověřuje chování běžícího serveru. Nejde pouze o nalezení řídicího znaku ve vstupu. Důležité je zjistit, zda payload skutečně přežije zpracování a dostane se do pole předávaného modelu.

Detekce používá tři signály:

  • ANSI řídicí bajt,
  • pevně definovanou instrukci,
  • unikátní značku konkrétního testovacího payloadu.

Všechny tři části musí zůstat ve stejném poli. Nestačí, aby se payload objevil kdekoliv v odpovědi MCP. Bright považuje problém za potvrzený až tehdy, když se dostane například do result.content[].text, result.contents[].text nebo result.messages[].content.text.

Bezpečnostní dopady

ANSI sekvence mohou manipulovat s výstupem terminálu nebo logů a skrýt část obsahu před člověkem, který kontroluje průběh agentní úlohy. Pokud agent zároveň dostane skrytou instrukci a má přístup k nástrojům, může ji následovat v rozsahu svých oprávnění.

Dopad proto závisí i na návrhu celého agentního systému. Agent s přístupem pouze ke čtení představuje jiné riziko než systém, který může zapisovat soubory, spouštět příkazy nebo přistupovat k interním službám.

Jak riziko omezit

Bright doporučuje odstraňovat kontrolní bajty před vložením externího nebo uloženého textu do kontextu modelu. Dále dává smysl validovat vstupy a povolené URL, omezit oprávnění dostupných nástrojů a zacházet s textem z externích systémů jako s nedůvěryhodným obsahem.

DAST může ověřit, zda payload skutečně projde běžící implementací. Jde ale o přístup popsaný dodavatelem bezpečnostního produktu, nikoli o nezávislé srovnání všech možných metod ochrany MCP serverů.