Bezpečnost AI agentů: kritika MCP a terminálu ve vývoji

Krize bezpečnosti AI agentů: proč současné přístupy vedou do slepé uličky

Moderní AI agenti postavení na hotových protokolech jako MCP a shellových obálkách vykazují základní zranitelnosti v bezpečnosti a architektuře. Místo vytváření spolehlivých produktů průmysl produkuje „podomácku vyrobené“ řešení, která nejsou připravena pro vydání pro masového uživatele. Hlavní problémy – iluze bezpečnosti přes guardrails, nekontrolované MCP servery a nebezpečná závislost na terminálu.

Architektonické chyby status quo

Současný přístup k vývoji agentů připomíná stavbu Maginotovy linie: nákladné, ale zbytečné obrany, které lze snadno obejít. Claude Code, navzdory popularitě mezi vývojáři, je příkladem produktu, který není bezpečný pro běžné uživatele. Jeho paradigma práce s git repozitáři jako „padákem“ se neškáluje na publikum bez technického zázemí. Odstranění kritických souborů, úniky dat a nekontrolované provádění příkazů – typická rizika.

Hlavní architektonické nedostatky zahrnují:

• Terminál jako rozhraní: LLM skvěle pracují s textem, ale shell je příliš výkonný a nebezpečný nástroj. Omezení příkazů jako rm vyžaduje složitou infrastrukturu (parsování AST, filtrování syscall), což se špatně škáluje na tisíce příkazů a jejich kombinací.
• MCP protokol: Dává kontrakt pro interakci, ale ignoruje identifikaci, což otevírá vektory útoků tool poisoning (TPA). Útočný MCP server může aktualizovat popis nástrojů, což přinutí LLM nepozorovaně předat klíče nebo hesla.
• Guardrails jako iluze: Pokusy filtrovat toxicitu, prompt injection nebo PII přes regexpy a klasifikátory připomínají implementaci časovače ve hře přes padající průhledné objekty – složité, neefektivní a zanechávající díry.

Proč MCP je slepá ulička pro desktopové agenty

MCP vytváří pět kritických problémů pro produkty obecného použití:

• Bezpečnost: Protokol nezajišťuje identifikaci akcí, umožňuje LLM provádět operace bez výslovného souhlasu uživatele. Zranitelnosti tool poisoning činí systém zranitelným pro skryté útoky.
• Výkonnost: Každý MCP server běží v samostatném procesu. Vývojář agenta nekontroluje, kolik takových procesů uživatel spustí, což může vést k degradaci výkonu stroje.
• Ztráta kontroly: Vývojář nemůže spravovat cizí MCP servery, doplňovat zpracování chyb nebo vidět logy, což vylučuje vytváření transparentního systému.
• Kolize nástrojů: Různé MCP mohou překrývat funkčnost navzájem, přidávat nástroje se stejnými jmény, což vede k nejistotě chování.
• Růst nákladů: Zvýšení spotřeby tokenů na validaci, nafouknutí kódové základny a rizika úniků paměti.

Alternativní přístup: od obecných agentů k specializovaným nástrojům

Místo vytváření „univerzálních agentů“ s přístupem ke všemu přes MCP, je třeba vyvíjet specializované nástroje (funkce) s izolovaným kontextem. To snižuje povrch útoku a zlepšuje kontrolu.

Klíčové principy nové architektury:

• Interpretátor místo terminálu: Vlastní interpretátor s omezenou sadou příkazů dává lepší kompromis mezi bezpečností a možnostmi. Například nástroje na ls a rm lze implementovat s různými úrovněmi potvrzení (callback pro rm, bez potvrzení pro ls).
• Sandbox kolem interpretátoru, ne agenta: Izolace by měla být aplikována na prostředí provádění nástrojů, ne na agenta jako celek. To umožňuje bezpečně provádět kód bez radikálního omezení funkčnosti.
• Transparentnost pro vývojáře: Agent by měl poskytovat kompletní logy, trasování volání a možnost ladění, vylučující černé skříňky jako MCP servery.
• End-to-End testy: Prompty a modely se mění, ale testy na kritické scénáře (například „neodstranit systémové soubory“) by měly zůstat stabilní.

Co je důležité

• Současní AI agenti na bázi MCP a terminálu nejsou bezpeční pro vydání masovým uživatelům.
• Architektonická řešení jako guardrails na regexpech vytvářejí iluzi ochrany, ale jsou snadno obcházena.
• Specializované nástroje s izolací jsou preferovány před univerzálními MCP servery.
• Bezpečnost by měla být zajištěna na úrovni interpretátoru a sandboxu, ne přes přídavné filtry.
• Vývojáři potřebují plnou transparentnost a kontrolu nad prováděním nástrojů pro ladění a audit.

Implementace bezpečného agenta: praktické kroky

• Odmítnutí shellové obálky: Nahraďte terminál interpretátorem s omezeným API. Definujte sadu bezpečných příkazů a implementujte je jako nástroje s explicitními kontrakty.
• Izolace přes sandbox: Použijte kontejnerizaci nebo virtualizaci pro spuštění interpretátoru v izolovaném prostředí. To zabrání nežádoucímu přístupu k souborovému systému nebo síti.
• Zavedení End-to-End testů: Vytvořte testy pro kritické scénáře (například zpracování uživatelských dat, provádění destruktivních operací). Automatizujte je v CI/CD.
• Logování a trasování: Implementujte systém logů, který zaznamenává všechna volání nástrojů, prompty a odpovědi LLM. To je nutné pro audit a ladění incidentů.
• Specializace nástrojů: Místo připojování externích MCP, vyvíjejte nástroje pro konkrétní úkoly (práce se soubory, API, databázemi). To sníží rizika kolizí a úniků.

Kategorický imperativ vývoje agentů

Vytvářejte agenty, které se nebojí vydat. To znamená:

• Spolehlivost a bezpečnost na úrovni tradičních aplikací.
• Absenci nutnosti u uživatele instalovat Docker, otevírat terminál nebo konfigurovat MCP.
• Úsporu tokenů – jednoduché operace by neměly stát stovky korun.
• Transparentnost práce pro vývojáře a možnost rychlé reakce na incidenty.

Jen takový přístup umožní překročit hranice výklenkových nástrojů pro vývojáře a vytvořit produkty pro globální publikum.

— Editorial Team