Refael Angel, medgrundare och CTO på Akeyless – Intervjuserie

Refael Angel, medgrundare och CTO på Akeyless, är en ledande expert inom cybersäkerhet och programvaruteknik med djup erfarenhet av molnsäkerhet, kryptering, maskinautentisering och företagsinfrastruktur. Sedan han medgrundade Akeyless 2018 har han hjälpt till att bygga företaget kring modern hantering av hemligheter och identitetssäkerhet för molnbaserade miljöer. Innan Akeyless arbetade han som senior programvarutekniker inom säkerhet på Intuit (INTU ), där han byggde system för hantering av offentliga molnkrypteringsnycklar och maskinautentisering, och fick praktisk erfarenhet av AWS, Go, Python, Java, PHP, Bash, Linux, Git och Jenkins. Tidigare i sin karriär hade Angel programvarutekniska roller på 3D Systems (DDD ) och Cimatron, där han utvecklade CAD/CAM- och Windowsbaserade applikationer med hjälp av C/C++, C#, WPF, MFC och objektorienterade designmönster.

Akeyless är ett företag inom identitetssäkerhet som fokuserar på att skydda maskiner, AI-agenter och människor genom en molnbaserad plattform byggd kring kryptografi med nollkunskap. Deras plattform kombinerar hantering av hemligheter, krypteringsnyckelhantering, certifikatlivscykelhantering, behörig åtkomst och maskinidentitetssäkerhet, vilket ger organisationer en enhetlig metod för att hantera autentiseringsuppgifter, nycklar, certifikat och åtkomst över hybrid-, multi-moln-, DevOps- och AI-miljöer. Företagets positionering speglar en bredare förändring inom cybersäkerhet: allt eftersom arbetsbelastningar, tjänster och AI-agenter alltmer utför systemåtkomst utan direkt mänsklig inblandning, behöver företagen starkare kontroller kring icke-mänskliga identiteter, kortlivade autentiseringsuppgifter, automatiserad rotation och körningsstyrning.

Du medgrundade Akeyless 2018 efter att ha byggt system för krypteringsnyckelhantering och maskinautentisering på Intuit. Vilken brist inom molnsäkerhet och identitetshantering övertygade dig om att det var dags att starta Akeyless, och hur har den ursprungliga visionen utvecklats allt eftersom AI-agenter har dykt upp som en ny klass av digitala identiteter?

På Intuit var jag en del av teamet som byggde system för krypteringsnyckelhantering och maskinautentisering vid en tidpunkt då Intuit var ett av de första stora företagen som flyttade till molnet. Det som blev tydligt för mig var att varje organisation som antog molnet så småningom skulle ställas inför samma problem som vi löste internt: hur man hanterar hemligheter och nycklar över distribuerad, dynamisk infrastruktur. Att bygga detta internt kräver enorma tekniska resurser, och det har ingen mening att varje företag ska återskapa det. Det logiska svaret var en SaaS-modell.

Fällan var förtroende. Detta är den känsligaste information som ett företag äger, och ingen allvarlig organisation kommer att ge en tredje part möjlighet att komma åt det. Så kraven var nästan motsägelsefulla: leverera det som SaaS för skala och enkelhet, men gör det arkitektoniskt omöjligt för leverantören att någonsin se kundens data. Den spänningen är exakt vad som gav upphov till Distribuerad Fragmentskryptografi (DFC). DFC låter oss köra en fullständigt hanterad SaaS-kontrollplan medan kunden håller en fragment som vi aldrig besitter, så vi är matematiskt oförmögna att komma åt deras nycklar. Det blev grunden för SaaS plus Nollkunskapsmodellen som Akeyless byggs på.

Den ursprungliga visionen handlade om att skydda mänsklig och maskinåtkomst i molnet. AI-agenter är den naturliga och mest extrema utvidgningen av samma problem. De är icke-mänskliga identiteter som opererar på en skala och hastighet som ingen katalog är utformad för, och samma Nollkunskaps-, identitetscentrerade grundval utvidgas nu direkt till dem.

Du tillskrivs som arkitekten bakom Akeyless patenterade Zero-Trust-krypteringsteknologi. Vilka var de största tekniska utmaningarna i att bygga en säkerhetsmodell som kunde eliminera antaganden om förtroende samtidigt som den förblev praktisk för stora företag?

