Refael Angel, medstifter og CTO af Akeyless – Interviewserie

Refael Angel, medstifter og CTO af Akeyless, er en cybersecurity- og softwareingeniørleder med dyb erfaring i cloud-sikkerhed, kryptering, maskinauthentificering og enterprise-infrastruktur. Siden han medstiftede Akeyless i 2018, har han hjulpet med at bygge virksomheden omkring moderne hemmelighedsstyring og identitetssikkerhed for cloud-native miljøer. Før Akeyless arbejdede han som senior softwareingeniør i sikkerhed hos Intuit (INTU ), hvor han byggede systemer til offentlig-cloud-krypteringsnøglestyring og maskinauthentificering, og fik praktisk erfaring på tværs af AWS, Go, Python, Java, PHP, Bash, Linux, Git og Jenkins. Tidligere i sin karriere havde Angel softwareingeniørroller hos 3D Systems (DDD ) og Cimatron, hvor han udviklede CAD/CAM- og Windows-baserede applikationer ved hjælp af C/C++, C#, WPF, MFC og objektorienterede designmønstre.

Akeyless er et identitetssikkerhedsfirma, der fokuserer på at sikre maskiner, AI-agenter og mennesker gennem en cloud-native platform bygget omkring zero-knowledge-kryptografi. Deres platform bringer sammen hemmelighedsstyring, krypteringsnøglestyring, certifikatlivscyklusstyring, privilegeret adgang og maskinidentitetssikkerhed, og giver organisationer en samlet måde at styre legitimationsoplysninger, nøgler, certifikater og adgang på tværs af hybrid-, multi-cloud-, DevOps- og AI-miljøer. Virksomhedens positionering afspejler en bredere skift i cybersecurity: da arbejdsbyrden, services og AI-agenter i stigende grad udfører systemadgang uden direkte menneskelig indblanding, har virksomheder brug for stærkere kontroller omkring ikke-menneskelige identiteter, kortvarige legitimationsoplysninger, automatiseret rotation og runtime-styring.

De co-stiftede Akeyless i 2018 efter at have bygget krypteringsnøglestyring og maskinauthentificeringssystemer hos Intuit. Hvad var det hul i cloud-sikkerhed og identitetstyring, der overbeviste dig om, at det var tid at starte Akeyless, og hvordan er den oprindelige vision udviklet, da AI-agenter er dukket op som en ny klasse af digitale identiteter?

Ved Intuit var jeg en del af teamet, der byggede krypteringsnøglestyring og maskinauthentificeringssystemer på et tidspunkt, hvor Intuit var en af de første store virksomheder, der flyttede til cloud. Det, der blev klart for mig, var, at hver organisation, der antog cloud, ville til sidst stå over for det samme problem, vi løste internt: hvordan man styrer hemmeligheder og nøgler på tværs af distribueret, dynamisk infrastruktur. At bygge dette internt kræver enorme ingeniørressourcer, og det giver ingen mening, at hver virksomhed skal genskabe det. Den logiske løsning var en SaaS-model.

Fælden var tillid. Dette er det mest følsomme materiale, en virksomhed ejer, og ingen alvorlig organisation vil give en tredjepart adgang til det. Så kravet var næsten modsatret: lever det som SaaS for skala og enkelhed, men gør det arkitektonisk umuligt for leverandøren at se kundens data. Den spænding er præcis, hvad der gav liv til Distributed Fragments Cryptography (DFC). DFC låter os køre en fuldt administreret SaaS-kontrolplan, mens kunden holder en fragment, som vi aldrig besidder, så vi er matematisk ude af stand til at få adgang til deres nøgler. Det blev grundlaget for SaaS plus Zero-Knowledge-modellen, som Akeyless er bygget på.

Den oprindelige vision var om at sikre menneskelig og maskinadgang i cloud. AI-agenter er den naturlige og mest ekstreme udvidelse af det samme problem. De er ikke-menneskelige identiteter, der opererer på en skala og hastighed, som ingen directory er designet til, og den samme Zero-Knowledge, identitetscentrerede grundlag udvides nu direkte til dem.

De er krediteret som arkitekten bag Akeyless’ patenterede Zero-Trust-krypteringsteknologi. Hvad var de største tekniske udfordringer i at bygge en sikkerhedsmodel, der kunne eliminere tillidsantagelser, mens den samtidig var praktisk for store virksomheder?

