Refael Angel, medgrunnlegger og CTO av Akeyless – Intervju-serie

Refael Angel, medgrunnlegger og CTO av Akeyless, er en ledende ekspert innen cybersikkerhet og programvareutvikling med lang erfaring innen sky-sikkerhet, kryptering, maskin-autentisering og bedrifts-infrastruktur. Siden han var med å grunnlegge Akeyless i 2018, har han hjulpet til å bygge selskapet rundt moderne hemmelighets-håndtering og identitetssikkerhet for sky-baserte miljøer. Før Akeyless arbeidet han som senior programvare-ingeniør i sikkerhet hos Intuit (INTU ), der han bygget systemer for offentlig-sky-krypteringsnøkkel-håndtering og maskin-autentisering, og fikk praktisk erfaring med AWS, Go, Python, Java, PHP, Bash, Linux, Git og Jenkins. Tidligere i sin karriere hadde Angel programvare-ingeniør-roller hos 3D Systems (DDD ) og Cimatron, der han utviklet CAD/CAM- og Windows-baserte applikasjoner med C/C++, C#, WPF, MFC og objekt-orienterte design-mønster.

Akeyless er et identitetssikkerhet-selskap som fokuserer på å sikre maskiner, AI-agenter og mennesker gjennom en sky-basert plattform bygget rundt null-kunnskaps-kryptografi. Plattformen bringer sammen hemmelighets-håndtering, krypteringsnøkkel-håndtering, sertifikat-livssyklus-håndtering, privilegert tilgang og maskin-identitetssikkerhet, og gir organisasjonene en samlet måte å håndtere legitimasjoner, nøkler, sertifikater og tilgang på tvers av hybrid-, multi-sky-, DevOps- og AI-miljøer. Selskapets posisjonering reflekterer en større endring i cybersikkerhet: Ettersom arbeidsbyrder, tjenester og AI-agenter i økende grad utfører system-tilgang uten direkte menneskelig innblanding, trenger bedriftene sterkere kontroller rundt ikke-menneskelige identiteter, kortvarige legitimasjoner, automatisert rotasjon og kjøretids-styring.

Du var med å grunnlegge Akeyless i 2018 etter å ha bygget krypteringsnøkkel-håndtering- og maskin-autentiseringssystemer hos Intuit. Hva var det som overbeviste deg om at det var på tide å starte Akeyless, og hvordan har den opprinnelige visjonen utviklet seg nå som AI-agenter har dukket opp som en ny klasse av digitale identiteter?

Hos Intuit var jeg en del av teamet som bygget krypteringsnøkkel-håndtering- og maskin-autentiseringssystemer på en tid da Intuit var ett av de første store bedriftene som flyttet til skyen. Det som ble klart for meg var at hver organisasjon som tok i bruk skyen ville til slutt møte det samme problemet vi løste internt: hvordan å håndtere hemmeligheter og nøkler på tvers av distribuerte, dynamiske infrastrukturer. Å bygge dette internt krever enorme ingeniør-resurser, og det har ingen mening for hver bedrift å gjenta det. Det logiske svaret var en SaaS-modell.

Men det var et problem: Tillit. Dette er det mest sensitive materialet en bedrift eier, og ingen alvorlig organisasjon vil gi en tredjepart mulighet til å få tilgang til det. Så kravet var nesten motsigende: levere det som SaaS for skala og enkelhet, men gjøre det arkitektonisk umulig for leverandøren å noen gang se kundens data. Den spenningen er nettopp det som ga liv til Distribuerte Fragmenter Kryptografi (DFC). DFC lar oss kjøre en fullt administrert SaaS-kontroll-planet mens kunden holder et fragment som vi aldri besitter, så vi er matematisk unable til å få tilgang til deres nøkler. Det ble grunnlaget for SaaS-pluss-null-kunnskaps-modellen som Akeyless er bygget på.

Den opprinnelige visjonen var om å sikre menneskelig og maskin-tilgang i skyen. AI-agenter er den naturlige og mest ekstreme utvidelsen av det samme problemet. De er ikke-menneskelige identiteter som opererer på en skala og hastighet som ingen directory er designet for, og den samme null-kunnskaps-, identitets-sentriske grunnlaget utvides nå direkte til dem.

Du blir kreditert som arkitekten bak Akeyless’ patenterede Zero-Trust-krypteringsteknologi. Hva var de største tekniske utfordringene i å bygge en sikkerhetsmodell som kunne eliminere tillits-antagelser samtidig som den forble praktisk for store bedrifter?

