Micha Rave, CEO en mede-oprichter van Hush Security – Interviewreeks

Micha Rave, CEO en mede-oprichter van Hush Security, is een ervaren cybersecurity‑ en technologie‑executive wiens loopbaan zich uitstrekt over software‑engineering, productmanagement, enterprise‑netwerken, cloud‑beveiliging en identiteit. Voor hij Hush Security mede‑stichtte in 2024, werkte hij meer dan vijf jaar bij Proofpoint als Senior Director of Product Management voor Cloud Security, waar hij verantwoordelijk was voor de productlijnen Zero Trust Network Access (ZTNA) en Secure Web Gateway (SWG). Eerder was hij VP of Product Management bij Meta Networks, met focus op enterprise‑netwerken en beveiliging, en bekleedde hij product‑ en engineering‑leiderschapsrollen bij HARMAN International, Redbend, SanDisk, Hola, Jungo en Elbit Systems. Zijn achtergrond combineert hands‑on software‑ontwikkeling met meer dan twee decennia ervaring in het bouwen en commercialiseren van beveiligings‑, netwerk‑, virtualisatie‑ en embedded‑technologieproducten.

Hush Security is een cybersecurity‑bedrijf dat zich richt op het beveiligen van AI‑agents en andere niet‑menselijke identiteiten door langlevende inloggegevens en statische geheimen te vervangen door identiteits‑gebaseerde, beleids‑gestuurde toegang. Het platform ontdekt AI‑agents, inclusief shadow‑agents en intern ontwikkelde agents, kent hen verifieerbare identiteiten toe en beheert hun interacties met enterprise‑systemen met behulp van scoped, just‑in‑time‑rechten, gecentraliseerde beleidsregels en controleerbare activiteitslogboeken. Het bedrijf werd opgericht door beveiligingsveteranen van het team achter Meta Networks, dat Proofpoint in 2019 overnam. In juli 2026 haalde Hush een Series A van $30 miljoen op, waarbij Akamai Technologies als strategische investeerder toetreedt naast Battery Ventures en YL Ventures, waardoor de totale financiering stijgt naar $41 miljoen terwijl het bedrijf zijn technologie uitbreidt voor het beheren van enterprise‑AI‑agents en niet‑menselijke infrastructuur.

Voordat je Hush Security oprichtte, heb je jaren besteed aan het bouwen en leiden van beveiligingsproducten, waaronder cloud‑beveiliging bij Proofpoint. Wat zag je op de markt dat je overtuigde dat er een behoefte was om Hush te starten, en hoe is die oorspronkelijke these geëvolueerd met de snelle opkomst van agent‑AI?

Bij Proofpoint zagen we bedrijven die menselijke identiteit oplossen, terwijl alles niet‑menselijks nog draaide op statische geheimen. Service‑accounts, workloads, pipelines, allemaal authenticerend met sleutels die niemand bezat en die nooit verloopt. De industrie reageerde met betere kluizen. Dat is een betere kluis, geen oplossing.

De oprichtings‑these was om niet‑menselijke toegang te verplaatsen van geheimen naar identiteit. Verifieerbare workload‑identiteit, kort‑levende inloggegevens die just‑in‑time worden uitgegeven, beleid inline afgedwongen. Geen code‑aanpassingen.

Agent‑AI maakte dat urgent. Een agent is een NHI die op runtime redeneert en beslist welke tools aangeroepen moeten worden. Geef het een statische sleutel en je geeft autonome software permanente toegang tot productie, en agents worden buiten elk wijzigingsproces geleverd; een ontwikkelaar zet dinsdag een MCP‑server op en tegen vrijdag raakt hij klantgegevens aan.

De these veranderde niet. De reikwijdte wel. Identiteits‑gebaseerde toegang was het juiste antwoord voor workloads. Voor agents is het het enige werkbare: ken elke bestaande agent, geef elke agent standaard de minste agency, en audit elke actie. Mensen kregen een IdP. Agents hebben er ook één nodig en dat is Hush.

Hush stelt dat enterprise‑AI‑agents hun eigen identiteiten en gedelegeerde permissies moeten hebben in plaats van simpelweg de toegangsrechten van de mensen die ze gebruiken over te nemen. Waarom hebben traditionele Identity and Access Management (IAM)‑systemen moeite met autonome agents, en wat moet er veranderen?

