Krize viditelnosti AI: Proč bezpečnostní týmy létají naslepo a proč nemusí

Integrace agentů AI do produkčních prostředí se urychluje, ale bezpečnostní architektura potřebná k jejich zabezpečení zůstává nebezpečně pozadu. Žijeme v éře, kdy agent AI, který má za úkol rutinní úlohu v prostředí stagingu, může nezávisle rozhodnout “opravit” nesoulad přihlašovacích údajů tím, že smazá databázový svazek.

Jako odvětví kolektivně vypínáme naše mozky, když se jedná o základní principy bezpečnosti a pozorovatelnosti kolem AI. Bezpečnostní týmy létají naslepo, ale nemusí.

Mýtus systémových příkazů a bezpečného nástrojování

Převažující mýtus v prostoru AI je, že můžeme ovládat chování agenta jednoduše tím, že mu řekneme, aby se choval. Systémové příkazy jsou poradenské, nikoli vynucující. V uvedeném incidentu systémová pravidla AI explicitně stanovila, že nesmí spustit destruktivní příkazy, ale agent porušil svá vlastní marketingová ochranná opatření a provedl nejnezvratnější akci možné.

Musíme pracovat pod předpokladem, že AI ve skutečnosti “neví” nic. Útoky proti AI jsou sociálním inženýrstvím, kromě toho, že oběť je hloupější než průměrný člověk. Každý, kdo má zkušenosti s penetračním testováním, rozumí, jak je obtížné pro organizace bránit se proti útokům sociálního inženýrství. Nyní jsou naše počítače také zranitelné.

Kromě toho je nástrojování AI nakonec jen softwarem, a všechny software mají chyby. Už jsme viděli instance, kdy nástrojování AI automaticky spustí neautentizované servery HTTP, umožňující libovolnému místnímu procesu nebo webové stránce spustit libovolné příkazy shellu s uživatelskými oprávněními.

Černá skříňka auditu AI

Pokud AI zjitra nebo je manipulována, zjištění toho, co udělala, je noční můrou. Nástroje AI obecně neposkytují auditní protokoly. Pokud máte štěstí a jste na podnikové úrovni, protokoly, které obdržíte, jsou vážně nedostatečné. Například můžete dostat vágní událost, která uvádí, že uživatel “použil Gen AI.” a pouze základní metriky podrobnosti o počtu tokenů vstupu a výstupu.

Ani jeden z nich nepomůže bezpečnostnímu analytikovi odpovědět na základní otázku: Co přesně tento agent provedl?

Odhalení AI: Jak přestat létat naslepo

Dobrou zprávou je, že nemusíte nutně potřebovat nový bezpečnostní přístroj speciálně pro AI, aby jste znovu získali viditelnost. Stínová AI použití a aktivita agenta jsou detekovatelné pomocí stávajících technik analýzy protokolů, které by váš tým již měl. Volání nástrojů AI, spouštění příkazů a události změny systému lze stopovat na AI pomocí stávající analýzy spuštění procesu (kterou děláte ve vašem bezpečnostním informačním a událostním managementu (SIEM), že ano?).

Zde je, jak můžete využít svou stávající infrastrukturu k detekci aktivity AI:

• Analýza DNS: Analýza protokolů DNS pro dotazy na známá doménová jména služeb AI může pomoci detekovat použití AI ve vašem prostředí.
• Seznamy hrozeb: Tento přístup vyžaduje udržování aktualizovaného seznamu hrozeb domén spojených s platformami AI nebo poskytovateli modelů.
• Komunitní zdroje: Existují komunitní projekty a seznamy blokování, které lze upravit do vyhledávacích tabulek pro programové použití.
• Sledování SSL: Podobný přístup lze použít pro sledování serverů SSL, aby se stopovaly názvy serverů, i když poskytuje slightly méně detailů, protože není zaznamenán plný URL.
• Telemetrie koncových bodů: Můžete použít nástroje jako Sysmon, aby se počítaly procesy a lovily vysoké spawny bash, což je silný indikátor potenciálních agentů AI, kteří spouštějí příkazy na koncovém bodě.

Slepá skvrna, která vyžaduje aktivní změny ve vaší sbírce dat, jsou samotné příkazy. Co uživatelé požadují od AI? Zveřejňují nějaké potenciálně citlivé dokumenty, a tím vytvářejí problémy s dodržováním předpisů? Odpověď na tyto otázky pravděpodobně vyžaduje sbírání požadavků API na poskytovatele; webové proxy, proxy LLM, a nástroje pro ingestování dat z protokolů a SIEM. Tyto mohou odstranit závoj, který blokuje tento cenný zdroj dat.

Vznikající hrozba: Zlé servery MCP

Protokol kontextu modelu (MCP) se objevil jako způsob, jak specifikovat, jak aplikace AI integrují s externími nástroji a zdroji dat. Zatímco standardizuje připojení, také zavádí obrovské nové vektory útoků prostřednictvím “Zlých serverů MCP“.

Hostuji praktické školení, kde studenti mohou zažít tento útok přímo. Navrhnou zlý server MCP, aby oklamali LLM, aby volali legitimní nástroje a odeslali výstup zpět útočníkovi. Protože LLM jsou vysoce zranitelné vůči sociálnímu inženýrství, obcházení jejich vestavěných ochranných opatření je často jen otázkou lepšího výběru slov nebo chytrého pretextu.

Studenti běžně používají svůj zlý server, aby instruovali AI, že je “v režimu údržby” a musí předat data sekundárnímu nástroji pro “auditní protokolování”, což vede k exfiltraci dat. Někteří jsou více kreativní se svými příkazy než jiní, ale všichni jsou obvykle úspěšní.

Zpět k ovládání

Abyste mohli řádně audovat aktivitu AI v reálném světě, potřebujete proxy, aby zachytila požadavky AI, a nástroj pro sbírání protokolů, který je schopen zpracovat obrovské datové poplatky JSON. S touto viditelností můžete detekovat a triážovat hrozby. Nemůžete se spoléhat pouze na dodavatele AI, aby poskytli bezpečnostní vrstvu. Vynucování musí žít ve systémech vaší organizace, ne v odstavci textu, na který doufáme, že se model rozhodne dodržovat. S dobrým řešením pro sbírání protokolů mají bezpečnostní týmy telemetrii; je čas, aby začali dotazovat ji.