Refael Angel, mede-oprichter en CTO van Akeyless – Interviewreeks

Refael Angel, mede-oprichter en CTO van Akeyless, is een leider in cybersecurity en software engineering met diepgaande ervaring in cloudbeveiliging, encryptie, machine-authenticatie en enterprise-infrastructuur. Sinds de oprichting van Akeyless in 2018 heeft hij geholpen om het bedrijf op te bouwen rondom moderne geheimenbeheer en identiteitsbeveiliging voor cloud-native omgevingen. Voordat hij bij Akeyless kwam, werkte hij als senior software engineer in Security bij Intuit (INTU ), waar hij systemen bouwde voor publieke cloud-encryptiesleutelbeheer en machine-authenticatie, en hands-on ervaring opdeed met AWS, Go, Python, Java, PHP, Bash, Linux, Git en Jenkins. Eerder in zijn carrière had Angel software engineering-rollen bij 3D Systems (DDD ) en Cimatron, waar hij CAD/CAM- en Windows-gebaseerde applicaties ontwikkelde met C/C++, C#, WPF, MFC en object-georiënteerde ontwerppatronen.

Akeyless is een identiteitsbeveiligingsbedrijf dat zich richt op het beveiligen van machines, AI-agents en mensen via een cloud-native platform dat is gebouwd rondom zero-knowledge-cryptografie. Het platform combineert geheimenbeheer, encryptiesleutelbeheer, certificaatlevenscyclusbeheer, bevoorrechte toegang en machine-identiteitsbeveiliging, waardoor organisaties een uniforme manier hebben om referenties, sleutels, certificaten en toegang te beheren in hybride, multi-cloud-, DevOps- en AI-omgevingen. De positionering van het bedrijf weerspiegelt een bredere verschuiving in cybersecurity: naarmate workloads, services en AI-agents steeds vaker systeemtoegang uitvoeren zonder directe menselijke betrokkenheid, hebben bedrijven sterkerere controles nodig rondom niet-menselijke identiteiten, kortstondige referenties, geautomatiseerde rotatie en runtime-governance.

U bent mede-oprichter van Akeyless in 2018, nadat u encryptiesleutelbeheer- en machine-authenticatiesystemen had gebouwd bij Intuit. Welke lacune in cloudbeveiliging en identiteitsbeheer overtuigde u ervan dat het tijd was om Akeyless op te richten, en hoe is die oorspronkelijke visie geëvolueerd nu AI-agents zijn opgekomen als een nieuwe klasse van digitale identiteiten?

Bij Intuit was ik deel van het team dat encryptiesleutelbeheer- en machine-authenticatiesystemen bouwde op een moment dat Intuit een van de eerste grote ondernemingen was die naar de cloud verhuisden. Wat voor mij duidelijk werd, was dat elke organisatie die de cloud aannam, uiteindelijk hetzelfde probleem zou tegenkomen dat wij intern oplosten: hoe geheimen en sleutels te beheren in gedistribueerde, dynamische infrastructuur. Het opbouwen hiervan kost enorm veel engineeringsbronnen, en het heeft geen zin dat elk bedrijf dit zelf moet uitvinden. Het logische antwoord was een SaaS-model.

De valkuil was vertrouwen. Dit is het meest gevoelige materiaal dat een onderneming bezit, en geen enkel serieus bedrijf zal een derde partij de mogelijkheid geven om toegang te krijgen. Dus de eis was bijna tegenstrijdig: het moet als SaaS worden geleverd voor schaal en eenvoud, maar het moet architectonisch onmogelijk zijn voor de leverancier om ooit de klantgegevens te zien. Die spanning is precies wat de geboorte van Distributed Fragments Cryptography (DFC) teweegbracht. DFC laat ons toe om een volledig beheerd SaaS-controlevlak uit te voeren, terwijl de klant een fragment bezit dat wij nooit in bezit hebben, zodat wij wiskundig niet in staat zijn om toegang te krijgen tot hun sleutels. Dat werd de basis van het SaaS plus Zero-Knowledge-model waarop Akeyless is gebouwd.