Het voor de hand liggende geval is een agent die namens een gebruiker handelt. Het moeilijkere geval is een agent zonder enige gebruiker: een geplande taak, een autonome SOC‑responder, een pipeline die zelfstandig redeneert en handelt. Er is niemand van wie gedelegeerd kan worden, dus vallen teams terug op het enige instrument dat ze hebben, een statisch service‑account met brede permissies en een sleutel die nooit verloopt. Dat is hetzelfde shared‑secret‑model dat al een decennium faalt, nu gekoppeld aan software die improviseert.

De systemen aan de andere kant maken het nog erger. De meeste interne API’s, databases en MCP‑servers voeren geen echte autorisatie uit. Ze controleren of je een geldig token bezit, niet wat je ermee mag doen. Bezit is gelijk aan toestemming.

Wat er moet veranderen: elke agent krijgt zijn eigen identiteit, cryptografisch uitgegeven, ongeacht of er een mens achter zit. Toegang wordt per actie verleend, kort‑levend en scoped, met beleid inline afgedwongen in plaats van vertrouwd op het doelsysteem. Wanneer er een gebruiker is, zijn de permissies van de agent de intersectie van wat de gebruiker mag en wat die agent mag doen voor die taak. Wanneer er geen gebruiker is, vormen de eigen identiteit en het beleid van de agent het volledige verhaal. Mensen kregen least privilege. Agents hebben least agency nodig.

Je gebruikt het concept “least agency” bij het bespreken van AI‑beveiliging. Hoe verschilt least agency van het traditionele cybersecurity‑principe van least privilege, en hoe kunnen organisaties precies bepalen wat een AI‑agent mag doen voor een specifieke taak?

Agents hebben geen vast gedrag. Geef er één lees‑toegang tot een CRM en schrijfrechten voor e‑mail en je hebt niet twee permissies verleend, maar elke mogelijke route ertussen. Least privilege begrenst wat een agent kan aanraken. Het zegt niets over wat hij ermee moet doen.

Least agency voegt de ontbrekende dimensie toe: welke acties, voor welke taak, op dit moment. Een agent die tickets triageert moet kunnen lezen en reageren. Hij hoeft geen tickets te sluiten, te verwijderen of facturering aan te raken, zelfs niet als het token dat toestaat. Wanneer de taak eindigt, eindigt de toegang.

Beslissen wat is toegestaan begint met observatie, niet met giswerk. Laat de agent draaien, kijk wat hij daadwerkelijk aanroept, en laat dat de basislijn bepalen. Vernauw vervolgens met drie inputs: de taak waarvoor hij bestaat, de gebruiker waarvoor hij handelt (nooit meer dan die gebruiker zelf kan doen), en de impactradius van elke actie, omdat het plaatsen van een reactie en het uitvoeren van een betaling niet hetzelfde goedkeuringspad mogen delen.

Dankzij het principe van minste privileges wordt bepaald wie de sleutels krijgt. Least agency bepaalt wat ze kunnen doen zodra ze binnen zijn.

We lenen onze identiteit vaak aan onze agent, maar we willen niet dat de agent dezelfde permissies heeft als wij – dit is de definitie van least agency.

Hush heeft onlangs een Serie A van 30 miljoen dollar opgehaald, waardoor de totale financiering op $41 miljoen komt, met Akamai als strategische investeerder naast Battery Ventures en YL Ventures. Wat brengt de betrokkenheid van Akamai verder dan kapitaal, en hoe verwacht u dat het partnerschap de uitbreiding van Hush naar enterprise AI-agentbeveiliging zal beïnvloeden?

Akamai bevindt zich in het verkeerspad van de meeste ondernemingen wereldwijd, en dat is precies waar agentbeveiliging moet opereren. Je beheert een agent niet achteraf via een dashboard. Je beheert hem inline, op het moment dat hij een tool of API aanroept. Akamai heeft zijn business op dat model gebouwd.

Naast kapitaal brengen ze drie dingen: distributie naar CISO’s die al vragen hoe ze agents en MCP-verkeer moeten beheersen; bevestiging dat agentidentiteit een echte categorie is, geen functie; en tientallen jaren ervaring met het beveiligen van machine‑to‑machine verkeer op wereldwijde schaal, wat precies is wat agent‑to‑tool verkeer binnenkort wordt.

Model Context Protocol (MCP) wordt snel een belangrijke laag voor het verbinden van AI‑agents met tools en bedrijfsdata. Vanuit een beveiligingsperspectief, welke nieuwe risico’s introduceert MCP, en hoe moeten organisaties denken over identiteit en autorisatie tussen de agent, de MCP‑server en de onderliggende bron?

