Jonathan Zanger, Chief Technology Officer på Check Point – Intervju-serie

Jonathan Zanger, Chief Technology Officer på Check Point, har en sällsynt kombination av elit militär underrättelseerfarenhet, djup AI-expertis och operativ ledning inom både startups och globala företag. Innan han tillträdde sin nuvarande roll var han CTO på Trigo, där han ledde utvecklingen av nästa generations AI- och datorsynsystem som möjliggjorde friktionfri detaljhandel och förlustförhindrande i stor skala, samtidigt som han samordnade produkt och FoU med verkliga kommersiella distributioner. Tidigare hade han seniora FoU-ledningsroller på Trigo och tillbringade över ett decennium i Israels elit-enhet 8200, där han slutligen ledde en cyber-FoU-avdelning som var ansvarig för nationella underrättelse- och cybersäkerhetsinitiativ och fick topp-nationell erkänsla för sitt arbete.

Check Point Software Technologies (CHKP ) är en global ledare inom cybersäkerhet, som tillhandahåller AI-drivna, molnbaserade säkerhetslösningar som är utformade för att skydda företag och myndigheter från alltmer sofistikerade digitala hot. Företaget betjänar över 100 000 organisationer världen över med en omfattande plattform som säkrar nätverk, molnmiljöer, slutpunkter och användare genom en förebyggande strategi som syftar till att stoppa attacker innan de inträffar. Dess integrerade arkitektur utnyttjar artificiell intelligens och realtids-hotinformation för att förenkla säkerhetsoperationer, minska risker och möjliggöra för organisationer att växa säkert när de antar AI, molnberäkning och distribuerade system.

Du har lett storskaliga cybersäkerhets- och AI-initiativ, byggt AI-drivna system på Trigo och övervakar nu AI-strategin på Check Point. Vilka specifika felmoder har du observerat när AI-system övergår från kontrollerade miljöer till produktion, särskilt när de ges tillgång till verktyg och företagsdata?

Två saker förändras grundläggande i produktion. Först förvandlas skalans kanter till vardagliga händelser. En felpositivt rate på 0,1 procent låter utmärkt i laboratoriet, men när du bearbetar miljontals interaktioner, översätts det till tusentals incidenter som kräver uppmärksamhet. Statistiska utbrytare i test blir operativa verkligheter i skala.

Andra, produktion innebär antagonistisk exponering. I en kontrollerad miljö är indata benigna och förutsägbara. I den verkliga världen kommer vissa användare och hotaktörer att aktivt försöka lura systemet, utnyttja varje otrustad datakanal som finns tillgänglig för att manipulera beteendet. Övergången från demo till produktion är inte ett skalningsproblem. Det är en övergång från en samarbetsmiljö till en omstridd sådan, och det kräver grundläggande olika designantaganden.

I agenssystem, där modeller kan anropa API:er, köra kod och kedja åtgärder, vilka är de mest kritiska attackytorna som säkerhetsteam fortfarande inte instrumenterar ordentligt?

Den kritiska ytan som de flesta team underskattar är data i sig. Agenssystem har rutinmässig tillgång till otrustade datakällor – inkommande e-post, webbplatser, Jira-biljetter, öppen källkod, extern dokumentation. Den data inges och analyseras av modeller som en del av deras resonemangsprocess.

Detta skapar två konkreta risker. Först, minnesförgiftning – där manipulerat innehåll subtilt formar modellens framtida svar och beslut utan någon uppenbar promptinjektion. Andra, indirekt promptinjektion – där antagonistiska instruktioner är inbäddade i den externa data och effektivt “jailbreaker” modellen från insidan. Angriparen rör aldrig prompten direkt. De planterar bara instruktioner där agenter kommer att hitta dem.

Promptinjektion beskrivs ofta som ett modellproblem, men i praktiken blir det ett systembrett problem. Hur bör företag omkonstruera sin arkitektur för att isolera modellindata, verktygsutförande och känslig dataåtkomst?

