Jonathan Zanger, Chief Technology Officer ve společnosti Check Point – Interview Series

Jonathan Zanger, Chief Technology Officer ve společnosti Check Point, přináší vzácnou kombinaci elitních zkušeností z vojenské inteligence, hluboké odbornosti v oblasti umělé inteligence a operačního vedení napříč startupy i globálními podniky. Před svým současným postem působil jako technický ředitel ve společnosti Trigo, kde vedl vývoj nächsten generace umělé inteligence a počítačového vidění, umožňující bezproblémový maloobchod a prevenci ztrát ve velkém měřítku, a to v souladu s komerčním nasazením produktu a výzkumu a vývoje. Dříve zastával seniorní pozice ve výzkumu a vývoji ve společnosti Trigo a strávil více než deset let v izraelské elitní jednotce 8200, kde nakonec vedl divizi kybernetického výzkumu a vývoje zodpovědnou za národní iniciativy v oblasti inteligence a kybernetické bezpečnosti a získal nejvyšší národní uznání za svou práci.

Check Point Software Technologies (CHKP ) je globálním lídrem v oblasti kybernetické bezpečnosti, poskytujícím řešení založená na umělé inteligenci a dodávaná prostřednictvím cloudu, navržená k ochraně podniků a vlád před stále sofistikovanějšími digitálními hrozbami. Společnost slouží více než 100 000 organizací po celém světě s komplexní platformou, která zajišťuje sítě, cloudová prostředí, koncová zařízení a uživatele prostřednictvím preventivního přístupu, jehož cílem je zastavit útoky předtím, než nastanou. Její integrovaná architektura využívá umělou inteligenci a informace o hrozbách v reálném čase k zjednodušení bezpečnostních operací, snížení rizika a umožnění organizacím bezpečně škálovat, zatímco přijímají umělou inteligenci, cloud computing a distribuované systémy.

Máte zkušenosti s vedením rozsáhlých iniciativ v oblasti kybernetické bezpečnosti a umělé inteligence, stavbou systémů založených na umělé inteligenci ve společnosti Trigo a nyní dohlížíte na strategii umělé inteligence ve společnosti Check Point. Jaké konkrétní selhání jste pozorovali, když systémy umělé inteligence přecházejí z kontrolovaných prostředí do produkční fáze, zejména když mají přístup k nástrojům a firemním údajům?

Dvě věci se fundamentálně mění v produkční fázi. První je, že měřítko mění okrajové případy na každodenní události. 0,1procentní falešná pozitivní míra zní v laboratoři skvěle, ale když zpracováváte miliony interakcí, to se překlápí do tisíců incidentů, které vyžadují pozornost. Statistické outliery v testování se stávají operačními realitami v měřítku.

Druhá je, že produkční fáze znamená adversní expozici. V kontrolovaném prostředí jsou vstupy benigní a předvídatelné. Ve skutečném světě budou někteří uživatelé a útočníci aktivně snažit oklamat systém, využívající každý nedůvěryhodný kanál dat k manipulaci chování. Přechod z demonstrace do produkční fáze není problémem měřítka. Je to posun z kooperativního prostředí do sporného, a to vyžaduje fundamentálně odlišné designové předpoklady.

U agenticích systémů, kde modely mohou volat rozhraní API, spouštět kód a řetězit akce, jaké jsou nejkritičtější útočné plochy, které bezpečnostní týmy dosud dostatečně neinstrumentují?

Kritická plocha, kterou většina týmů podceňuje, je sama data. Agenticí systémy rutinně přistupují k nedůvěryhodným zdrojům dat — příchozí e-maily, webové stránky, Jira tikety, open-source kód, externí dokumentace. Tato data jsou přijata a analyzována modely jako součást jejich rozhodovacího procesu.

To vytváří dvě konkrétní rizika. První je otrava paměti — kde manipulovaná obsah zkresluje budoucí odpovědi a rozhodnutí modelu bez zjevné injekce podnětu. Druhé je nepřímá injekce podnětu — kde jsou adversní instrukce vloženy do těch externích dat a efektivní jailbreak modelu z vnitřku. Útočník se nikdy nedotkne podnětu přímo. Pouze zasadí instrukce, kde agent najde.

Prompt injekce je často prezentována jako problém modelu, ale v praxi se stává systémovým problémem. Jak by měly podniky přepracovat svou architekturu, aby izolovaly vstupy modelu, spouštění nástrojů a přístup k citlivým údajům?