De oorspronkelijke visie was gericht op het beveiligen van menselijke en machine-toegang in de cloud. AI-agents zijn de natuurlijke en meest extreme uitbreiding van hetzelfde probleem. Zij zijn niet-menselijke identiteiten die opereren op een schaal en snelheid waarvoor geen enkel directory is ontworpen, en dezelfde Zero-Knowledge, identiteitsgerichte basis wordt nu rechtstreeks uitgebreid tot hen.

U wordt gecrediteerd als de architect achter Akeyless’ gepatenteerde Zero-Trust-encryptietechnologie. Wat waren de grootste technische uitdagingen bij het opbouwen van een beveiligingsmodel dat vertrouwensveronderstellingen kon elimineren en toch praktisch was voor grote ondernemingen?

Het moeilijkste deel was “vertrouw niemand” praktisch maken in plaats van academisch. De meeste split-key- of geheime-delingschema’s assembleren de volledige sleutel nog steeds op een bepaald moment, meestal binnen een enkel proces, HSM of enclave op het moment van een cryptografische bewerking. Dat korte venster is precies wat aanvallers, kwaadwillige insiders en juridische dwangscenario’s richten.

Met DFC wordt de sleutel nooit geassembleerd, niet bij het maken, niet in ruste en niet tijdens het gebruik. Fragmenten worden onafhankelijk gegenereerd in afzonderlijke vertrouwensdomeinen, en cryptografische bewerkingen worden uitgevoerd als een gedistribueerde berekening waarbij elke fragmentbezitter zijn aandeel lokaal berekent en alleen gedeeltelijke resultaten worden uitgewisseld. De engineeringsuitdaging was het bereiken hiervan met de latentie, doorvoer en betrouwbaarheid die grote ondernemingen in productie eisen.

Een tweede uitdaging, en een van de belangrijkste, was het mogelijk maken van continue vernieuwing van de fragmenten. We moesten in staat zijn om elk fragment te vervangen door een nieuwe wiskundige waarde, op elke locatie, terwijl de onderliggende master-sleutel die de fragmenten vertegenwoordigen onveranderd bleef en het cryptografische proces nooit werd onderbroken. Dit voegde een zeer substantiële laag beveiliging toe aan de oplossing. Omdat fragmenten kunnen worden vernieuwd, kan een aanvaller niet langer fragmenten verzamelen. Een fragment dat vorige week is vastgelegd, is wiskundig niet gerelateerd aan de fragmenten die vandaag bestaan, dus het is ruis in plaats van een voorsprong. Om iets over een sleutel te leren, zou een aanvaller elk fragmentlocatie tegelijkertijd moeten compromitteren, binnen een enkel vernieuwingsvenster, en die eis wordt exponentieel moeilijker naarmate locaties, vertrouwensdomeinen en vernieuwingsfrequentie toenemen. In combinatie met de all-or-nothing-drempel, waarbij 100% van de fragmenten nodig is om iets te onthullen en elke strikte deelverzameling geen informatie lekt, verandert de vernieuwing het beveiligingsmodel van een statische garantie in een tijdsgebonden garantie.

Veel organisaties zijn bezig met het implementeren van AI-agents, maar identiteitsbeveiliging blijft vaak een ondergeschikte overweging. Wat zijn de meest voorkomende fouten die bedrijven maken wanneer ze AI-agents toegang geven tot bedrijfssystemen en gevoelige gegevens?

De grootste fout is het behandelen van een agent als een serviceaccount en het geven van een statische, langdurige API-sleutel. Die referentie wordt een permanent, oogstbaar actief dat zich in een niet-deterministische, injecteerbare actor bevindt.

