Micha Rave, administrerende direktør og medgründer av Hush Security – intervjuserie

Micha Rave, administrerende direktør og medgründer av Hush Security, er en erfaren leder innen cybersikkerhet og teknologi med en karriere som spenner over programvareutvikling, produktledelse, bedriftsnettverk, sky‑sikkerhet og identitet. Før han medgründet Hush Security i 2024, tilbrakte han mer enn fem år i Proofpoint som senior direktør for produktledelse innen sky‑sikkerhet, hvor han hadde ansvar for produktlinjene Zero Trust Network Access (ZTNA) og Secure Web Gateway (SWG). Han har tidligere vært VP for produktledelse i Meta Networks, med fokus på bedriftsnettverk og sikkerhet, og har hatt lederroller innen produkt og engineering i HARMAN International, Redbend, SanDisk, Hola, Jungo og Elbit Systems. Bakgrunnen hans kombinerer praktisk programvareutvikling med mer enn to tiår med erfaring i å bygge og kommersialisere sikkerhets‑, nettverks‑, virtualiserings‑ og innebygde teknologiprodukter.

Hush Security er et cybersikkerhetsselskap som fokuserer på å sikre AI‑agenter og andre ikke‑menneskelige identiteter ved å erstatte langvarige påloggingsinformasjoner og statiske hemmeligheter med identitetsbasert, policy‑styrt tilgang. Plattformen deres oppdager AI‑agenter, inkludert skygg‑ og internt utviklede agenter, tildeler dem verifiserbare identiteter, og styrer deres samhandling med bedriftsystemer ved hjelp av avgrensede, just‑in‑time‑tillatelser, sentraliserte policyer og revisjonsbare aktivitetslogger. Selskapet ble grunnlagt av sikkerhetserfarne fra teamet bak Meta Networks, som Proofpoint kjøpte opp i 2019. I juli 2026 hentet Hush inn $30 millioner i en Series A‑runding, med Akamai Technologies som strategisk investor sammen med Battery Ventures og YL Ventures, noe som økte den totale finansieringen til $41 millioner mens selskapet utvider teknologien for styring av bedrifts‑AI‑agenter og ikke‑menneskelig infrastruktur.

Før du grunnla Hush Security, brukte du år på å bygge og lede sikkerhetsprodukter, inkludert sky‑sikkerhet i Proofpoint. Hva så du i markedet som overbeviste deg om at det var behov for å starte Hush, og hvordan har den opprinnelige hypotesen utviklet seg med den raske fremveksten av agentisk AI?

På Proofpoint så vi hvordan virksomheter løste menneskelig identitet mens alt som ikke var menneskelig fortsatt kjørte på statiske hemmeligheter. Servicekontoer, arbeidsbelastninger, pipelines, alle autentiserte med nøkler ingen eide, ingen utløp. Bransjen svarte med bedre hvelv. Det er en bedre safe, men ikke en løsning.

Den grunnleggende hypotesen var å flytte ikke‑menneskelig tilgang fra hemmeligheter til identitet. Verifiserbar arbeidsbelastningsidentitet, kortvarige påloggingsinformasjoner utstedt just‑in‑time, policy håndhevet inline. Ingen kodeomskrivinger.

Agentisk AI gjorde dette presserende. En agent er en NHI som resonnerer og bestemmer i sanntid hvilke verktøy som skal kalles. Gi den en statisk nøkkel, så har du gitt autonom programvare vedvarende tilgang til produksjon, og agenter leveres utenfor enhver endringsprosess; en utvikler kobler en MCP‑server på tirsdag, og den berører kundedata allerede på fredag.

Hypotesen endret seg ikke. Omfanget gjorde det. Identitetsbasert tilgang var det riktige svaret for arbeidsbelastninger. For agenter er det det eneste levedyktige: kjenne hver eksisterende agent, gi hver som standard minst mulig myndighet, og revidere hver handling. Mennesker fikk en IdP. Agenter trenger også en, og det er Hush.

Hush hevder at AI‑agenter i bedrifter bør ha egne identiteter og delegert tilgang i stedet for bare å arve tilgangsrettighetene til menneskene som bruker dem. Hvorfor sliter tradisjonelle Identity and Access Management (IAM)-systemer med autonome agenter, og hva må endres?

