Micha Rave, administrerende direktør og medstifter af Hush Security – Interviewserie

Micha Rave, administrerende direktør og medstifter af Hush Security, er en erfaren leder inden for cybersikkerhed og teknologi, hvis karriere spænder over softwareudvikling, produktledelse, virksomhedsnetværk, cloud‑sikkerhed og identitet. Før han medstiftede Hush Security i 2024, tilbragte han mere end fem år hos Proofpoint som Senior Director of Product Management for Cloud Security, hvor han var ansvarlig for produktlinjerne Zero Trust Network Access (ZTNA) og Secure Web Gateway (SWG). Han har tidligere været VP of Product Management hos Meta Networks med fokus på virksomhedsnetværk og sikkerhed, og har haft produkt‑ og ingeniørledelsesroller hos HARMAN International, Redbend, SanDisk, Hola, Jungo og Elbit Systems. Hans baggrund kombinerer praktisk softwareudvikling med over to årtiers erfaring med at bygge og kommercialisere sikkerheds‑, netværks‑, virtualiserings‑ og indlejrede teknologiprodukter.

Hush Security er en cybersikkerhedsvirksomhed, der fokuserer på at sikre AI‑agenter og andre ikke‑menneskelige identiteter ved at erstatte langvarige legitimationsoplysninger og statiske hemmeligheder med identitetsbaseret, politikstyret adgang. Platformen opdager AI‑agenter, herunder skygge‑ og internt udviklede agenter, tildeler dem verificerbare identiteter og styrer deres interaktioner med virksomheds‑systemer ved hjælp af afgrænsede, just‑in‑time‑tilladelser, centraliserede politikker og audit‑bare aktivitetslogfiler. Virksomheden blev grundlagt af sikkerhedsveteraner fra teamet bag Meta Networks, som Proofpoint erhvervede i 2019. I juli 2026 rejste Hush en Series A på 30 millioner USD med Akamai Technologies som strategisk investor sammen med Battery Ventures og YL Ventures, hvilket bringer den samlede finansiering op på 41 millioner USD, mens virksomheden udvider sin teknologi til at styre virksomhedens AI‑agenter og ikke‑menneskelige infrastruktur.

Før du grundlagde Hush Security, brugte du år på at bygge og lede sikkerhedsprodukter, herunder cloud‑sikkerhed hos Proofpoint. Hvad så du på markedet, der overbeviste dig om, at der var behov for at starte Hush, og hvordan har den oprindelige tese udviklet sig i takt med den hurtige fremkomst af agentisk AI?

Hos Proofpoint så vi, hvordan virksomheder løste menneskelig identitet, mens alt ikke‑menneskeligt stadig kørte på statiske hemmeligheder. Service‑konti, arbejdsbelastninger, pipelines, alle autentificerede med nøgler, som ingen ejede, og som ingen udløb. Branchen svarede med bedre hvelve – men det er kun en bedre safe, ikke en løsning.

Dannelsestesen var at flytte ikke‑menneskelig adgang fra hemmeligheder til identitet. Verificerbar arbejdsbelastningsidentitet, kort‑levet legitimationsoplysninger udstedt just‑in‑time, politik håndhævet inline. Ingen kodeomskrivninger.

Agentisk AI gjorde det presserende. En agent er en NHI, der på kørselstidspunktet ræsonnerer og beslutter, hvilke værktøjer der skal kaldes. Giver du den en statisk nøgle, har du givet autonom software vedvarende adgang til produktionen, og agenter leveres uden for enhver ændringsproces; en udvikler tilslutter en MCP‑server om tirsdagen, og den berører kundedata allerede om fredagen.

Tesen ændrede sig ikke. Omfanget gjorde. Identitetsbaseret adgang var det rigtige svar for arbejdsbelastninger. For agenter er det det eneste levedygtige: kend hver eksisterende agent, giv hver som standard den mindst mulige agentur, og auditér hver handling. Mennesker fik en IdP. Agenter har også brug for en, og det er Hush.

Hush argumenterer for, at virksomhedens AI‑agenter skal have deres egne identiteter og delegerede tilladelser i stedet for blot at arve adgange fra de mennesker, der bruger dem. Hvorfor har traditionelle Identity and Access Management (IAM)-systemer svært ved autonome agenter, og hvad skal ændres?