Andere veelvoorkomende fouten die ik zie: het verlenen van permanente privileges in plaats van alleen just-in-time-toegang, het vertrouwen op grove rolgebaseerde machtigingen die beschrijven wat een agent kan bereiken maar nooit wat hij van plan is te doen, het geven van agents directe netwerkpaden naar databases en API’s, zodat een compromittering laterale beweging wordt, en het ontbreken van een auditketen die een agentactie koppelt aan de mens en de prompt die het heeft geactiveerd. Elk van deze is een poging om menselijke controles te retrofitten op iets dat niet als een mens gedraagt.

Akeyless heeft betoogd dat AI-agents een fundamenteel ander identiteitsmodel nodig hebben dan mensen of traditionele machine-werkbelastingen. Wat maakt AI-agents uniek moeilijk te beveiligen in vergelijking met bestaande IAM- en PAM-kaders?

De kernfout is het behandelen van AI-agents als een nieuw type gebruiker, of zelfs een nieuw type serviceaccount, en het aannemen dat ze kunnen worden ingeschreven en beheerd zoals menselijke identiteiten. Dat is een categorie-fout, om een aantal verbonden redenen.

Agent-identiteiten zijn niet te tellen. Het specifieke exemplaar dat u wilt beheren, bestaat meestal nog niet, en tegen de tijd dat het wel bestaat, is het alweer verdwenen. Een agent kan op een Lambda opstarten, 800 milliseconden draaien en verdwijnen voordat een enkele scanner het opmerkt, of ketens van sub-agents over VM’s, containers en serverless creëren die in seconden zijn voltooid. Het registreren van deze in een directory is het behandelen van spoken als inwoners: tegen de tijd dat de inschrijving is voltooid, is de entiteit die het beschrijft, verdwenen.

Het juiste anker is daarom niet de agent, maar de workload-identiteit die de runtime al verstrekt, de AWS-uitvoeringsrol, de Kubernetes-serviceaccounttoken, de SPIFFE SVID. Die identiteit bestaat al, wordt gewaarborgd door het platform waarop de agent draait, en verdwijnt wanneer de agent verdwijnt. Omdat de identiteiten ephemeren zijn, zijn de enige stabiele entiteiten om beleid tussen te schrijven de auth-methoden en de doelsystemen, niet genoemde identiteiten en scopes.

En dit is waar bestaande IAM en PAM het meest beslissend breken: statische RBAC en ABAC kunnen een niet-deterministische actor niet bevatten. Een agent met een perfect gescoord token en een perfect afgedwongen TTL kan nog steeds prompt-injectie ondergaan, een destructieve query hallucineren of pivoteren van een leestaak naar een schrijftaak in dezelfde sessie, zonder enige beleidsschending zichtbaar op het autorisatievlak. RBAC en ABAC worden op het moment van authenticatie beoordeeld, niet erna, omdat wat erna gebeurt wordt besloten door een LLM die naar een contextwindow kijkt die de beleidsauteur niet kan zien.

Agents zijn uniek moeilijk omdat ze ephemeren, niet-deterministisch, multi-substraat en prompt-injecteerbaar zijn, allemaal tegelijk. De ontbrekende laag is geen beter directory. Het is intentiebewuste afdwinging op elke actie, bemiddeld door een gateway die controleert wat de agent daadwerkelijk doet tegen wat het zei dat het zou doen, voordat enige referentie wordt geslagen. Dat is de ontbrekende laag.

Er is een groeiend debat over “geheimloze” architectuur voor AI-systemen. Hoe definieert u geheimloze authenticatie, en waarom denkt u dat statische referenties en API-sleutels onhoudbaar worden in de tijd van autonome agents?

Geheimloze authenticatie betekent dat de agent nooit een referentie in bezit heeft. In plaats van de agent een sleutel te geven die het moet opslaan en presenteren, authenticeren de agent via zijn native workload-identiteit, en een kortstondige, just-in-time-referentie wordt ingespoten in een bemiddelde sessie op het moment van uitvoering, en vervolgens vernietigd wanneer de sessie eindigt. De agent ziet het nooit.