Promptinjektion är inte ett universellt problem med en universell lösning. Om en given indata är legitim eller antagonistisk beror helt på sammanhang. Att be en agent att “ändra adminns lösenord” är fullständigt legitimt om det är en teknisk hjälpdeskagent. Samma begäran till en online-återförsäljares chatbot är en attack.

Detta är varför arkitektur är viktigare än någon enskild upptäcksteknik. System behöver både deterministiska och icke-deterministiska mekanismer som fungerar tillsammans. Deterministiska kontroller hanterar åtkomst till verktyg och data baserat på agentens identitet, användarens identitet och systemets definierade roll. Icke-deterministiska, modellbaserade kontroller lägger till förmågan att förstå språk, sammanhang och avsikt. Du behöver båda lager – styva policytillämpningar och intelligent kontextuell resonemang – eftersom ingen av dem ensam är tillräcklig.

Många AI-agenter förlitar sig på återvinningssystem och externa datakällor. Vilka är riskerna kring datapåverkan och kontextmanipulering i dessa pipelines, och hur kan de mildras vid körning?

Riskerna skiljer sig beroende på dataflödets riktning. För interna datakällor är den primära risken känslig dataexponering – PII-exponering, kors-kunddata-delning, intern information som visas för obehöriga parter. För externa datakällor inkluderar riskerna modellbias från overifierad information, indirekt promptinjektion inbäddad i hämtad innehåll och beroende av otrustade eller manipulerade källor.

Mildring måste ske på transaktionsnivå, i realtid. Varje agensinteraktion måste säkras i båda riktningarna: säkerställa att känslig data inte läcker ut från insidan och säkerställa att förgiftad eller antagonistisk information inte matas in i systemet eller modellen från utsidan. Du kan inte lösa detta på inmatningstiden ensam eftersom sammanhang är dynamiskt och hotlandskapet förändras kontinuerligt.

Din AI-försvarsplan introducerar ett enhetligt kontrollskikt över anställd AI-användning, applikationer och agenssystem. Vilka var de största arkitektoniska utmaningarna i att bygga ett system som kan observera och tillämpa policy över en sådan fragmenterad AI-stack?

Vi tror att i den nära framtiden kommer agensarbetsbelastningar att omfatta slutpunkter, applikationer, SaaS-tjänster och molnbelastningar – alla hyperkopplade i vad vi kallar “Internet of Agents”. Idén bakom AI-försvarsplanet är att upptäcka, styra och skydda denna utvecklande företagsagensinfrastruktur inom ett enda fönster.

Den grundläggande arkitektoniska utmaningen är att dynamiskt utvärdera riskprofilen och sammanhanget för varje agent samtidigt som man utvecklar effektiv realtidsskydd för varje agens-transaktion. Det innebär att upprätthålla höga blockeringstal mot verkliga hot samtidigt som man minimerar falska positiva resultat – vid produktionshastighet och skala, över flera körande miljöer. Att bygga ett system som kan observera och tillämpa policy konsekvent över en sådan fragmenterad och snabbt utvecklande AI-stack krävde att vi omdefinierade hur vi abstraherar och utvärderar AI-aktivitet på en grundläggande nivå.

Plattformen betonar realtidsbeslut i maskinvaruhastighet över språk och arbetsflöden. Hur balanserar du latensbegränsningar med behovet av djup inspektion och kontroll av AI-drivna åtgärder i produktionsmiljöer?

Vi utvecklar och tränar grundmodeller specifikt för hotförhindrande, sedan använder vi destilleringstekniker för att göra dem extremt effektiva. Det låter oss köra inferens snabbt och med minimal beräkning – även på CPU:er eller kommersiella GPU:er – samtidigt som vi upprätthåller multi-språk och multi-modal täckning, inklusive bild- och ljudanalys, med maximal noggrannhet.

Denna metod låter oss inspektera agens-transaktioner djupt utan att bli en flaskhals. Säkerhet som introducerar oacceptabel latens kommer att kringgås. Säkerhet som är osynlig för arbetsflödet men tillämpar meningsfulla kontroller är det som faktiskt distribueras och förblir distribuerat.