Det åpenbare tilfellet er en agent som handler på vegne av en bruker. Det vanskeligere tilfellet er en agent uten noen bruker i det hele tatt: en planlagt jobb, en autonom SOC‑responder, en pipeline som resonnerer og handler på egen hånd. Det finnes ingen å delegere fra, så teamene faller tilbake på det eneste verktøyet de har, en statisk servicekonto med brede tillatelser og en nøkkel som aldri utløper. Det er den samme delte‑hemmelighetsmodellen som har sviktet i et tiår, nå knyttet til programvare som improviserer.

Systemene på den andre siden gjør det verre. De fleste interne API‑er, databaser og MCP‑servere utfører ikke reell autorisasjon. De sjekker om du har et gyldig token, ikke hva du har lov til å gjøre med det. Besittelse er lik tillatelse.

Det som må endres: hver agent får sin egen identitet, kryptografisk utstedt, uavhengig av om en menneskelig bruker står bak den eller ikke. Tilgang gis per handling, kortvarig og avgrenset, med policy håndhevet inline i stedet for å stole på målsystemet. Når det finnes en bruker, er agentens tillatelser skjæringspunktet mellom hva brukeren kan gjøre og hva agenten har lov til å gjøre for den oppgaven. Når det ikke finnes en bruker, er agentens egen identitet og policy hele historien. Mennesker fikk minst mulig privilegium. Agenter trenger minst mulig myndighet.

Du bruker begrepet «least agency» når du diskuterer AI‑sikkerhet. Hvordan skiller «least agency» seg fra det tradisjonelle cybersikkerhetsprinsippet om «least privilege», og hvordan kan organisasjoner nøyaktig fastslå hva en AI‑agent skal ha lov til å gjøre for en bestemt oppgave?

Agenter har ikke fast atferd. Gi en lesetilgang til et CRM og skrivetilgang til e‑post, så har du ikke gitt to tillatelser, du har gitt alle mulige veier mellom dem. «Least privilege» begrenser hva en agent kan berøre. Det sier ingenting om hva den skal gjøre med det.

Least agency legger til den manglende dimensjonen: hvilke handlinger, for hvilken oppgave, akkurat nå. En agent som triagerer saker må kunne lese og kommentere. Den trenger ikke å lukke, slette eller berøre fakturering, selv om tokenet tillater det. Når oppgaven er ferdig, er tilgangen slutt.

Å bestemme hva som er tillatt starter med observasjon, ikke gjetning. Kjør agenten, se hva den faktisk kaller, og la det definere grunnlinjen. Deretter begrens med tre innspill: oppgaven den er ment å utføre, brukeren den handler på vegne av (aldri mer enn de kunne gjort selv), og virkningen av hver handling, fordi posting av en kommentar og utføring av en betaling ikke bør dele samme godkjenningsvei.

Least privilege bestemmer hvem som får nøklene. Least agency bestemmer hva de kan gjøre når de er inne.

Vi «låner» ofte vår identitet til agenten, men vi vil ikke at agenten skal ha samme nivå av tillatelser som vi har – dette er definisjonen av least agency.

Hush har nylig hentet inn en 30 millioner dollar i serie A, noe som bringer total finansiering til $41 million, med Akamai som strategisk investor sammen med Battery Ventures og YL Ventures. Hva tilfører Akamais engasjement utover kapital, og hvordan forventer du at partnerskapet vil påvirke Hush sin ekspansjon innen bedrifts‑AI‑agent‑sikkerhet?

Akamai sitter i trafikkveien til de fleste av verdens bedrifter, og det er akkurat der agent‑sikkerhet må eksistere. Du styrer ikke en agent fra et dashbord i etterkant. Du styrer den inline, i det øyeblikket den kaller et verktøy eller en API. Akamai bygde sin forretningsmodell på dette.

Utover kapital bringer de tre ting: Distribusjon til CISO‑er som allerede spør hvordan de skal kontrollere agenter og MCP‑trafikk; validering av at agentidentitet er en reell kategori, ikke bare en funksjon; og tiår med erfaring i å sikre maskin‑til‑maskin‑trafikk i global skala, som er det agent‑til‑verktøy‑trafikk snart vil bli.