Det åbenlyse tilfælde er en agent, der handler på vegne af en bruger. Det sværere tilfælde er en agent uden nogen bruger overhovedet: et planlagt job, en autonom SOC‑responder, en pipeline, der ræsonnerer og handler på egen hånd. Der er ingen at delegere fra, så teams falder tilbage på det eneste værktøj, de har – en statisk service‑konto med brede tilladelser og en nøgle, der aldrig udløber. Det er den samme delte‑hemmelighedsmodel, som har været i opløsning i et årti, nu knyttet til software, der improviserer.

Systemerne i den anden ende forværrer det. De fleste interne API’er, databaser og MCP‑servere udfører ikke reel autorisation. De tjekker kun, om du har et gyldigt token, ikke hvad du har lov til at gøre med det. Besiddelse svarer til tilladelse.

Hvad der skal ændres: hver agent får sin egen identitet, udstedt kryptografisk, uanset om der er et menneske bag den eller ej. Adgang gives per handling, kort‑levet og afgrænset, med politik håndhævet inline i stedet for at blive betroet mål‑systemet. Når der er en bruger, er agentens tilladelser skæringspunktet mellem, hvad brugeren kan, og hvad den pågældende agent må gøre for den opgave. Når der ikke er en bruger, er agentens egen identitet og politik hele historien. Mennesker fik mindste privilegium. Agenter har brug for mindste agentur.

Du bruger begrebet “mindste agentur” i diskussionen om AI‑sikkerhed. Hvordan adskiller mindste agentur sig fra det traditionelle cybersikkerhedsprincip om mindste privilegium, og hvordan kan organisationer præcist fastlægge, hvad en AI‑agent skal have lov til at gøre for en given opgave?

Agenter har ikke fast adfærd. Giver du én læseadgang til et CRM og skriveadgang til e‑mail, har du ikke givet to tilladelser, men alle mulige veje imellem dem. Mindste privilegium begrænser, hvad en agent kan røre ved. Det siger intet om, hvad den bør gøre med det.

Least agency tilføjer den manglende dimension: hvilke handlinger, for hvilken opgave, lige nu. En agent, der triagerer tickets, skal kunne læse og kommentere. Den behøver ikke at lukke, slette eller røre fakturering, selvom tokenet tillader det. Når opgaven slutter, slutter adgangen.

At beslutte, hvad der er tilladt, starter med observation, ikke gætteri. Kør agenten, se hvad den faktisk kalder, og lad det definere grundlinjen. Derefter indsnævres det med tre input: den opgave, den er skabt til at udføre, brugeren den handler på vegne af (aldrig mere end de selv kunne gøre), og eksplosionens radius for hver handling, fordi det ikke skal være samme godkendelsessti at poste en kommentar og foretage en betaling.

Least privilege bestemmer, hvem der får nøglerne. Least agency bestemmer, hvad de kan gøre, når de er inde.

Vi “låner” ofte vores identitet til vores agent, men vi ønsker ikke, at agenten skal have samme niveau af tilladelser som vi har – det er definitionen af least agency.

Hush har for nylig rejst en 30 millioner dollar i serie A, hvilket bringer den samlede finansiering op på $41 million, med Akamai som strategisk investor sammen med Battery Ventures og YL Ventures. Hvad bringer Akamais involvering udover kapital, og hvordan forventer du, at partnerskabet vil påvirke Hushs udvidelse inden for enterprise AI-agent sikkerhed?

Akamai befinder sig i trafikstien for de fleste af verdens virksomheder, og det er præcis, hvor agent-sikkerhed skal leve. Du styrer ikke en agent fra et dashboard efterfølgende. Du styrer den inline, i det øjeblik den kalder et værktøj eller en API. Akamai byggede sin forretning på den model.

Udover kapital bringer de tre ting: Distribution til CISO’er, der allerede spørger om, hvordan man kontrollerer agenter og MCP-trafik; validering af, at agentidentitet er en reel kategori, ikke en funktion; samt årtiers erfaring med at sikre maskine-til-maske-trafik i global skala, som er hvad agent-til-værktøj-trafik snart vil blive.

Model Context Protocol (MCP) er hurtigt ved at blive et vigtigt lag for at forbinde AI-agenter med værktøjer og virksomhedsdata. Set fra et sikkerhedsperspektiv, hvilke nye risici introducerer MCP, og hvordan bør organisationer tænke på identitet og autorisation mellem agenten, MCP-serveren og den underliggende ressource?