MCP maakt het verbinden van een agent met een tool triviaal. Dat is het risico. Een ontwikkelaar voegt een server toe aan een configuratiebestand en het model kan nu Jira lezen, een database bevragen of e‑mail verzenden. Geen review, geen inventaris, geen beleid. Beveiliging ontdekt het pas wanneer er iets misgaat.

Er zijn nu drie nieuwe problemen:

1. Shadow MCP – niemand weet hoeveel servers er draaien of wat ze aanraken.
2. Credential sprawl – de meeste servers authenticeren met een statisch token dat het volledige oppervlak verleent, waardoor de agent alles krijgt wat het token kan doen.
3. De ingestorte keten – de bron ziet alleen het credential van de MCP‑server, dus kan niet bepalen welke agent, namens welke gebruiker, de oproep heeft gedaan. Identiteit moet aan de basis van elke interactie staan, toegang moet tijdelijk, scoped en gebaseerd op de permissies van agent en gebruiker zijn.

Hush is oorspronkelijk gebouwd rond het idee dat statische geheimen en langdurige credentials een gebroken basis vormen voor machine‑toegang. Aangezien de meeste enterprise‑infrastructuur nog sterk leunt op API‑sleutels, tokens en andere geheimen, hoe kunnen bedrijven realistisch overstappen naar op identiteit gebaseerde, kort‑levende toegang zonder hun volledige technologische stack te herbouwen?

Je bouwt het niet opnieuw. Niemand die het anders beweert, heeft een enterprise ontmoet. Het grootste deel van wat we beschermen dateert van vóór de term non‑human identity, en het wordt niet herschreven.

Daarom vragen we er niet om. Hush wordt ingezet zonder code‑wijzigingen en zit in het toegangs‑pad. Stap één is ontdekking: elk geheim, wie het gebruikt, wat het bereikt, wat het daadwerkelijk doet tijdens runtime. De meeste bedrijven hebben dat beeld nog nooit gezien.

Daarna is het een reis, geen migratie. Ontdekking toont welke geheimen dood, over‑ge scoped of het hoogste risico hebben. Los die eerst op. Vervang vervolgens statische sleutels door kort‑levende, door identiteit uitgegeven credentials, één systeem per keer. De applicatie denkt nog steeds dat hij een sleutel gebruikt. De sleutel is gewoon niet meer langdurig, en het beleid wordt naar ons verplaatst.

Hetzelfde model geldt voor een vijftien jaar oude Java‑service en een MCP‑server die vorige week is opgezet. Begin waar het risico ligt, bewijs het, ga door.

AI‑agents zullen steeds vaker namens mensen werken en, in veel gevallen, taken delegeren aan andere agents. Naarmate deze multi‑agent‑workflows complexer worden, hoe behoud je een duidelijke keten van identiteit, autorisatie, eigendom en verantwoordelijkheid voor elke actie die plaatsvindt?

De foutmodus: een gebruiker vraagt een orchestrator, die delegeert aan een tweede agent, die een tool via een MCP‑server aanroept, die een database benadert met een service‑account. Vier hops later toont het logboek één ding, een geldig token. Wie heeft gevraagd, wie heeft beslist, en wie is verantwoordelijk, zijn verdwenen.

De oplossing is te weigeren dat identiteit op enige hop instort. Elke agent heeft zijn eigen cryptografische identiteit. Wanneer hij delegeert, geeft hij zijn token niet door. Hij uitgeeft een scoped delegatie: deze sub‑agent, deze taak, deze acties, namens deze gebruiker. Elke hop draagt de volledige keten en zijn eigen permissies.

Verantwoordelijkheid ontstaat door inline af te dwingen en te loggen, op het moment van actie. Het record van de gateway van wat het mocht doen, wat het heeft aangeroepen, en de keten erachter.

Multi‑agentsystemen zullen steeds moeilijker te doorgronden zijn. De keten van bewaring voor elke actie hoeft dat niet te zijn.

Prompt injection en andere aanvallen kunnen een anders legitieme AI‑agent mogelijk manipuleren om acties uit te voeren die de operator nooit heeft bedoeld. In hoeverre kunnen op identiteit gebaseerde toegangscontroles de schade beperken van een gecompromitteerde of gemanipuleerde agent, zelfs wanneer het onderliggende AI‑model zich onjuist gedraagt?