Det hardeste var å gjøre “tillit ingen” praktisk i stedet for akademisk. De fleste delt-nøkkel- eller hemmelighets-delings-scheme assemblerer fortsatt den fullstendige nøkkelen på et eller annet tidspunkt, vanligvis innen en enkelt prosess, HSM eller enclave ved kryptografisk operasjon. Det korte vinduet er nettopp det som angripere, malisøse innbyggere og juridiske-kompensasjonsscenarioer målretter.

Med DFC er nøkkelen aldri sammensatt, ikke ved opprettelse, ikke i ro og ikke under bruk. Fragmenter genereres uavhengig i separate tillits-domener, og kryptografiske operasjoner kjøres som en distribuert beregning der hver fragment-innehaver beregner sin lokale andel og bare delvis resultater utveksles. Ingeniør-utfordringen var å oppnå dette med latensen, gjennomstrømmingen og påliteligheten som store bedrifter krever i produksjon.

En annen utfordring, og en av de viktigste, var å aktivere kontinuerlig oppdatering av fragmentene. Vi måtte kunne erstatte hver fragment med en ny matematisk verdi, på hver lokalitet, mens den underliggende master-nøkkelen som fragmentene representerer forblir uendret og den kryptografiske prosessen aldri avbrytes. Dette la til en svært betydelig sikkerhetslag til løsningen. Fordi ved oppdatering kan en angriper ikke lenger samle inn fragmenter tålmodig over tid. Et fragment fanget forrige uke er matematisk uavhengig av fragmentene som eksisterer i dag, så det er støy i stedet for en head-start. For å lære noe om en nøkkel ville en motpart måtte kompromittere hver fragment-lokalitet samtidig, innen en enkelt oppdaterings-vindu, og det kravet vokser eksponentielt harder etterhvert som lokaliteter, tillits-domener og oppdaterings-hyppighet øker. Kombinert med all-eller-ingen-terskelen, der 100 prosent av fragmenter er nødvendige for å avsløre noe og enhver streng subset lekkasjoner ingen informasjon, gjør oppdateringen sikkerhetsmodellen fra en statisk garanti til en tid-avhengig.

Mange organisasjoner kappler for å deployere AI-agenter, men identitetssikkerhet forblir ofte en ettertanke. Hva er de vanligste feilene selskaper gjør når de gir AI-agenter tilgang til bedriftssystemer og sensitive data?

Den største feilen er å behandle en agent som en tjenestekonto og gi den en statisk, langvarig API-nøkkel. Den legitimasjonen blir en permanent, innhøstbar verdi som sitter inne i en ikke-deterministisk, prompt-injiserbar aktør.

Andre vanlige feil jeg ser: å gi stående privilegier i stedet for bare-i-tiden-tilgang, å stole på grove rolle-baserte tillatelser som beskriver hva en agent kan nå, men aldri hva den har til hensikt å gjøre, å gi agenter direkte nett-veier til databaser og API-er så et kompromiss blir lateral bevegelse, og å ha ingen revisjons-kjede som binder en agent-handling tilbake til den menneskelige og prompten som utløste den. Hver av disse er et forsøk på å tilpasse menneske-æra-kontroller til noe som ikke oppfører seg som et menneske.

Akeyless har argumentert for at AI-agenter krever en fundamentalt annen identitetsmodell enn mennesker eller tradisjonelle maskin-arbeidsbyrder. Hva gjør AI-agenter unikt vanskelige å sikre sammenlignet med eksisterende IAM- og PAM-rammeverk?

Feilen i grunn er å behandle AI-agenter som en ny type bruker, eller selv en ny type tjenestekonto, og anta at de kan påmeldes og styres som menneskelige identiteter. Det er en kategori-feil, av flere sammenhengende grunner.

Agent-identiteter er ikke tellbare. Den spesifikke instansen du ønsker å styre eksisterer vanligvis ikke ennå, og ved den tiden den gjør, er den allerede borte. En agent kan spinne opp på en Lambda, kjøre i 800 millisekunder og forsvinne før noen skanner legger merke til det, eller avle kjeder av under-agenter på tvers av VM-er, containere og serverløse som fullføres på sekunder. Å registrere disse i en directory er å behandle spøkelser som beboere: ved den tiden posten er ferdig, er enheten det beskrev forsvunnet.