AI-agenter opererar alltmer med delegerade behörigheter över flera system. Hur bör organisationer omdefiniera identitet och åtkomsthantering för icke-mänskliga aktörer, särskilt när agenter dynamiskt utökar sin omfattning genom verktygsanvändning?

Fel som de flesta organisationer gör är att behandla AI-agenter antingen som utvidgningar av mänskliga användare eller som traditionella tjänstekonton. Ingen av modellerna passar. Tänk på dem som digitala anställda – entiteter med definierade roller, ansvar och gränser.

Agentidentitet bör definieras av tre dimensioner: den specifika arbetsflödet som agenten utför, användaren som äger eller skapade agenten och användaren som för närvarande interagerar med den. Alla tre faktorerna formar vad agenten bör tillåtas göra. Utöver detta behöver organisationer tillämpa noll-tillit-principer på agenter – aldrig anta tillit baserat på ursprung, kontinuerligt verifiera beteende och tillämpa minst-privilegierad åtkomst vid varje steg. Utan detta kommer agenter att tyst ackumulera mer auktoritet än någon avsett.

De flesta företag har nu skugg-AI-användning över copiloter, plugins och interna skript. Vilken telemetri bör säkerhetsteam samla in för att få verklig insikt i hur AI interagerar med känslig data?

Insikt behöver fungera på agens-transaktionsnivå – inte bara prompter och svar, utan verktygsanrop, den data som returneras av dessa verktyg och de åtgärder som vidtas som ett resultat. Säkerhetsteam behöver se hela kedjan: vad som begärdes, vilken data som nåddes, vilka verktyg som anropades, vilka parametrar som skickades och vad som hände sedan.

Utan denna transaktionsnivå-telemetri kan du inte besvara grundläggande frågor om exponering, missbruk eller påverkan. Skugg-AI är inte farlig för att den existerar. Det är farligt för att den opererar utan denna nivå av styrning eller insikt.

Red teaming agenssystem är grundläggande annorlunda än testning av statiska applikationer. Hur simulerar du antagonistiskt beteende över multi-stegsarbetsflöden, och vilka typer av exploateringar upptäcks vanligtvis?

Vi driver Gandalf (https://gandalf.lakera.ai), som är den största AI-red team-övningen i världen. Det är en crowd-sourced-plattform där riktiga användare försöker övertyga AI-agenter att bryta sina riktlinjer. Det ger oss en unik och kontinuerligt växande dataset av verkliga antagonistiska tekniker – inte teoretiska attacker, utan strategier som riktiga människor använder för att manipulera AI-system.

Vi utnyttjar den dataseten för att driva vår red team-kapacitet. Attackerna vi ser oftast involverar användare som gradvis övertalar agenter att bryta mot sina begränsningar – genom indirekt promptinjektion, kreativ omformulering, kontextmanipulering och inkrementell tillitsutnyttjande över multi-stegsinteraktioner. Dessa problem är osynliga om du bara testar enskilda prompter. Du måste testa sekvenser och uthålliga antagonistiska kampanjer.

När angripare börjar använda autonoma agenter för att undersöka system kontinuerligt, förväntar du dig att försvar kommer att förskjutas mot realtidsadaptiva kontroller drivna av AI, och vad ser den arkitekturen ut som i praktiken?

Ja. Statiska försvar kan inte hålla jämna steg med autonoma angripare som opererar kontinuerligt. Försvar måste bli adaptiva, körningsdrivna och automatiserade. Det innebär realtidsövervakning av AI-beteende, kontinuerlig riskbedömning och omedelbar tillämpning när policyer kränks. Hastigheten och omfattningen av AI-drivna attacker kommer bara att motverkas av lika snabba, maskinvaruhastighetsförsvar.

I praktiken blir säkerhet en återkopplingsloop snarare än en regelsamling. AI-system observeras, utvärderas och begränsas dynamiskt, i samma hastighet och skala som de opererar. Den förändringen är avgörande om organisationer vill distribuera AI på ett säkert sätt i företagsskala.

Tack för det underbara samtalet, läsare som vill lära sig mer kan besöka Check Point Software Technologies.