Micha Rave, VD och medgrundare av Hush Security – Intervjuserie

Micha Rave, VD och medgrundare av Hush Security, är en erfaren ledare inom cybersäkerhet och teknik vars karriär spänner över mjukvaruutveckling, produktledning, företagsnätverk, molnsäkerhet och identitet. Innan han medgrundade Hush Security år 2024 tillbringade han mer än fem år på Proofpoint som Senior Director of Product Management för Cloud Security, där han ansvarade för produktlinjerna Zero Trust Network Access (ZTNA) och Secure Web Gateway (SWG). Han har tidigare varit VP of Product Management på Meta Networks, med fokus på företagsnätverk och säkerhet, samt haft produkt- och ingenjörsledande roller på HARMAN International, Redbend, SanDisk, Hola, Jungo och Elbit Systems. Hans bakgrund kombinerar praktisk mjukvaruutveckling med mer än två decennier av erfarenhet av att bygga och kommersialisera säkerhets-, nätverks-, virtualiserings- och inbyggda teknikprodukter.

Hush Security är ett cybersäkerhetsföretag som fokuserar på att säkra AI‑agenter och andra icke‑mänskliga identiteter genom att ersätta långlivade autentiseringsuppgifter och statiska hemligheter med identitetsbaserad, policy‑styrd åtkomst. Plattformen upptäcker AI‑agenter, inklusive skugg‑ och internt utvecklade agenter, tilldelar dem verifierbara identiteter och styr deras interaktioner med företagssystem med hjälp av avgränsade, just‑in‑time‑behörigheter, centraliserade policys och granskningsbara aktivitetsloggar. Företaget grundades av säkerhetsveteraner från teamet bakom Meta Networks, som Proofpoint förvärvade år 2019. I juli 2026 tog Hush in $30 miljoner i en Series A‑runda med Akamai Technologies som strategisk investerare tillsammans med Battery Ventures och YL Ventures, vilket förde den totala finansieringen till $41 miljoner när företaget utökar sin teknik för att styra företags‑AI‑agenter och icke‑mänsklig infrastruktur.

Innan du grundade Hush Security tillbringade du år med att bygga och leda säkerhetsprodukter, inklusive molnsäkerhet på Proofpoint. Vad såg du på marknaden som övertygade dig om att det fanns ett behov av att starta Hush, och hur har den ursprungliga tesen utvecklats med den snabba framväxten av agentisk AI?

På Proofpoint såg vi hur företag löste mänsklig identitet medan allt icke‑mänskligt fortfarande kördes på statiska hemligheter. Servicekonton, arbetsbelastningar, pipelines, alla autentiserade med nycklar som ingen ägde och som ingen förnyade. Branschen svarade med bättre valv. Det är ett bättre kassaskåp, inte en lösning.

Den grundläggande tesen var att flytta icke‑mänsklig åtkomst från hemligheter till identitet. Verifierbar arbetsbelastningsidentitet, kortlivade autentiseringsuppgifter som utfärdas just‑in‑time, policy‑styrd inline‑verkställning. Ingen kodomskrivning.

Agentisk AI gjorde det brådskande. En agent är en NHI som resoneras och beslutar i realtid vilka verktyg som ska anropas. Ge den en statisk nyckel så har du gett autonom mjukvara permanent åtkomst till produktionsmiljön, och agenter levereras utanför alla förändringsprocesser; en utvecklare kopplar en MCP‑server på en tisdag och den hanterar kunddata redan på fredagen.

Tesen förändrades inte. Omfånget gjorde det. Identitetsbaserad åtkomst var det rätta svaret för arbetsbelastningar. För agenter är det det enda fungerande alternativet: känna till varje befintlig agent, ge var och en minimal agentur som standard och granska varje åtgärd. Människor fick en IdP. Agenter behöver också en, och det är Hush.

Hush hävdar att företags‑AI‑agenter bör ha egna identiteter och delegerade behörigheter istället för att bara ärva åtkomsträttigheterna från de människor som använder dem. Varför har traditionella Identity and Access Management (IAM)‑system problem med autonoma agenter, och vad måste förändras?