Det hardeste var at gøre “tillid ingen” praktisk snarere end akademisk. De fleste split-key eller hemmelighedsdelingsordninger samler stadig den fulde nøgle på et tidspunkt, normalt inden for en enkelt proces, HSM eller enclave på det tidspunkt for en kryptografisk operation. Det korte vindue er præcis, hvad angribere, maliciøse insiders og juridiske-kompulsionsscenarier målretter.

Med DFC er nøglen aldrig samlet, ikke ved oprettelse, ikke i hvile og ikke under brug. Fragmenter genereres uafhængigt i separate tillidsdomæner, og kryptografiske operationer køres som en distribueret beregning, hvor hver fragmentholder beregner sin andel lokalt, og kun delvise resultater udveksles. Det tekniske udfordring var at opnå dette med den latency, gennemstrømning og pålidelighed, som store virksomheder kræver i produktion.

En anden udfordring, og en af de mest betydningsfulde, var at aktivere kontinuerlig opdatering af fragmenterne. Vi måtte kunne erstatte hver fragment med en ny matematisk værdi, på hver lokalitet, mens den underliggende masternøgle, som fragmenterne repræsenterer, forbliver uforandret, og den kryptografiske proces aldrig afbrydes. Dette tilføjede et meget substantielt lag af sikkerhed til løsningen. Fordi opdateringen gør det umuligt for en angriber at samle fragmenter tålmodigt over tid. En fragment, der blev fanget sidste uge, er matematisk ikke-relateret til de fragmenter, der findes i dag, så det er støj snarere end en head start. For at lære noget om en nøgle ville en modpart være nødt til at kompromittere hver fragmentlokation samtidig, inden for en enkelt opdateringsvindue, og det krav vokser eksponentielt sværere, efterhånden som lokaliteter, tillidsdomæner og opdateringsfrekvens øges. Kombineret med det alt-eller-intet-grænseværdi, hvor 100 procent af fragmenterne er nødvendige for at afsløre noget, og enhver streng undermængde lækker zero information, gør opdateringen sikkerhedsmodellen fra en statisk garanti til en tidsspecifik.

Mange organisationer er ved at udrulle AI-agenter, men identitetssikkerhed er ofte en eftertanke. Hvad er de mest almindelige fejl, virksomheder begår, når de giver AI-agenter adgang til enterprise-systemer og følsomme data?

Den største fejl er at behandle en agent som en servicekonto og give den en statisk, langvarig API-nøgle. Denne legitimationsoplysning bliver en permanent, høstbar aktiv, der sidder inde i en ikke-deterministisk, prompt-injektabel actor.

De andre almindelige fejl, jeg ser, er: at give stående privilegier i stedet for kun-i-tid-adgang, at stole på grove rollebaserede tilladelser, der beskriver, hvad en agent kan nå, men aldrig, hvad den har til hensigt at gøre, at give agenter direkte netværksstier til databases og API’er, så et kompromis bliver lateral bevægelse, og at have ingen revisionskæde, der knytter en agent-handling tilbage til den menneskelige og prompt, der udløste den. Hver af disse er et forsøg på at tilpasse menneske-æra-kontroller til noget, der ikke opfører sig som et menneske.

Akeyless har argumenteret for, at AI-agenter kræver en fundamentalt anderledes identitetsmodel end mennesker eller traditionelle maskinbyrden. Hvad gør AI-agenter unikt svære at sikre i forhold til eksisterende IAM- og PAM-rammer?

Den grundlæggende fejl er at behandle AI-agenter som en ny type bruger eller endda en ny type servicekonto og antage, at de kan påmeldes og styres som menneskelige identiteter. Det er en kategori-fejl, af flere sammenhængende årsager.

Agent-identiteter er ikke oprejst. Den specifikke instans, du ønsker at styre, findes normalt ikke endnu, og på det tidspunkt, det gør, er det allerede forsvundet. En agent kan starte på en Lambda, køre i 800 millisekunder og forsvinde, før en scanner når at bemærke det, eller danne kæder af underagenter på tværs af VM’er, containere og serverless, der afsluttes på få sekunder. At registrere disse i en directory er at behandle spøgelser som beboere: på det tidspunkt, indgangen er gennemført, er enheden, den beskrev, forsvundet.

Den rette anchor er derfor ikke agenten, men arbejdsbyrden-identiteten, som runtime allerede udsteder, AWS-executionsrollen, Kubernetes-servicekontotoken, SPIFFE SVID. Denne identitet findes allerede, er garanteret af platformen, som agenten kører på, og forsvinder, når agenten gør. Fordi identiteterne er efemere, er de eneste stabile enheder at skrive politik mellem autentificeringsmetoder og målsystemer, ikke navngivne identiteter og omfang.