Det svåraste var att göra “lita på ingen” praktiskt snarare än akademiskt. De flesta delade nycklar eller hemligsshare-scheman samlar fortfarande in den fullständiga nyckeln vid någon tidpunkt, vanligtvis inom en enda process, HSM eller enclave vid tidpunkten för en kryptografisk operation. Det korta fönstret är exakt vad angripare, illvilliga insiders och rättsliga tvångsscenarier riktar sig mot.

Med DFC är nyckeln aldrig sammansatt, inte vid skapande, inte i vila och inte under användning. Fragment genereras oberoende i separata förtroendedomäner, och kryptografiska operationer körs som en distribuerad beräkning där varje fragmentinnehavare beräknar sin andel lokalt och endast delvisa resultat utbyts. Den tekniska utmaningen var att uppnå detta med den latens, genomströmning och tillförlitlighet som stora företag kräver i produktion.

En andra utmaning, och en av de mest betydande, var att möjliggöra kontinuerlig förnyelse av fragmenten. Vi var tvungna att kunna ersätta varje fragment med ett nytt matematiskt värde, på varje plats, medan den underliggande huvudnyckel som fragmenten representerar förblev oförändrad och den kryptografiska processen aldrig stördes. Detta tillade ett mycket betydande lager av säkerhet till lösningen. Eftersom en angripare inte längre kan samla in fragment tålmodigt över tid, är ett fragment som infångades förra veckan matematiskt orelaterat till de fragment som existerar idag, så det är brus snarare än en försprång. För att lära sig något om en nyckel skulle en motståndare behöva kompromettera varje fragmentplats samtidigt, inom ett enda förnyelsefönster, och det kravet växer exponentiellt svårare allt eftersom platser, förtroendedomäner och förnyelsefrekvens ökar. Kombinerat med allt-eller-inget-tröskeln, där 100 procent av fragmenten behövs för att avslöja något och varje strikt delmängd läcker noll information, förvandlar förnyelse säkerhetsmodellen från en statisk garanti till en tidbunden.

Många organisationer tävlar om att distribuera AI-agenter, men identitetssäkerhet förblir ofta en eftertanke. Vilka är de vanligaste misstagen som företag gör när de ger AI-agenter åtkomst till företagssystem och känslig data?

Det största misstaget är att behandla en agent som en tjänstekonto och ge den en statisk, långlivad API-nyckel. Den autentiseringsuppgiften blir en permanent, skördbar tillgång som sitter inuti en icke-deterministisk, prompt-injicerbar aktör.

Andra vanliga fel jag ser: att bevilja stående behörigheter istället för bara-i-tid-åtkomst, förlita sig på grova rollbaserade behörigheter som beskriver vad en agent kan nå men aldrig vad den avser att göra, ge agenter direkt nätverksväg till databaser och API:er så att en kompromettering blir lateralt rörelse, och ha ingen revisionskedja som binder en agentåtgärd tillbaka till den mänskliga prompten och utlösaren som utlöste den. Var och en av dessa är ett försök att återanvända mänskliga kontroller på något som inte beter sig som en människa.

Akeyless har hävdat att AI-agenter kräver en grundligt annorlunda identitetsmodell än människor eller traditionella maskinbelastningar. Vad gör AI-agenter unikt svåra att skydda jämfört med befintliga IAM- och PAM-ramverk?

Felkällan är att behandla AI-agenter som en ny typ av användare, eller till och med en ny typ av tjänstekonto, och anta att de kan påbörjas och styras som mänskliga identiteter. Det är en kategori-fel, av flera sammanhängande skäl.

Agentidentiteter är inte uppräkneliga. Den specifika instans du vill styra existerar vanligtvis inte än, och när den gör det, är den redan borta. En agent kan starta på en Lambda, köra i 800 millisekunder och försvinna innan någon skanner märker det, eller generera kedjor av underagenter över VM, containrar och serverlösa som slutförs på några sekunder. Att registrera dessa i en katalog är att behandla spöken som boende: när posten begärs, är den enhet som beskrevs borta.