MCP gjorde det trivielt at forbinde en agent til et værktøj. Det er risiciene. En udvikler tilføjer en server til en konfigurationsfil, og modellen kan nu læse Jira, forespørge en database eller sende e‑mail. Ingen gennemgang, ingen inventarliste, ingen politik. Sikkerheden opdager problemet, når noget går i stykker.

Der er nu tre nye problemer:

1. Shadow MCP – ingen ved, hvor mange servere der kører, eller hvad de berører.
2. Credential sprawl – de fleste servere autentificerer med et statisk token, der giver adgang til hele overfladen, så agenten får alt, hvad tokenet kan gøre.
3. Den kollapsede kæde – ressourcen ser kun MCP-serverens legitimationsoplysninger, så den kan ikke se, hvilken agent, på vegne af hvilken bruger, foretog kaldet. Identitet skal være i bunden af hver interaktion, adgang skal være midlertidig, afgrænset og baseret på agent- og brugerrettigheder.

Hush blev oprindeligt bygget omkring idéen om, at statiske hemmeligheder og langvarige legitimationsoplysninger er et brudt fundament for maskinadgang. Da de fleste virksomhedsinfrastrukturer stadig i høj grad er afhængige af API-nøgler, tokens og andre hemmeligheder, hvordan kan virksomheder realistisk bevæge sig mod identitetsbaseret, kortvarig adgang uden at skulle genopbygge hele deres teknologiske stack?

Du genopbygger ikke. Ingen, der siger andet, har mødt en virksomhed. Det meste af det, vi beskytter, er ældre end udtrykket non-human identity, og det bliver ikke omskrevet.

Derfor beder vi ikke om det. Hush implementeres uden kodeændringer og sidder i adgangsstien. Første skridt er opdagelse: hver hemmelighed, hvem der bruger den, hvad den når, og hvad den faktisk gør i runtime. De fleste virksomheder har aldrig set dette billede.

Derefter er det en rejse, ikke en migration. Opdagelse viser, hvilke hemmeligheder der er døde, over‑afgrænsede eller højeste risiko. Fix dem først. Udskift derefter statiske nøgler med kortvarige, identitetsudstedte legitimationsoplysninger én system ad gangen. Applikationen tror stadig, den bruger en nøgle. Nøglen stopper blot med at være langvarig, og politikken flyttes til os.

Den samme model dækker en femten år gammel Java‑service og en MCP‑server, der blev sat i drift i sidste uge. Start hvor risikoen er, bevis det, fortsæt.

AI-agenter vil i stigende grad arbejde på vegne af mennesker og i mange tilfælde delegere opgaver til andre agenter. Efterhånden som disse multi‑agent‑arbejdsprocesser bliver mere komplekse, hvordan bevarer du en klar kæde af identitet, autorisation, ejerskab og ansvarlighed for hver handling, der finder sted?

Fejltilstanden: en bruger spørger en orkestrator, den delegere til en anden agent, som kalder et værktøj gennem en MCP‑server, som rammer en database med en servicekonto. Fire hop senere viser loggen kun én ting, et gyldigt token. Hvem spurgte, hvem besluttede, og hvem er ansvarlig, er væk.

Løsningen er at nægte, at identiteten kollapser på noget hop. Hver agent har sin egen kryptografiske identitet. Når den delegere, overdrager den ikke sit token. Den udsteder en afgrænset delegation: denne under‑agent, denne opgave, disse handlinger, på vegne af denne bruger. Hvert hop bærer den fulde kæde og sine egne tilladelser.

Ansvarlighed kommer fra håndhævelse og logning inline, på handlingstidspunktet. Gatewayens registrering af, hvad den fik lov til at gøre, hvad den kaldte, og kæden bag den.

Multiaagentsystemer vil blive sværere at forstå. Kæden af ansvar for hver handling behøver den ikke.

Prompt‑injektion og andre angreb kan potentielt manipulere en ellers legitim AI‑agent til at udføre handlinger, som dens operatør aldrig havde til hensigt. I hvilken grad kan identitetsbaserede adgangskontroller begrænse skaden fra en kompromitteret eller manipuleret agent, selv når den underliggende AI‑model opfører sig forkert?