Det uppenbara fallet är en agent som agerar för en användare. Det svårare fallet är en agent utan någon användare alls: ett schemalagt jobb, en autonom SOC‑responder, en pipeline som resoneras och agerar på egen hand. Det finns ingen att delega från, så teamen faller tillbaka på det enda verktyg de har, ett statiskt servicekonto med breda behörigheter och en nyckel som aldrig går ut. Det är samma delade‑hemlighetsmodell som har varit bristfällig i ett decennium, nu kopplad till mjukvara som improviserar.

Systemen i andra änden förvärrar situationen. De flesta interna API:er, databaser och MCP‑servrar utför ingen verklig auktorisation. De kontrollerar om du har en giltig token, inte vad du får göra med den. Ägande är lika med behörighet.

Vad som måste förändras: varje agent får sin egen identitet, kryptografiskt utfärdad, oavsett om en människa står bakom den eller inte. Åtkomst beviljas per åtgärd, kortlivad och avgränsad, med policy som verkställs inline snarare än att lita på målsystemet. När det finns en användare är agentens behörigheter skärningspunkten mellan vad användaren kan göra och vad den agenten får göra för den uppgiften. När det inte finns någon användare är agentens egen identitet och policy hela historien. Människor fick minsta privilegium. Agenter behöver minsta agentur.

Du använder begreppet ”minsta agentur” när du diskuterar AI‑säkerhet. Hur skiljer sig minsta agentur från det traditionella cybersäkerhetsprincipen om minsta privilegium, och hur kan organisationer exakt fastställa vad en AI‑agent bör tillåtas göra för en viss uppgift?

Agenter har inte ett fast beteende. Ge en läsåtkomst till ett CRM och skrivbehörighet till e‑post, så har du inte beviljat två separata behörigheter, du har beviljat varje möjlig väg mellan dem. Minsta privilegium begränsar vad en agent kan röra vid. Det säger ingenting om vad den bör göra med det.

Least agency tillför den saknade dimensionen: vilka åtgärder, för vilken uppgift, just nu. En agent som triagerar ärenden behöver läsa och kommentera. Den behöver inte stänga, radera eller röra fakturering, även om tokenet tillåter det. När uppgiften är klar upphör åtkomsten.

Att besluta vad som är tillåtet börjar med observation, inte gissning. Kör agenten, se vad den faktiskt anropar, och låt det definiera baslinjen. Sedan begränsar du med tre ingångar: den uppgift den finns för, användaren den agerar för (aldrig mer än vad de kan göra) och sprängradien för varje åtgärd, eftersom att posta en kommentar och genomföra en betalning inte bör dela samma godkännandekedja.

Least privilege bestämde vem som får nycklarna. Least agency bestämmer vad de kan göra när de är inne.

Vi “lånar” ofta vår identitet till vår agent, men vi vill inte att agenten ska ha samma behörighetsnivå som vi – det är definitionen av least agency.

Hush nyligen tog in en serie A på 30 miljoner dollar, vilket bringar den totala finansieringen till $41 miljoner, med Akamai som strategisk investerare tillsammans med Battery Ventures och YL Ventures. Vad tillför Akamais engagemang utöver kapital, och hur förväntar du dig att partnerskapet ska påverka Hushs expansion inom företags‑AI‑agent‑säkerhet?

Akamai sitter i trafikvägen för de flesta av världens företag, och det är exakt där agent‑säkerhet måste finnas. Du styr inte en agent från en instrumentpanel i efterhand. Du styr den inline, i det ögonblick den anropar ett verktyg eller API. Akamai byggde sin verksamhet på den modellen.

Utöver kapitalet bidrar de med tre saker: distribution till CISO:er som redan frågar hur man kontrollerar agenter och MCP‑trafik; validering att agent‑identitet är en riktig kategori, inte en funktion; samt decennier av erfarenhet av att säkra maskin‑till‑maskin‑trafik i global skala, vilket är vad agent‑till‑verktyg‑trafik snart kommer att bli.