Statische referenties en API-sleutels worden onhoudbaar om een eenvoudige reden: een geheim dat een agent in bezit heeft, is een geheim dat een aanvaller kan stelen. In een wereld waar de actor die de referentie in bezit heeft, prompt-injectie kan ondergaan of hallucineren, wordt een langdurige sleutel een permanent, oogstbaar actief dat in elke gecompromitteerde agent zit. Verwijder de referentie uit de agent en een gecompromitteerde agent heeft niets om te lekken. Dat is het hele punt van wat we SecretlessAI noemen.

Naarmate AI-agents de mogelijkheid krijgen om te plannen, acties uit te voeren en onafhankelijk met meerdere systemen te communiceren, welke nieuwe aanvalsvectoren maken u het meest bezorgd in de komende drie tot vijf jaar?

De vectoren die mij het meest zorgen baren, stammen allemaal uit het feit dat agents in staat zijn om te plannen en onafhankelijk te handelen over systemen heen. Prompt-injectie die een agent zijn intentie midden in een taak overneemt, is de meest voor de hand liggende, omdat de identiteit nog steeds geldig is, zelfs als het gedrag kwaadwillig wordt. Verder maak ik me zorgen over agent-tot-agent-overdrachten waarbij autoriteit langs een keten wordt doorgegeven zonder duidelijke verantwoordelijkheid, laterale beweging via agents die directe netwerktoegang hebben, en gegevensuitstroom waarbij een over-geautoriseerde agent veel meer trekt dan zijn taak vereist.

De gemeenschappelijke draad is dat de referentie en de rol perfect legitiem kunnen zijn, terwijl de actie dat niet is. Verdedigingen die alleen machtiging controleren, niet doel, zullen geen van deze vangen. Dat is waarom intentiebewuste afdwinging op een gateway, op elke enkele actie, de controle is die ik geloof dat het meest zal tellen.

We zien een verschuiving van het beveiligen van menselijke identiteiten naar het beveiligen van machine- en agent-identiteiten. Hoe ziet u de verandering in de balans van beveiligingsprioriteiten als organisaties beginnen met het beheren van miljoenen niet-menselijke identiteiten over hun infrastructuur?

We gaan een wereld binnen waarin de overgrote meerderheid van systeemtoegang wordt uitgevoerd door niet-menselijke identiteiten, machines, workloads en nu agents, maar de meeste tooling gaat er nog steeds van uit dat er een mens achter de knoppen zit. Het resultaat is geheimen overal, permanente privileges en identiteiten die niemand volledig kan bijhouden.

De verschuiving in prioriteiten is van periodieke, mens-georiënteerde controles naar continue, runtime-afdwinging op machine-schaal. Wanneer u miljoenen niet-menselijke identiteiten beheert, kunt u niet vertrouwen op inschrijving, certificeringscampagnes en kwartaal- toegangstoezichten. U hebt ephemere, door constructie, identiteit nodig, geen permanente privileges en beleid dat automatisch op elke actie wordt geëvalueerd. Menselijke identiteitsbeveiliging gaat niet weg, maar het wordt een kleinere fractie van het oppervlak, en de architectuur moet worden gebouwd voor de niet-menselijke meerderheid eerst.

Recent onderzoek suggereert dat AI-agents mogelijk al toegang hebben tot informatie die verder gaat dan hun bedoelde machtigingen. Welke governance- en runtime-controles moeten organisaties hebben voordat ze agents toestaan om autonoom te opereren in productieomgevingen?