Prompt injekce není univerzální problém s univerzálním řešením. Zda je určitý vstup legitimní nebo adversní, závisí zcela na kontextu. Žádost o změnu hesla administrátora je zcela legitimní, pokud je to technický helpdesk agent. Stejná žádost k online retailerovu chatbotu je útok.

To je důvod, proč architektura záleží více než jakákoli jednotlivá detekční technika. Systémy potřebují jak deterministické, tak nedeterministické mechanismy, které pracují společně. Deterministické kontroly spravují přístup k nástrojům a údajům na základě identity agenta, identity uživatele a definované role systému. Nedeterministické, model-založené kontroly přidávají schopnost rozumět jazyku, kontextu a záměru. Potřebujete obě vrstvy — rigidní politiku enforcement a inteligentní kontextuální rozumění — protože ani jedna z nich sama o sobě není dostatečná.

Mnohé agenticí agenti spoléhají na generaci založenou na načtení a externích zdrojích dat. Jaká jsou rizika kolem otravy dat a manipulace kontextu v těchto potrubích a jak je lze zmírnit v reálném čase?

Rizika se liší v závislosti na směru toku dat. Pro interní zdroje dat je primárním rizikem únik citlivých dat — expozice PII, sdílení dat mezi zákazníky, vnitřní informace jsou zpřístupněny neoprávněným stranám. Pro externí zdroje dat zahrnují rizika bias modelu z neověřených informací, nepřímou injekci podnětu vloženou do načteného obsahu a závislost na nedůvěryhodných nebo manipulovaných zdrojích.

Mitigace musí probíhat na úrovni transakce, v reálném čase. Každá agenticí interakce musí být zabezpečena v obou směrech: zajišťující, že citlivá data nejsou úniky z vnitřku ven, a zajišťující, že otrávená nebo adversní informace nejsou krmeny z vnějšku do systému nebo modelu. Nemůžete toto vyřešit pouze v době ingestování, protože kontext je dynamický a hrozby se mění neustále.

Vaše AI Defense Plane představuje sjednocenou kontrolní vrstvu napříč využitím umělé inteligence zaměstnanci, aplikacemi a agenticími systémy. Jaké byly největší architektonické výzvy při budování systému, který může pozorovat a vynucovat politiku napříč takto fragmentovanou AI stack?

Věříme, že v blízké budoucnosti budou agenticí zátěže pokrývat koncová zařízení, aplikace, SaaS služby a cloudové zátěže — všechny hyper-připojené v tom, co nazýváme “Internetem agentů”. Nápad za AI Defense Plane je objevit, spravovat a chránit tuto vyvíjející se podnikovou agenticí infrastrukturu v jednom zobrazení.

Core architektonická výzva spočívá v dynamické evaluaci rizikového profilu a kontextu každého agenta, zatímco vyvíjíme efektivní ochranu v reálném čase pro každou agenticí transakci. To znamená udržovat vysoké míry blokování proti skutečným hrozbám, zatímco minimalizujeme falešné pozitivy — v produkční rychlosti a měřítku, napříč několika běžícími prostředími. Budování systému, který může pozorovat a vynucovat politiku konzistentně napříč takto fragmentovanou a rychle se vyvíjející AI stack, vyžadovalo, abychom přehodnotili, jak abstrahujeme a vyhodnocujeme AI aktivitu na základní úrovni.

Platforma zdůrazňuje rozhodování v reálném čase na úrovni strojů napříč jazyky a pracovními postupy. Jak vyvažujete omezení latence s potřebou hlubokého prohlížení a kontroly akcí založených na umělé inteligenci v produkčních prostředích?

Wyvíjíme a trénujeme základní modely specificky pro prevenci hrozeb, pak používáme destilační techniky, aby byly extrémně efektivní. To nám umožňuje spustit inference rychle a s minimálním výpočtem — dokonce i na CPU nebo komoditních GPU — zatímco zachováváme pokrytí více jazyků a multimodální analýzu, včetně image a audio analýzy, s maximální přesností.

Tento přístup nám umožňuje hluboce prohlížet agenticí transakce bez toho, aby se stal úzkým místem. Bezpečnost, která zavádí nepřijatelnou latenci, bude obejita. Bezpečnost, která je neviditelná pro pracovní postup, ale vynucuje smysluplné kontroly, je to, co se skutečně nasadí a zůstane nasazené.