Model Context Protocol (MCP) blir snabbt ett viktigt lager för att koppla AI‑agenter till verktyg och företagsdata. Ur ett säkerhetsperspektiv, vilka nya risker introducerar MCP, och hur bör organisationer tänka kring identitet och auktorisation mellan agenten, MCP‑servern och den underliggande resursen?

MCP gjorde det trivialt att koppla en agent till ett verktyg. Det är risken. En utvecklare lägger till en server i en konfigurationsfil och modellen kan nu läsa Jira, fråga en databas eller skicka e‑post. Ingen granskning, ingen inventering, ingen policy. Säkerheten får reda på det när något går sönder.

Det finns nu tre nya problem:

1. Shadow MCP – ingen vet hur många servrar som körs eller vad de berör.
2. Credential sprawl – de flesta servrar autentiserar med en statisk token som ger åtkomst till hela ytan, så agenten får allt som tokenet kan göra.
3. Den kollapsade kedjan – resursen ser bara MCP‑serverns credential, så den kan inte avgöra vilken agent, agerande för vilken användare, som gjorde anropet. Identitet måste ligga i basen för varje interaktion, åtkomst bör vara kortlivad, avgränsad och baserad på agent‑ och användarbehörigheter.

Hush byggdes ursprungligen kring idén att statiska hemligheter och långlivade credentialer är en bristfällig grund för maskintillgång. Eftersom de flesta företagsinfrastrukturer fortfarande starkt förlitar sig på API‑nycklar, token och andra hemligheter, hur kan företag realistiskt gå mot identitetsbaserad, kortlivad åtkomst utan att bygga om hela sin teknikstack?

Du bygger inte om. Ingen som säger motsatsen har mött ett företag. Det mesta vi skyddar föregår begreppet icke‑mänsklig identitet, och det blir inte omskrivet.

Så vi begär det inte. Hush distribueras utan kodändringar och sitter i åtkomstvägen. Steg ett är upptäckt: varje hemlighet, vem som använder den, vad den når, vad den faktiskt gör vid körning. De flesta företag har aldrig sett den bilden.

Därefter är det en resa, inte en migrering. Upptäckt visar vilka hemligheter som är döda, över‑avgränsade eller högst riskfyllda. Åtgärda dem först. Byt sedan ut statiska nycklar mot kortlivade, identitetsutfärdade credentialer, ett system i taget. Applikationen tror fortfarande att den använder en nyckel. Nyckeln slutar bara vara långlivad, och policyn övergår till oss.

Samma modell täcker en femton år gammal Java‑tjänst och en MCP‑server som sattes upp förra veckan. Börja där risken finns, bevisa det, fortsätt.

AI‑agenter kommer i allt högre grad att arbeta på uppdrag av människor och, i många fall, delegera uppgifter till andra agenter. När dessa multi‑agent‑arbetsflöden blir mer komplexa, hur upprätthåller du en tydlig kedja av identitet, auktorisation, ägande och ansvar för varje åtgärd som sker?

Fel‑läget: en användare frågar en orkestrator, den delegerar till en andra agent, som anropar ett verktyg via en MCP‑server, som träffar en databas med ett service‑konto. Fyra hopp senare visar loggen bara en sak, en giltig token. Vem som frågade, vem som beslutade och vem som är ansvarig har försvunnit.

Lösningen är att vägra låta identiteten kollapsa i något hopp. Varje agent har sin egen kryptografiska identitet. När den delegerar överlämnar den inte sin token. Den utfärdar en avgränsad delegation: denna under‑agent, denna uppgift, dessa åtgärder, på uppdrag av denna användare. Varje hopp bär hela kedjan och sina egna behörigheter.

Ansvarstagande kommer från att verkställa och logga inline, vid åtgärdens punkt. Gatewayens register över vad den fick göra, vad den anropade och kedjan bakom det.

Multiaagentsystem blir svårare att resonera kring. Kedjan av ansvar för varje åtgärd behöver inte.

Promptinjektion och andra attacker kan potentiellt manipulera en annars legitim AI‑agent att utföra handlingar som dess operatör aldrig avsett. I vilken grad kan identitetsbaserade åtkomstkontroller begränsa skadan från en komprometterad eller manipulerad agent, även när den underliggande AI‑modellen beter sig felaktigt?

