AI agent může udělat chybu. Může ale také dostat pokyn od někoho, komu jsme žádné oprávnění dát nechtěli. O skutečném dopadu pak rozhoduje, k čemu všemu má přístup a kam se přes něj dá dostat.
Když se o AI bavíme se zákazníky, vidím dva poměrně odlišné přístupy. Některé firmy mají pocit, že AI nepotřebují. Když se ale podíváme dovnitř, jejich zaměstnanci už dávno používají nejrůznější veřejné nástroje a nahrávají do nich firemní data. Na druhém konci jsou firmy, které chtějí AI nasadit na všechno a všude. Nejdřív ji nasadí a teprve potom přemýšlejí, jaký to může mít dopad.
Způsob, jakým zákazníci AI nasazují, má dopad na zabezpečení jejich prostředí – a právě za to jsme odpovědní. Proto se této oblasti musíme věnovat. Jelikož jsem k tématu nenašel dostatek vhodných materiálů, začal jsem pátrat sám. A jako vždy s vámi chci sdílet, k čemu jsem došel. Doufám, že vám tím pomohu.
Z chatbota se stává agent
Chatbot, jak jsme ho znali ještě nedávno, především odpovídal na otázky. AI agent už může pracovat se soubory, upravovat zdrojový kód, přistupovat k dalším službám nebo spouštět příkazy na počítači. Aby nám dokázal reálně pomáhat, musíme mu dát nástroje a oprávnění.
A právě tady se začíná měnit i bezpečnostní riziko.
Nemyslím si, že by AI chtěla našemu počítači nebo firmě úmyslně ublížit. Může ale udělat chybu. Například si může vymyslet název neexistujícího softwarového balíčku. Útočník pod stejným názvem balíček vytvoří a agent ho později stáhne a spustí.
Vedle této chyby ale existuje ještě druhé riziko: agent může být zmanipulován.
Social engineering pro AI
Útokům, při kterých agent dostane škodlivou instrukci v datech, se říká indirect prompt injection. Já si je představuji jako určitý druh social engineeringu namířeného proti AI.
Instrukce může být schovaná na webové stránce, v dokumentu nebo třeba v komentáři ve zdrojovém kódu. Uživatel agentovi zadá legitimní úkol, ale agent během jeho plnění narazí na podvrženou instrukci a začne ji následovat.
V přednášce ukazuji experiment, při kterém se podařilo tímto způsobem přimět agenta ke stažení a spuštění backdooru. Když spuštění napoprvé nefungovalo, agent sám našel chybu a opravil ji. Schopnost samostatně řešit problémy, kvůli které agenty používáme, se v tu chvíli obrátila proti jejich uživateli.
Samotné schvalování každého příkazu přitom nemusí být dostatečnou obranou. Pokud agent pokládá jeden dotaz za druhým, člověk je po nějaké době začne potvrzovat automaticky. A jestli příkazu nerozumí, stejně nedokáže spolehlivě posoudit, zda je bezpečný.
Rozhoduje blast radius
Stejná chyba nebo manipulace může mít velmi rozdílný dopad. U běžného uživatele povede k úniku historie konverzací, osobních údajů nebo firemních dat. U vývojáře jsou ve hře zdrojové kódy, API klíče a přístupy do dalších systémů. U administrátora se bavíme o serverech, privilegovaných účtech nebo celém firemním IT prostředí.
Proto podle mě nestačí řešit pouze to, jak bezpečný je použitý AI model. Potřebujeme se ptát také na to, pod jakou identitou agent pracuje, kde běží, jaká data vidí, které nástroje smí použít a k jakým dalším systémům se přes ně dostane. Jinými slovy: jaký má blast radius.
V přednášce proto neřeším jen prompt injection. Probírám také rozdílný blast radius u běžných uživatelů, vývojářů a administrátorů a nové cesty pro laterální pohyb, které může nasazení AI ve firmě vytvořit.
Budu rád, pokud vám přednáška pomůže podívat se na AI agenty nejen jako na užitečné nástroje, ale také jako na další součást infrastruktury, které musíme rozumně vymezit oprávnění a dosah.