Rätt ankare är därför inte agenten, utan arbetsbelastningsidentiteten som dess körning redan utfärdar, AWS-körningsrollen, Kubernetes-tjänstekontotoken, OIDC-federationen och standarder som SPIFFE/SPIRE som redan är beprövade i produktion och tvärsubstrat. Auktorisering kommer att uttryckas som relationer mellan autentiseringsmetoder och målsystem snarare än mellan namngivna identiteter och omfång. Och tyngdpunkten kommer att vara en körningsenhet på en gateway som förmedlar varje åtgärd, klassificerar avsikt, injicerar efemära autentiseringsuppgifter, maskerar känsliga svar och producerar en fullständig rättskedja. Identitet har fortfarande betydelse, men den faller på plats bakom verkställighet snarare än framför den. Den körningsmyndighetslagret, som sitter på samma plattform som redan styr mänsklig och maskinåtkomst, är vad jag tror att varje företag som kör agenter i produktion kommer att behöva.

Det pågår en diskussion om “hemlighetslösa” arkitekturer för AI-system. Hur definierar du hemlighetslös autentisering, och varför tror du att statiska autentiseringsuppgifter och API-nycklar blir ohållbara i AI-agenternas tidevarv?

Hemlighetslös autentisering innebär att agenten aldrig har en autentiseringsuppgift alls. Istället för att ge agenten en nyckel som den måste lagra och presentera, autentiserar agenten genom sin naturliga arbetsbelastningsidentitet, och en kortlivad, just-i-tid-autentiseringsuppgift injiceras i en förmedlad session vid tidpunkten för körning, sedan förstörs när sessionen slutar. Agenten ser aldrig den.

Statiska autentiseringsuppgifter och API-nycklar blir ohållbara av en enkel anledning: en hemlighet som en agent har är en hemlighet som en angripare kan stjäla. I en värld där aktören som håller autentiseringsuppgiften kan injiceras med en prompt eller hallucinera, blir en långlivad nyckel varje komprometterad agent till en nyckelläcka. Ta bort autentiseringsuppgiften från agenten och en komprometterad agent har ingenting att läcka. Det är hela poängen med vad vi kallar SecretlessAI.

När AI-agenter får förmåga att planera, utföra åtgärder och interagera med flera system oberoende, vilka nya attackvektorerna oroar dig mest under de kommande tre till fem åren?

Attackvektorerna som oroar mig mest alla härrör från att agenter kan planera och agera över system oberoende. Promptinjektion som kapar en agents avsikt mitt i en uppgift är den tydligaste, eftersom identiteten förblir giltig även om beteendet blir skadligt. Utöver detta oroar jag mig för agent-till-agent-överföringar där auktoritet överförs längs en kedja utan tydligt ansvar, lateralt rörelse genom agenter som har direkt nätverksåtkomst och dataexfiltration där en överbehörig agent hämtar mycket mer än vad dess uppgift kräver.

Gemensamt för alla är att autentiseringsuppgiften och rollen kan vara fullständigt legitima medan åtgärden inte är det. Försvar som bara kontrollerar behörighet, inte syfte, kommer inte att fånga någon av dessa. Det är därför som avsiktssmedveten verkställighet på en gateway, på varje enskild åtgärd, är den kontroll jag tror kommer att ha störst betydelse.

Vi ser en förändring från att skydda mänskliga identiteter till att skydda maskin- och agentidentiteter. Hur ser du på balansen av säkerhetsprioriteringar som förändras när organisationer börjar hantera miljontals icke-mänskliga identiteter över sin infrastruktur?

Vi går in i en värld där den överväldigande majoriteten av systemåtkomst utförs av icke-mänskliga identiteter, maskiner, arbetsbelastningar och nu agenter, men de flesta verktyg förutsätter fortfarande att en människa finns bakom tangentbordet. Resultatet är hemligheter överallt, stående behörigheter och identiteter som ingen kan fullständigt spåra.

Förändringen i prioriteringar är från periodiska, mänskligt tempo-kontroller till kontinuerlig, körningstid-verkställighet i maskinskala. När du hanterar miljontals icke-mänskliga identiteter kan du inte förlita dig på registrering, certifieringskampanjer och kvartalsvisa åtkomstgranskningar. Du behöver efemär-till-konstruktion-identitet, noll stående behörighet och policy som utvärderas automatiskt på varje åtgärd. Mänsklig identitetssäkerhet försvinner inte, men den blir en mindre del av ytan, och arkitekturen måste byggas för den icke-mänskliga majoriteten först.