Du kan inte stoppa promptinjektion på modellnivå. Modeller läser opålitligt innehåll som en del av sin design. Anta att agenten så småningom blir övertalad att göra något fel. Frågan är vad den kan göra när det inträffar.

Identitetsbaserad åtkomst begränsar spridningsradien. En manipulerad agent med minimal befogenhet kan bara missbruka de handlingar den beviljats för den uppgiften. Om den kan läsa ärenden och posta kommentarer, gör ingen injektion den till att exfiltrera kunddatabasen. Tokenet har inte den räckvidden.

Användarattributering håller kedjan intakt: vilken användare, vilken agent, vilken uppgift, vid varje anrop. Agenten överskrider aldrig vad användaren kan göra, och varje handling spåras tillbaka.

Anomalidetektion fångar det som policyn tillåter men avsikten inte gjorde. En agent som normalt läser fem poster och plötsligt hämtar fem tusen är utanför sin karaktär även om varje anrop är auktoriserat. Eftersom gatewayen sitter inline och känner till baslinjen kan den flagga eller blockera det i realtid.

Modellen kommer att vara fel ibland. Avgränsad identitet, attributering och beteendegrundlinjer gör fel överlevbara.

Hush fokuserar främst på att säkra AI, men hur använder ni AI inom Hush själva? Finns det områden som att upptäcka icke‑mänskliga identiteter, analysera åtkomstmönster, prioritera risk eller verkställa policyer där AI kan förbättra säkerhetsplattformen på ett väsentligt sätt?

Vi använder den där den förtjänar sin plats.

I produkten är den svåra delen inte att hitta hemligheter, utan att förstå dem. En nyckel dyker upp i trafiken. Arbetsbelastningsidentitet, leverantörsintegration, dev‑test‑token, dead credential? En LLM läser körningskontexten och ägarsignaler och föreslår ett svar med en förtroendescore. Den sammanfattar vad en identitet faktiskt gör i klar mänsklig språk, så att policyn blir en som en människa godkänner. Den rangordnar risk efter verklig räckvidd och spridningsradie, inte statisk allvarlighetsgrad. Verkställandet förblir deterministiskt. AI hjälper till att skriva policyn – den får ingen röst vid körning.

Inom Hush har agentbaserad programmering förändrat vår tidslinje. Funktioner som tidigare tog en sprint tar nu dagar, och vi levererar integrationer i en takt som ett Series‑A‑team annars inte skulle ha råd med. LLM‑ar triagerar supportärenden, grupperar grundorsaker och lyfter fram kundförfrågningar för roadmap‑diskussioner. Vår egen MCP‑gateway står framför allt detta och hjälper våra kunder att resonera kring och utnyttja NHI och agentisk risk.

Hush säger att flera Fortune 500‑företag nu använder deras teknik, medan Kyndryl har implementerat Hush internt och börjat återförsälja den till företagskunder. Vad lär ni er av dessa storskaliga utrullningar om de verkliga styrningsproblemen som företag stöter på när AI‑agenter går från experiment till produktion?

Ingen vet vad de har. Varje stor utrullning börjar på samma sätt: säkerheten tror att det finns ett dussin agenter i produktion, men upptäckt hittar hundratals, redan i kontakt med kunddata. Styrningsproblemet är inte policy, utan inventering först.

Behörigheterna är värre än agenterna. Nästan varje produktionsagent körs på ett statiskt servicekonto som föregår den, med behörigheter som samlats på sig under år för något annat. Den fick ingen avgränsad åtkomst.

Ägarskap saknas. Fråga vem som är ansvarig för en agent, eller en NHI, och du får högst ett teamnamn, en avgången konsult eller inget svar.

Och köparen förändrades. Detta var ett problem för plattformsteamet. Nu äger CISO:n det eftersom styrelsen efterfrågar det. Det förde oss från pilotprojekt till företagsomfattande utrullningar, och det är därför Kyndryl implementerade internt innan de återförsäljde.

Agenter skapade inga nya styrningsproblem. De tog de problem som företag ignorerade i ett decennium med servicekonton och förvärrade dem kraftigt.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka Hush Security.