Je kunt prompt‑injectie niet bij het model stoppen. Modellen lezen per ontwerp onbetrouwbare inhoud. Ga ervan uit dat de agent uiteindelijk tot iets verkeerds wordt gelokt. De vraag is wat hij kan doen wanneer dat gebeurt.

Op identiteit gebaseerde toegang begrenst de impact. Een gemanipuleerde agent met minimale bevoegdheid kan alleen de acties misbruiken die hij voor die taak heeft gekregen. Als hij tickets kan lezen en opmerkingen kan plaatsen, zal geen injectie hem de klantendatabase laten exfiltreren. Het token heeft niet het bereik.

Gebruikersattributie houdt de keten intact: welke gebruiker, welke agent, welke taak, bij elke oproep. De agent overschrijdt nooit wat de gebruiker kon doen, en elke actie is terug te voeren.

Anomaliedetectie vangt op wat beleid toestaat, maar de intentie niet. Een agent die normaal vijf records leest en plotseling vijfduizend ophaalt, handelt buiten de norm, zelfs als elke oproep is geautoriseerd. Omdat de gateway inline zit en de basislijn kent, kan hij dat in realtime markeren of blokkeren.

Het model zal af en toe fout zijn. Gescopeerde identiteit, attributie en gedragsbaselines maken fouten overleefbaar.

Hush richt zich voornamelijk op het beveiligen van AI, maar hoe gebruiken jullie AI binnen Hush zelf? Zijn er gebieden zoals het ontdekken van niet‑menselijke identiteiten, het analyseren van toegangs‑patronen, het prioriteren van risico’s, of het handhaven van beleid waar AI de beveiligingsplatform aanzienlijk kan verbeteren?

We gebruiken het overal waar het zijn plek verdient.

In het product is het moeilijke niet het vinden van geheimen, maar het begrijpen ervan. Een sleutel verschijnt in het verkeer. Werkbelasting‑identiteit, leverancier‑integratie, dev‑test‑token, dode referentie? Een LLM leest de runtime‑context en eigenaarssignalen en stelt een antwoord voor met een vertrouwensscore. Het vat samen wat een identiteit daadwerkelijk doet in gewone mensentaal, zodat het beleid één is die een mens zal goedkeuren. Het rangschikt risico op basis van reëel bereik en impact, niet op statische ernst. Handhaving blijft deterministisch. AI helpt het beleid te schrijven – het krijgt geen stem tijdens runtime.

Binnen Hush heeft agentisch programmeren onze klok veranderd. Functionaliteiten die een sprint duurden, kosten nu dagen, en we leveren integraties in een tempo dat een Series‑A‑team zich normaal niet kan veroorloven. LLM’s triëren support‑tickets, clusteren oorzaken en brengen klantverzoeken naar roadmap‑discussies. Onze eigen MCP‑gateway staat ervoor, en helpt onze klanten redeneren over en omgaan met NHI en agentisch risico.

Hush zegt dat meerdere Fortune‑500‑bedrijven nu hun technologie gebruiken, terwijl Kyndryl Hush intern heeft ingezet en begonnen is met het doorverkopen aan enterprise‑klanten. Wat leer je van deze grootschalige implementaties over de governance‑problemen in de praktijk waarmee bedrijven worden geconfronteerd zodra AI‑agents van experiment naar productie gaan?

Niemand weet wat ze hebben. Elke grote uitrol begint op dezelfde manier: security denkt dat er een tiental agents in productie zijn, ontdekking vindt er honderden, die al klantgegevens aanraken. Het governance‑probleem is niet beleid, maar eerst inventaris.

De inloggegevens zijn erger dan de agents. Bijna elke productie‑agent draait op een statisch service‑account dat ouder is, met permissies die over jaren voor iets anders zijn opgebouwd. Het kreeg geen gescopeerde toegang.

Eigenaarschap ontbreekt. Vraag je wie er verantwoordelijk is voor een agent, of een NHI, dan krijg je op z’n best een teamnaam, een vertrokken contractant, of stilte.

En de koper veranderde. Dit was een probleem van het platformteam. Nu bezit de CISO het omdat het bestuur erom vraagt. Dat heeft ons van pilots naar enterprise‑rollouts gebracht, en is de reden waarom Kyndryl het intern heeft ingezet voordat het werd doorverkocht.

Agents hebben geen nieuwe governance‑problemen gecreëerd. Ze namen de problemen die bedrijven een decennium lang negeerden met service‑accounts en maakten ze veel erger.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen Hush Security bezoeken.