Riktig anchor er derfor ikke agenten, men arbeidsbyrden-identiteten som runtime allerede utsteder, AWS-eksekverings-rolle, Kubernetes-tjenestekonto-token, SPIFFE-SVID. Den identiteten eksisterer allerede, er vouchert for av plattformen agenten kjører på, og forsvinner når agenten gjør. Fordi identitetene er efemere, er de eneste stabile enhetene å skrive policy mellom autentiserings-metoder og mål-systemer, ikke navngitte identiteter og omfang.

Og dette er der eksisterende IAM og PAM bryter mest avgjørende: statisk RBAC og ABAC kan ikke inneholde en ikke-deterministisk aktør. En agent med en perfekt skopet token og en perfekt tvangt TTL kan likevel bli prompt-injusert, hallucinere en destruktiv forespørsel eller pivotere fra en lese-oppgave til en skrive-oppgave i samme sesjon, uten noen policy-brudd synlig på autoriserings-laget. RBAC og ABAC vurderer ved autentisering, ikke etter, fordi hva som skjer etter er bestemt av en LLM som ser på en kontekst-vindu som policy-forfatteren ikke kan se.

Derfor er agenter unikt vanskelige å sikre fordi de er efemere, ikke-deterministiske, multi-substrat og prompt-injuserte alle på en gang. Det manglende laget er ikke en bedre directory. Det er intent-avhengig styring på hver handling, formidlet av en portal som sjekker hva agenten faktisk gjør mot hva den sa den skulle gjøre, før noen legitimasjon utstedes.

Det er en økende diskusjon rundt “hemmelighetsløse” arkitekturer for AI-systemer. Hva definerer du som hemmelighetsløs autentisering, og hvorfor tror du at statiske legitimasjoner og API-nøkler blir uholdbare i AI-agenter-æraen?

Hemmelighetsløs autentisering betyr at agenten aldri holder en legitimasjon. I stedet for å gi agenten en nøkkel den må lagre og presentere, autentiserer agenten gjennom sin native arbeidsbyrde-identitet, og en kortvarig, bare-i-tiden legitimasjon injiseres i en formidlet sesjon ved kjøretid, og ødelegges når sesjonen slutter. Agenten ser det aldri.

Statiske legitimasjoner og API-nøkler blir uholdbare av en enkel grunn: en hemmelighet en agent holder er en hemmelighet en angriper kan stjele. I en verden der aktøren som holder legitimasjonen kan bli prompt-injusert eller hallucinere, blir en langvarig nøkkel en permanent, innhøstbar verdi som sitter inne i en ikke-deterministisk, prompt-injusert aktør. Fjern legitimasjonen fra agenten og en kompromittert agent har ingenting å lekke. Det er hele poenget med det vi kaller SecretlessAI.

Som AI-agenter får evnen til å planlegge, utføre handlinger og samhandle med flere systemer uavhengig, hva nye angrepsvektorer bekymrer deg mest de neste tre til fem årene?

Angrepsvektorene som bekymrer meg mest alle stammer fra at agenter kan planlegge og handle på tvers av systemer uavhengig. Prompt-injeksjon som kaprer en agents hensikt midt i en oppgave er den klareste, fordi identiteten forblir gyldig selv om atferden blir malisøs. Ut over det bekymrer jeg meg for agent-til-agent-overføringer hvor autoritet overføres langs en kjede uten noen klar ansvarlig, lateral bevegelse gjennom agenter som har direkte nett-tilgang, og data-ekstraksjon hvor en over-privilegert agent henter langt mer enn oppgaven krever.

Det felles tråden er at legitimasjonen og rollen kan være fullstendig legitime mens handlingen ikke er. Forsvar som bare sjekker tillatelse, ikke formål, vil ikke fange noen av disse. Det er derfor intent-avhengig styring på hver enkelt handling, på en portal, er kontrollen jeg tror vil være viktigst.

Vi ser en endring fra å sikre menneskelige identiteter til å sikre maskin- og agent-identiteter. Hvordan ser du på endringen i sikkerhets-prioriteter når organisasjoner begynner å håndtere millioner av ikke-menneskelige identiteter på tvers av infrastrukturen?

Vi går inn i en verden der det overveldende flertallet av system-tilgang utføres av ikke-menneskelige identiteter, maskiner, arbeidsbyrder og nå agenter, men de fleste verktøyene antar fortsatt at det er et menneske bak tastaturet. Resultatet er hemmeligheter overalt, stående privilegier og identiteter som ingen kan fullstendig spore.