Og det er her, hvor eksisterende IAM og PAM bryder mest afgørende: statisk RBAC og ABAC kan ikke indeholde en ikke-deterministisk actor. En agent med en perfekt scoped token og en perfekt gennemført TTL kan stadig være prompt-injektet, hallucinere en destruktiv forespørgsel eller skifte fra en læseopgave til en skriveopgave i samme session, uden nogen politikovertrædelse synlig på autorisationslaget. RBAC og ABAC vurderer ved autentificering, ikke efter, fordi det, der sker efter, bestemmes af en LLM, der ser på en kontekstvindue, som politikforfatteren ikke kan se.

Derfor er agenter unikt svære at sikre, fordi de er efemere, ikke-deterministiske, multi-substrat og prompt-injektabel på én gang. Det manglende lag er ikke en bedre directory. Det er intent-vidende gennemførelse på hver handling, formidlet af en gateway, der kontrollerer, hvad agenten faktisk gør, mod hvad den sagde, den ville gøre, før nogen legitimationsoplysning udstedes.

Der er en voksende diskussion om “hemmelighedsfrie” arkitekturer for AI-systemer. Hvordan definerer du hemmelighedsfri autentificering, og hvorfor tror du, at statiske legitimationsoplysninger og API-nøgler bliver utilfredsstillende i tiden med autonome agenter?

Hemmelighedsfri autentificering betyder, at agenten aldrig holder en legitimationsoplysning overhovedet. I stedet for at give agenten en nøgle, som den skal gemme og præsentere, autentificerer agenten gennem sin native arbejdsbyrden-identitet, og en kortvarig, kun-i-tid-legitimationsoplysning indsprøjes i en formidlet session på det tidspunkt for udførelse, og derefter ødelægges, når sessionen sluttes. Agenten ser aldrig det.

Statiske legitimationsoplysninger og API-nøgler bliver utilfredsstillende af en enkel grund: en hemmelighed, som en agent holder, er en hemmelighed, som en angriber kan stjæle. I en verden, hvor aktøren, der holder legitimationsoplysningen, kan være prompt-injektet eller hallucinere, bliver en langvarig nøgle til en hemmelighedslæk, når en agent er kompromitteret. Fjern legitimationsoplysningen fra agenten, og en kompromitteret agent har intet at lække. Det er hele pointen med, hvad vi kalder SecretlessAI.

Som AI-agenter får evnen til at planlægge, udføre handlinger og interagere med multiple systemer uafhængigt, hvilke nye angrebsvektorer bekymrer dig mest over de næste tre til fem år?

De vektorer, der bekymrer mig mest, stammer alle fra, at agenter kan planlægge og handle på tværs af systemer uafhængigt. Prompt-injektion, der kaprer en agents hensigt midt i en opgave, er den mest åbenlyse, fordi identiteten forbliver gyldig, selvom adfærden bliver ondsindet. Ud over det bekymrer jeg mig om agent-til-agent-overførsler, hvor autoritet overføres langs en kæde uden klart ansvar, lateral bevægelse gennem agenter, der har direkte netværksadgang, og dataudtræk, hvor en over-privilegeret agent trækker langt mere end sin opgave kræver.

Den fælles tråd er, at legitimationsoplysningen og rollen kan være perfekt legitime, mens handlingen ikke er. Forsvar, der kun kontrollerer tilladelse, og ikke formål, vil ikke fange nogen af disse. Det er derfor, intent-vidende gennemførelse på en gateway, på hver enkelt handling, er den kontrol, jeg tror vil være vigtigst.

Vi ser en skift fra at sikre menneskelige identiteter til at sikre maskin- og agent-identiteter. Hvordan ser du balancen af sikkerhedsprioriteter ændre sig, når organisationer begynder at styre millioner af ikke-menneskelige identiteter på tværs af deres infrastruktur?

Vi bevæger os ind i en verden, hvor den overvældende majoritet af systemadgang udføres af ikke-menneskelige identiteter, maskiner, arbejdsbyrden og nu agenter, men det meste af værktøjerne antager stadig, at der er et menneske bag tastaturet. Resultatet er hemmeligheder overalt, stående privilegier og identiteter, som ingen kan fuldt ud spore.