Model Context Protocol (MCP) blir raskt en viktig lag for å koble AI‑agenter med verktøy og bedriftsdata. Fra et sikkerhetsperspektiv, hvilke nye risikoer introduserer MCP, og hvordan bør organisasjoner tenke på identitet og autorisasjon mellom agenten, MCP‑serveren og den underliggende ressursen?

MCP gjorde det trivielt å koble en agent til et verktøy. Det er risikoen. En utvikler legger til en server i en konfigurasjonsfil, og modellen kan nå lese Jira, spørre en database eller sende e‑post. Ingen gjennomgang, ingen inventarliste, ingen policy. Sikkerheten får beskjed når noe går i stykker.

Det er nå tre nye problemer:

1. Shadow MCP – ingen vet hvor mange servere som kjører eller hva de berører.
2. Credential sprawl – de fleste servere autentiserer med et statisk token som gir tilgang til hele overflaten, så agenten får alt tokenet kan gjøre.
3. Den kollapsede kjeden – ressursen ser kun MCP‑serverens legitimasjon, så den kan ikke se hvilken agent, på vegne av hvilken bruker, som foretok kallet. Identitet må ligge i bunnen av hver interaksjon, tilgang bør være kortvarig, avgrenset og basert på agent‑ og brukerrettigheter.

Hush ble opprinnelig bygget rundt ideen om at statiske hemmeligheter og langvarige legitimasjoner er et ødelagt fundament for maskintilgang. Siden de fleste bedriftsinfrastrukturer fortsatt er tungt avhengige av API‑nøkler, token og andre hemmeligheter, hvordan kan selskaper realistisk gå over til identitetsbasert, kortvarig tilgang uten å måtte bygge om hele teknologistakken?

Du bygger ikke om. Ingen som sier noe annet har møtt en bedrift. Det meste vi beskytter er eldre enn begrepet ikke‑menneskelig identitet, og det blir ikke omskrevet.

Derfor ber vi ikke om det. Hush distribueres uten kodeendringer og sitter i tilgangsstien. Første steg er oppdagelse: hver hemmelighet, hvem som bruker den, hva den når, og hva den faktisk gjør i kjøretid. De fleste selskaper har aldri sett dette bildet.

Deretter er det en reise, ikke en migrasjon. Oppdagelse viser hvilke hemmeligheter som er døde, over‑avgrenset eller høyest risikable. Fiks dem først. Bytt deretter statiske nøkler mot kortvarige, identitetsutstedte legitimasjoner én tjeneste av gangen. Applikasjonen tror fortsatt den bruker en nøkkel. Nøkkelen slutter bare å være langvarig, og policyen flyttes til oss.

Den samme modellen dekker en femten år gammel Java‑tjeneste og en MCP‑server som ble satt opp forrige uke. Start der risikoen er, bevis konseptet, og fortsett.

AI‑agenter vil i økende grad arbeide på vegne av mennesker og, i mange tilfeller, delegere oppgaver til andre agenter. Etter hvert som disse multi‑agent‑arbeidsflytene blir mer komplekse, hvordan opprettholder du en klar kjede av identitet, autorisasjon, eierskap og ansvarlighet for hver handling som finner sted?

Feilmodus: en bruker spør en orkestrator, den delegere til en annen agent, som kaller et verktøy via en MCP‑server, som treffer en database med en tjenestekonto. Fire hopp senere viser loggen kun én ting, et gyldig token. Hvem spurte, hvem bestemte, og hvem som er ansvarlig, er borte.

Løsningen er å nekte at identiteten kollapser på noe hopp. Hver agent har sin egen kryptografiske identitet. Når den delegere, gir den ikke fra seg sitt token. Den utsteder en avgrenset delegasjon: denne under‑agenten, denne oppgaven, disse handlingene, på vegne av denne brukeren. Hvert hopp bærer hele kjeden, og sine egne tillatelser.

Ansvarlighet kommer fra å håndheve og logge inline, på handlingstidspunktet. Gatewayens register over hva den fikk lov til å gjøre, hva den kalte, og kjeden bak det.

Multiaragentsystemer blir vanskeligere å forstå. Kjedens forvaring for hver handling trenger det ikke.

Prompt‑injeksjon og andre angrep kan potensielt manipulere en ellers legitim AI‑agent til å utføre handlinger operatøren aldri hadde til hensikt. I hvilken grad kan identitetsbaserte tilgangskontroller begrense skaden fra en kompromittert eller manipulert agent, selv når den underliggende AI‑modellen oppfører seg feil?