Endringen i prioriteringer er fra periodiske, menneske-påvirkede kontroller mot kontinuerlige, kjøretids-kontroller på maskin-skala. Når du håndterer millioner av ikke-menneskelige identiteter, kan du ikke stole på påmelding, sertifisering-kampanjer og kvartalsvis tilgangs-gjennomgang. Du trenger efemær-av-konstruksjon identitet, null stående privilegier og policy vurderes automatisk på hver handling. Menneskelig identitetssikkerhet forsvinner ikke, men den blir en mindre fraksjon av overflaten, og arkitekturen må bygges for ikke-menneskelige flertallet først.

Nyeste forskning tyder på at AI-agenter allerede kan få tilgang til informasjon utover deres tiltenkte tillatelser. Hva styring og kjøretids-kontroller bør organisasjoner ha på plass før de tillater agenter å operere autonomt i produksjons-miljøer?

Før noen agent opererer autonomt i produksjon, ville jeg ønske å ha noen ting på plass. Først, ingen stående legitimasjoner på agenten, med bare-i-tiden, kortvarig tilgang injiseres per sesjon. Andre, ingen direkte nett-vei, så hver agent-handling er formidlet gjennom en obligatorisk knekk-punkt i stedet for å nå databaser og API-er direkte. Tredje, intent-avhengig policy-styring som vurderer formålet med en forespørsel mot den opprinnelige prompten før noen legitimasjon utstedes, så en agent bedt om å analysere inntekter ikke kan utstede en destruktiv kommando. Fjerde, i-sesjon-inspeksjon og respons-masking så sensitive data som PII og PHI er redigert før det kommer inn i agentens kontekst-vindu. Og femte, en enkelt uforanderlig revisjons-post som binder den menneskelige prompten, den klassifiserte hensikten, policy-vurderingen, sesjonen og den endelige handlingen.

Oppdagelse og synlighet betyr også noe, men som inndata til policy, ikke som en forutsetning for beskyttelse. Du bør kunne styre en agent første gang den autentiserer, selv om du aldri har sett den spesifikke instansen før.

Bransjen fokuserer ofte på modell-sikkerhet, men mindre oppmerksomhet blir gitt til identitet, autorisasjon og tilgangskontroll. Hvorfor tror du at disse områdene vil bli noen av de viktigste sikkerhets-utfordringene i AI-æraen?

Modell-sikkerhet får overskriftene, men en perfekt justert modell må likevel handle i den virkelige verden, og øyeblikket det handler trenger det tilgang til systemer og data. Den tilgangen er der den faktiske skaden skjer. Autorisasjon er også det hardeste delen av agenter-sikkerhet, fordi aktøren er ikke-deterministisk og efemær. Du kan ikke løse det reneste på modell-laget, og du kan ikke løse det med statiske roller. Det krever kontinuerlig, intent-avhengig styring på hver handling. Det er uglamorøst infrastruktur-arbeid, som er nettopp hvorfor det er under-diskutert og nettopp hvorfor det vil vise seg å være ett av de mest konsekvensfulle sikkerhets-problemene i denne æraen.

Ser du fremover, tror du at bedrifter til slutt vil trenge en dedikert identitets-lag for AI-agenter, lik hvordan identitets-leverandører ble essensielle for menneskelige brukere, og hva ville den fremtidige arkitekturen se ut som?

Ja, men det vil ikke se ut som menneske-identitets-leverandør-modellen bare omdøpt for agenter. Å bygge en directory av agenter er å bygge en directory for spøkelser, identiteter som er borte før du er ferdig med å påmelde dem.

Agent-identitets-laget jeg forventer vil anchor-identitet til arbeidsbyrden som runtime allerede utsteder, cloud-IAM, Kubernetes-tjenestekontoer, OIDC-føderasjon og standarder som SPIFFE/SPIRE som allerede er produksjons-bevist og tverr-substrat. Autorisasjon vil bli uttrykt som relasjoner mellom autentiserings-metoder og mål-systemer, ikke mellom navngitte identiteter og omfang. Og tyngde-punktet vil være en kjøretids-styrings-plane, en portal som formidler hver handling, klassifiserer hensikt, injiserer efemære legitimasjoner, masker sensitive responser og produserer en fullstendig forensisk-kjede. Identitet betyr fortsatt noe, men det faller på plass bak styring, ikke foran. Den kjøretids-myndighets-laget, som sitter på samme plattform som allerede styrer menneskelig og maskin-tilgang, er det jeg tror hver bedrift som kjører agenter i produksjon til slutt vil trenge.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Akeyless.