Senaste forskningen tyder på att AI-agenter redan kan komma åt information utöver deras avsedda behörigheter. Vilka styrningar och körningstidskontroller bör organisationer ha på plats innan de tillåter agenter att operera autonomt i produktionsmiljöer?

Innan någon agent opererar autonomt i produktion, skulle jag vilja ha några saker på plats. Först, inga stående autentiseringsuppgifter på agenten, med bara-i-tid, kortlivad åtkomst injicerad per session. Andra, ingen direkt nätverksväg, så varje agentåtgärd förmedlas genom en obligatorisk flaskhals snarare än att nå databaser och API:er direkt. Tredje, avsiktssmedveten policyverkställighet som utvärderar syftet med en begäran mot dess ursprungliga prompt innan någon autentiseringsuppgift utfärdas, så en agent som får i uppdrag att analysera intäkter inte kan utfärda en destruktiv kommando. Fjärde, i-session-inspektion och svarsmaskering så känslig data som PII och PHI är redigerad innan den kommer in i agentens kontextfönster. Och femte, en enda oföränderlig revisionspost som binder den mänskliga prompten, den klassificerade avsikten, policyutlåtandet, sessionen och den slutliga åtgärden.

Upptäckt och synlighet är också viktiga, men som ingångar till policy, inte som en förutsättning för skydd. Du bör kunna styra en agent första gången den autentiserar, även om du aldrig har sett den specifika instansen tidigare.

Branschen fokuserar ofta på modellsäkerhet, men mindre uppmärksamhet ges till identitet, auktorisering och åtkomstkontroll. Varför tror du att dessa områden kommer att bli några av de viktigaste säkerhetsutmaningarna under AI-eran?

Modellsäkerhet får rubrikerna, men en perfekt justerad modell måste fortfarande agera i den verkliga världen, och i och med att den agerar, behöver den åtkomst till system och data. Den åtkomsten är där den faktiska skadan sker. En modell som aldrig rör en databas kan inte exfiltrera den.

Auktorisering är också den svåraste delen av agentic-säkerhet, eftersom aktören är icke-deterministisk och efemär. Du kan inte lösa det enbart på modellnivå, och du kan inte lösa det med statiska roller. Det kräver kontinuerlig, avsiktssmedveten verkställighet på en gateway, på varje enskild åtgärd. Det är oglamoröst infrastrukturarbete, vilket är exakt varför det är underdiskuterat och exakt varför det kommer att visa sig vara ett av de mest betydelsefulla säkerhetsproblemen under denna era.

Om du ser framåt, tror du att företag kommer att kräva ett dedikerat identitetsskikt för AI-agenter, liknande hur identitetsleverantörer blev nödvändiga för mänskliga användare, och vad skulle den framtida arkitekturen se ut?

Ja, men det kommer inte att se ut som den mänskliga identitetsleverantörsmodellen enbart omformad för agenter. Att bygga en katalog av agenter är att bygga en katalog för spöken, identiteter som är borta innan du slutar registrera dem.

Agentidentitetsskiktet jag förväntar mig kommer att anknyta identitet till arbetsbelastningen som körningen utfärdar, moln IAM, Kubernetes-tjänstekonton, OIDC-federation och standarder som SPIFFE/SPIRE som redan är beprövade i produktion och tvärsubstrat. Auktorisering kommer att uttryckas som relationer mellan autentiseringsmetoder och målsystem snarare än mellan namngivna identiteter och omfång. Och tyngdpunkten kommer att vara en körningstid-verkställighetsplan, en gateway som förmedlar varje åtgärd, klassificerar avsikt, injicerar efemära autentiseringsuppgifter, maskerar känsliga svar och producerar en fullständig rättskedja. Identitet har fortfarande betydelse, men den faller på plats bakom verkställighet snarare än framför den. Den körningsmyndighetslagret, som sitter på samma plattform som redan styr mänsklig och maskinåtkomst, är vad jag tror att varje företag som kör agenter i produktion kommer att behöva.

Tack för den utmärkta intervjun, läsare som vill lära sig mer bör besöka Akeyless.