Du vil ikke stoppe prompt‑injeksjon på modellen. Modeller leser upålitelig innhold som en del av designet. Anta at agenten en dag blir overtalt til noe galt. Spørsmålet er hva den kan gjøre når det skjer.

Identitetsbasert tilgang begrenser sprengningsradiusen. En manipulert agent med minimal myndighet kan kun misbruke de handlingene den ble gitt for den oppgaven. Hvis den kan lese saker og poste kommentarer, gjør ingen injeksjon at den eksfiltrerer kundedatabasen. Tokenet har ikke rekkevidden.

Brukerattribusjon holder kjeden intakt: hvilken bruker, hvilken agent, hvilken oppgave, på hver kall. Agenten overskrider aldri hva brukeren kunne gjort, og hver handling spores tilbake.

Anomalideteksjon fanger det policyen tillater men intensjonen ikke. En agent som vanligvis leser fem poster og plutselig henter fem tusen, er utenfor karakter selv om hvert kall er autorisert. Fordi gatewayen sitter inline og kjenner basislinjen, kan den flagge eller blokkere det i sanntid.

Modellen vil av og til ta feil. Avgrenset identitet, attribusjon og atferdsbaselines gjør at feil er overlevbare.

Hush fokuserer primært på å sikre AI, men hvordan bruker dere AI innen Hush selv? Finnes det områder som å oppdage ikke‑menneskelige identiteter, analysere tilgangsmønstre, prioritere risiko, eller håndheve policyer hvor AI kan forbedre sikkerhetsplattformen materiell?

Vi bruker den der den fortjener sin plass.

I produktet er den vanskelige delen ikke å finne hemmeligheter, men å forstå dem. En nøkkel dukker opp i trafikken. Arbeidsbelastningsidentitet, leverandørintegrasjon, dev‑test‑token, død legitimasjon? En LLM leser kjøretidskonteksten og eier‑signalene og foreslår et svar med en tillitsgrad. Den oppsummerer hva en identitet faktisk gjør i klar menneskelig språk, slik at policyen er en som et menneske vil godkjenne. Den rangerer risiko etter reell rekkevidde og sprengningsradius, ikke statisk alvorlighetsgrad. Håndheving forblir deterministisk. AI hjelper til med å skrive policyen – den får ingen stemme ved kjøring.

Inne i Hush endret agentisk programmering klokken vår. Funksjoner som tok en sprint tar nå dager, og vi leverer integrasjoner i et tempo et Series‑A‑team ellers ikke ville ha råd til. LLM‑er triagerer support‑saker, grupperer rotårsaker, og fremhever kundebehov for veikartdiskusjoner. Vår egen MCP‑gateway står foran alt dette, og hjelper kundene våre med å resonere og konsumere NHI og agentisk risiko.

Hush sier at flere Fortune‑500‑selskaper nå bruker teknologien deres, mens Kyndryl har implementert Hush internt og begynt å selge det videre til bedriftskunder. Hva lærer dere av disse storskala‑utrullingene om de virkelige styringsproblemene selskaper møter når AI‑agenter går fra eksperimentering til produksjon?

Ingen vet hva de har. Hver stor utrulling starter på samme måte: sikkerheten tror det er et dusin agenter i produksjon, oppdagelse finner hundrevis, allerede i kontakt med kundedata. Styringsproblemet er ikke policy, men inventar først.

Legitimasjonene er verre enn agentene. Nesten hver produksjonsagent kjører på en statisk tjenestekonto som er eldre enn den, med tillatelser akkumulert over år for noe annet. Den fikk ikke avgrenset tilgang.

Eierskap mangler. Spør hvem som er ansvarlig for en agent, eller en NHI, så får du i beste fall et teamnavn, en avtroppet konsulent, eller stillhet.

Og kjøperen endret seg. Dette var et plattformteam‑problem. Nå eier CISO det fordi styret spør. Det flyttet oss fra pilotprosjekter til bedriftsutrullinger, og det er grunnen til at Kyndryl implementerte internt før de solgte videre.

Agenter skapte ikke nye styringsproblemer. De tok de problemene bedrifter har ignorert i et tiår med tjenestekontoer og gjorde dem mye verre.

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