Voordat enig agent autonoom in productie werkt, zou ik een aantal dingen willen hebben. Ten eerste, geen permanente referenties op de agent, met alleen just-in-time, kortstondige toegang die per sessie wordt ingespoten. Ten tweede, geen directe netwerkpaden, zodat elke agentactie wordt bemiddeld door een verplichte flessenhals in plaats van rechtstreeks toegang te krijgen tot databases en API’s. Ten derde, intentiebewuste beleidsafdwinging die de doelstelling van een verzoek evalueert tegen wat het zei dat het zou doen, voordat enige referentie wordt geslagen, zodat een agent die wordt gevraagd om omzet te analyseren, geen destructieve opdracht kan geven. Ten vierde, in-sessie-inspectie en responsmaskering, zodat gevoelige gegevens zoals PII en PHI worden gemaskeerd voordat ze de contextwindow van de agent binnenkomen. En ten vijfde, een enkele onveranderbare auditrecord die de menselijke prompt, de geclassificeerde intentie, het beleidsvonnis, de sessie en de finale actie koppelt.

Ontdekking en zichtbaarheid zijn ook belangrijk, maar als invoer voor beleid, niet als een vereiste voor bescherming. U moet in staat zijn om een agent te beheren de eerste keer dat het zich aanmeldt, zelfs als u nog nooit eerder dat specifieke exemplaar hebt gezien.

De industrie richt zich vaak op modelveiligheid, maar minder aandacht wordt besteed aan identiteit, autorisatie en toegangscontrole. Waarom denkt u dat deze gebieden enkele van de belangrijkste beveiligingsuitdagingen van de AI-tijdperk zullen worden?

Modelveiligheid krijgt de koppen, maar een perfect afgestemd model moet nog steeds handelen in de echte wereld, en op het moment dat het handelt, heeft het toegang nodig tot systemen en gegevens. Die toegang is waar de daadwerkelijke schade gebeurt. Een model dat nooit een database aanraakt, kan geen gegevens uitstroomen. Het risico materialiseert zich op de autorisatiegrens.

Autorisatie is ook het moeilijkste deel van agentic beveiliging, omdat de actor niet-deterministisch en ephemeren is. U kunt het niet puur op het modelniveau oplossen, en u kunt het niet oplossen met statische rollen. Het vereist continue, intentiebewuste afdwinging op elke actie. Dat is onopvallend infrastructuurwerk, wat precies is waarom het onderbesproken is en precies waarom het een van de meest consequente beveiligingsproblemen van deze tijdperk zal worden.

Kijkend naar de toekomst, denkt u dat ondernemingen uiteindelijk een speciale identiteitslaag voor AI-agents nodig zullen hebben, vergelijkbaar met hoe identiteitsproviders essentieel werden voor menselijke gebruikers, en hoe zou die toekomstige architectuur eruitzien?

Ja, maar het zal er niet uitzien als het menselijke identiteitsprovidermodel dat eenvoudigweg is omgedoopt voor agents. Proberen om een directory van agents te bouwen, is het bouwen van een directory voor spoken, identiteiten die verdwenen zijn voordat u klaar bent met inschrijven.

De agent-identiteitslaag die ik verwacht, zal identiteit ankeren aan de workload die de runtime verstrekt, cloud-IAM, Kubernetes-serviceaccounts, OIDC-federatie en standaarden zoals SPIFFE/SPIRE die al productie-proef zijn en cross-substraat. Autorisatie zal worden uitgedrukt als relaties tussen auth-methoden en doelsystemen, in plaats van tussen genoemde identiteiten en scopes. En het zwaartepunt zal een runtime-afdwingingsvlak zijn, een gateway die elke actie bemiddelt, intentie classificeert, ephemere referenties inspoten, gevoelige antwoorden maskeert en een volledige forensische keten produceert. Identiteit is nog steeds belangrijk, maar het valt op zijn plaats achter afdwinging, in plaats van ervoor. Dat runtime-autoriteitslaag, dat op hetzelfde platform zit dat al menselijke en machine-toegang regeert, is wat ik geloof dat elk bedrijf dat agents in productie draait, uiteindelijk nodig zal hebben.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Akeyless bezoeken.