Skiftet i prioriteringer er fra periodiske, menneske-pacede kontroller til kontinuerlige, runtime-gennemførelse på maskineskala. Når du styrer millioner af ikke-menneskelige identiteter, kan du ikke stole på tilmelding, certificeringskampagner og kvartalsvise adgangsrevisioner. Du har brug for efemær-by-construction-identitet, zero stående privilegier og politik, der vurderes automatisk på hver handling. Menneske-identitetssikkerhed forsvinder ikke, men det bliver en mindre del af overfladen, og arkitekturen må bygges for den ikke-menneskelige majoritet først.

Seneste forskning antyder, at AI-agenter måske allerede har adgang til information ud over deres intentionerede tilladelser. Hvad governance og runtime-kontroller bør organisationer have på plads, før de tillader agenter at operere autonomt i produktionsmiljøer?

Før nogen agent opererer autonomt i produktion, ville jeg ønske følgende ting på plads. Først, ingen stående legitimationsoplysninger på agenten, med kun-i-tid, kortvarig adgang indsprøjet per session. Anden, ingen direkte netværkssti, så hver agent-handling er formidlet gennem en obligatorisk choke point i stedet for at nå databases og API’er direkte. Tredje, intent-vidende politik-gennemførelse, der vurderer formålet med en anmodning mod dens oprindelige prompt, før nogen legitimationsoplysning udstedes, så en agent, der bedes om at analysere omsætning, ikke kan udstede en destruktiv kommando. Fjerde, i-session-inspektion og respons-masking, så følsomme data som PII og PHI er redigeret, før de kommer ind i agentens kontekstvindue. Og femte, en enkelt uforanderlig revisionspost, der kobler den menneskelige prompt, den klassificerede hensigt, politik-vurderingen, sessionen og den endelige handling.

Opdagelse og synlighed er også vigtige, men som input til politik, ikke som en forudsætning for beskyttelse. Du skal være i stand til at styre en agent, første gang den autentificerer, selv hvis du aldrig har set den specifikke instans før.

Branchen fokuserer ofte på model-sikkerhed, men mindre opmærksomhed gives til identitet, autorisation og adgangskontrol. Hvorfor tror du, at disse områder vil blive nogle af de vigtigste sikkerhedsudfordringer i AI-æraen?

Model-sikkerhed får overskrifterne, men en perfekt justeret model skal stadig handle i den virkelige verden, og på det tidspunkt, den handler, har den brug for adgang til systemer og data. Det er, hvor den virkelige skade sker. En model, der aldrig rører en database, kan ikke udtrække en. Risikoen materialiseres ved autorisationsgrænsen.

Autorisation er også den sværeste del af agentic-sikkerhed, fordi aktøren er ikke-deterministisk og efemær. Du kan ikke løse det kun på modellaget, og du kan ikke løse det med statiske roller. Det kræver kontinuerlig, intent-vidende gennemførelse på hver handling. Det er ikke-glamorøst infrastruktur-arbejde, som er præcis, hvorfor det er underdiskuteret, og præcis, hvorfor det vil vise sig at være et af de mest konsekvensfulde sikkerhedsproblemer i denne æra.

At se fremad, tror du, at virksomheder vil kræve en dedikeret identitetslag for AI-agenter, ligesom identitetsudbydere blev essentielle for menneskelige brugere, og hvordan vil den fremtidige arkitektur se ud?

Ja, men det vil ikke se ud som den menneskelige identitetsudbyder-model blot omdøbt til agenter. At bygge en directory af agenter er at bygge en directory for spøgelser, identiteter, der er forsvundet, før du får afsluttet tilmeldingen.

Agent-identitetslaget, jeg forventer, vil anchor-identitet til arbejdsbyrden, som runtime allerede udsteder, cloud-IAM, Kubernetes-servicekontotoken, OIDC-føderation og standarder som SPIFFE/SPIRE, der allerede er produktion-godkendt og cross-substrat. Autorisation vil blive udtrykt som relationer mellem autentificeringsmetoder og målsystemer i stedet for mellem navngivne identiteter og omfang. Og centrum af tyngdekraften vil være en runtime-gennemførelse-plan, en gateway, der formidler hver handling, klassificerer hensigt, indsprøjter efemær-legitimationsoplysninger, masker følsomme svar og producerer en fuld forensisk kæde. Identitet er stadig vigtig, men det falder på plads bag gennemførelsen i stedet for foran. Denne runtime-myndigheds-lag, der sidder på samme platform, der allerede styrer menneskelig og maskin-adgang, er, hvad jeg tror, hver virksomhed, der kører agenter i produktion, til sidst vil have brug for.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Akeyless.