Agenticí agenti stále více operují s delegovanými oprávněními napříč několika systémy. Jak by měly organizace přehodnotit správu identity a přístupu pro ne-lidské aktéry, zejména když agenti dynamicky rozšiřují svůj rozsah prostřednictvím nástrojů?

Chyba, kterou většina organizací dělá, je traitement agenticích agentů buď jako prodloužení lidských uživatelů, nebo jako tradiční servisní účty. Žádný z těchto modelů se nehodí. Myslete na ně jako na digitální zaměstnance — entity s definovanými rolemi, odpovědnostmi a hranicemi.

Identita agenta by měla být definována třemi dimenzemi: konkrétním pracovním postupem, který agent vykonává, uživatelem, který vlastnil nebo vytvořil agenta, a uživatelem, který目前 interaguje s ním. Všechny tři faktory formují, co by agent měl být povolen dělat. Kromě toho organizace potřebují aplikovat principy nulové důvěry na agenty — nikdy nebudou předpokládat důvěru založenou na původu, neustále ověřovat chování a vynucovat přístup s minimálními privilegii na každém kroku. Bez toho agenti budou tiše kumulovat více autority, než kdokoli zamýšlel.

Mnohé podniky nyní mají stínové využití umělé inteligence napříč copiloty, pluginy a interními skripty. Jakou telemetrii by měly bezpečnostní týmy shromažďovat, aby získaly skutečnou viditelnost do toho, jak umělá inteligence interaguje s citlivými údaji?

Viditelnost potřebuje fungovat na úrovni agenticí transakce — ne pouze podněty a odpovědi, ale volání nástrojů, data vrácená těmito nástroji a akce provedené jako výsledek. Bezpečnostní týmy potřebují vidět celý řetěz: co bylo požádáno, která data byla přístupná, které nástroje byly vyvolány, jaké parametry byly předány a co se stalo dále.

Bez této transakční telemetrie nemůžete odpovědět na základní otázky o expozici, zneužití nebo dopadu. Stínová umělá inteligence není nebezpečná, protože existuje. Je nebezpečná, protože operuje bez této úrovně správy nebo přehledu.

Red teaming agenticích systémů je fundamentálně odlišné od testování statických aplikací. Jak simulujete adversní chování napříč vícestupňovými pracovními postupy a jaké typy exploitů jsou nejčastěji odhaleny?

Provozujeme Gandalf (https://gandalf.lakera.ai), který je největší cvičení umělé inteligence v oblasti red teamingu. Je to crowd-sourced platforma, kde skuteční uživatelé se snaží přesvědčit agenticí agenty, aby porušili své ochranné bariéry. To nám dává unikátní a neustále rostoucí dataset skutečných adversních technik — ne teoretických útoků, ale strategií, které skutečné osoby používají k manipulaci systémy umělé inteligence.

Využíváme tento dataset k pohánění našich schopností red teamingu. Útoky, které vidíme nejčastěji, zahrnují uživatele, kteří postupně přesvědčují agenty, aby porušili své omezení — prostřednictvím nepřímé injekce podnětu, kreativní reframe, kontextové manipulace a inkrementální exploatace důvěry napříč vícestupňovými interakcemi. Tyto problémy jsou neviditelné, pokud testujete pouze jednotlivé podněty. Musíte testovat sekvence a udržitelné adversní kampaně.

Jakmile útočníci začnou využívat autonomní agenty k průzkumu systémů kontinuálně, očekáváte, že obrana se posune směrem k adaptivním kontrolám v reálném čase, poháněným umělou inteligencí, a jak vypadá tato architektura v praxi?

Ano. Statické obrany nemohou držet krok s autonomními útočníky, kteří operují kontinuálně. Obrana musí být adaptivní, poháněná v reálném čase a automatizovaná. To znamená monitorování chování umělé inteligence v reálném čase, neustálé hodnocení rizika a okamžitou aplikaci, když jsou porušeny politiky. Rychlost a měřítko útoků založených na umělé inteligenci budou odraženy pouze stejně rychlými, strojově rychlými obranami.

V praxi se bezpečnost stává zpětnou smyčkou spíše než souborem pravidel. Systémy umělé inteligence jsou pozorovány, vyhodnocovány a omezeny dynamicky, ve stejné rychlosti a měřítku, v jakém operují. Tento posun je nezbytný, pokud organizace chtějí nasadit umělou inteligenci bezpečně v podnikovém měřítku.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Check Point Software Technologies.