Du kan ikke stoppe prompt‑injektion på modellen. Modeller læser upålideligt indhold som design. Antag, at agenten på et tidspunkt vil blive overtalt til noget forkert. Spørgsmålet er, hvad den kan gøre, når det sker.

Identitetsbaseret adgang begrænser eksplosionens radius. En manipuleret agent med minimal handlefrihed kan kun misbruge de handlinger, den er tildelt for den opgave. Hvis den kan læse tickets og poste kommentarer, får ingen injektion den til at eksfiltrere kundedatabasen. Tokenet har ikke den rækkevidde.

Bruger‑attribution holder kæden intakt: hvilken bruger, hvilken agent, hvilken opgave, ved hvert opkald. Agenten overskrider aldrig, hvad brugeren kunne gøre, og hver handling kan spores tilbage.

Anomalidetektion fanger det, som politikken tillader, men intentionen ikke gør. En agent, der normalt læser fem poster og pludselig henter fem tusinde, er ude af karakter, selvom hvert opkald er autoriseret. Da gatewayen sidder inline og kender grundlinjen, kan den i realtid flagge eller blokere det.

Modellen vil nogle gange tage fejl. Afgrænset identitet, attribution og adfærdsmæssige grundlinjer gør fejl overlevelige.

Hush fokuserer primært på at sikre AI, men hvordan bruger I AI inden for Hush selv? Er der områder som at opdage ikke‑menneskelige identiteter, analysere adgangsmønstre, prioritere risici eller håndhæve politikker, hvor AI kan forbedre sikkerhedsplatformen væsentligt?

Vi bruger den, hvor den fortjener sin plads.

I produktet er den svære del ikke at finde hemmeligheder, men at forstå dem. En nøgle dukker op i trafikken. Arbejdsbelastningsidentitet, leverandørintegration, dev‑test‑token, død legitimationsoplysning? En LLM læser køretidskonteksten og ejer‑signaler og foreslår et svar med en tillidsgrad. Den opsummerer, hvad en identitet faktisk gør i almindeligt menneskeligt sprog, så politikken er en, som et menneske vil godkende. Den rangerer risiko efter reel rækkevidde og eksplosionens radius, ikke statisk alvorlighed. Håndhævelse forbliver deterministisk. AI hjælper med at skrive politikken – den får ingen stemme ved kørselstid.

Inden for Hush ændrede agentisk programmering vores tidsplan. Funktioner, der tog en sprint, tager nu dage, og vi leverer integrationer i et tempo, som et Series‑A‑team ellers ikke kunne have råd til. LLM’er triagerer support‑tickets, grupperer grundårsager og frembringer kundebehov til roadmap‑diskussioner. Vores egen MCP‑gateway står foran det hele og hjælper vores kunder med at forstå og håndtere NHI og agentisk risiko.

Hush siger, at flere Fortune 500‑virksomheder nu bruger deres teknologi, mens Kyndryl har implementeret Hush internt og begyndt at videresælge den til erhvervskunder. Hvad lærer I af disse store udrulninger om de virkelige governance‑problemer, som virksomheder støder på, når AI‑agenter går fra eksperimentering til produktion?

Ingen ved, hvad de har. Hver stor udrulning starter på samme måde: sikkerhed tror, der er et dusin agenter i produktion, men opdagelse finder hundredvis, som allerede berører kundedata. Governance‑problemet er ikke politik, men først inventar.

Legitimationsoplysningerne er værre end agenterne. Næsten hver produktionsagent kører på en statisk servicekonto, der er ældre end den, med tilladelser akkumuleret over år for noget andet. Den fik ikke afgrænset adgang.

Ejerskab mangler. Spørg, hvem der er ansvarlig for en agent eller en NHI, og du får højst et teamnavn, en afgået kontraktør eller stilhed.

Og køberen skiftede. Dette var et problem for platformteamet. Nu ejer CISO’en det, fordi bestyrelsen efterspørger det. Det flyttede os fra pilotprojekter til virksomhedsrulninger, og det er grunden til, at Kyndryl implementerede internt, før de videresalgte.

Agenter skabte ikke nye governance‑problemer. De tog de problemer, som virksomheder har ignoreret i et årti med servicekonti, og gjorde dem meget værre.

Tak for det fantastiske interview, læsere der ønsker at lære mere, bør besøge Hush Security.