Micha Rave, toimitusjohtaja ja Hush Securityn yhteisperustaja – Haastattelusarja

Micha Rave, toimitusjohtaja ja Hush Securityn yhteisperustaja, on kokenut kyberturvallisuuden ja teknologian johtaja, jonka ura kattaa ohjelmistokehityksen, tuotehallinnan, yritysverkon, pilviturvallisuuden ja identiteetin. Ennen Hush Securityn perustamista vuonna 2024 hän vietti yli viisi vuotta Proofpointissa seniorijohdossa pilviturvallisuuden tuotehallinnassa, jossa hän vastasi Zero Trust Network Access (ZTNA) ja Secure Web Gateway (SWG) -tuotelinjoista. Aikaisemmin hän toimi Meta Networksin tuotehallinnan varapuheenjohtajana, keskittyen yritysverkkoratkaisuihin ja turvallisuuteen, ja hänellä on ollut tuote- ja tekniikkajohtajan rooleja HARMAN Internationalissa, Redbendissä, SanDiskissä, Hola:ssa, Jungossa ja Elbit Systemsissa. Hänen taustansa yhdistää käytännön ohjelmistokehityksen yli kahden vuosikymmenen kokemukseen turvallisuus-, verkko-, virtualisointi- ja sulautettujen teknologioiden tuotteiden rakentamisesta ja kaupallistamisesta.

Hush Security on kyberturvallisuuskonsulttiyritys, joka keskittyy AI-agenttien ja muiden ei-inhimillisten identiteettien suojaamiseen korvaamalla pitkäikäiset tunnistetiedot ja staattiset salaisuudet identiteettipohjaisella, politiikkavalvotulla pääsyllä. Sen alusta löytää AI-agentteja, mukaan lukien varjot ja sisäisesti kehitetyt agentit, antaa niille tarkistettavat identiteetit ja hallinnoi niiden vuorovaikutusta yritysjärjestelmien kanssa käyttäen laajennettuja, juuri‑ajassa myönnettyjä oikeuksia, keskitettyjä politiikkoja ja tarkastettavia toiminnan lokitietoja. Yritys perustettiin turvallisuusveteraanien toimesta, jotka olivat Meta Networksin tiimissä, jonka Proofpoint hankki vuonna 2019. Heinäkuussa 2026 Hush keräsi $30 millionin Series A -rahoituksen, jossa Akamai Technologies liittyi strategiseksi sijoittajaksi Battery Venturesin ja YL Venturesin ohella, nostamalla kokonaisrahoituksen $41 miljoonaan, kun yritys laajentaa teknologiaansa yritysten AI-agenttien ja ei-inhimillisen infrastruktuurin hallintaan.

Ennen Hush Securityn perustamista vietit vuosia turvallisuustuotteiden rakentamiseen ja johtamiseen, mukaan lukien pilviturvallisuus Proofpointissa. Mitä näit markkinoilla, mikä vakuutti sinut siitä, että Hushin perustaminen oli tarpeen, ja miten alkuperäinen väite on kehittynyt agenttien AI:n nopean nousun myötä?

Proofpointissa havaitsimme, että yritykset ratkaisevat ihmisen identiteetin, kun kaikki ei-inhimillinen toiminta jatkui edelleen staattisilla salaisuuksilla. Palvelutilit, työkuormat, putkistot, kaikki todennuksen avaimilla, joita kukaan ei omistanut eikä ne vanhentuneet. Ala vastasi paremmilla holveilla. Se on parempi holvi, ei ratkaisu.

Perustava väite oli siirtää ei-inhimillinen pääsy salaisuuksista identiteettiin. Tarkistettava työkuorman identiteetti, lyhytaikaiset tunnistetiedot, jotka myönnetään juuri oikeaan aikaan, politiikka toteutettuna suoraan. Ei koodin uudelleenkirjoituksia.

Agenttipohjainen AI teki tästä kiireellistä. Agentti on NHI, joka päättää ja pohtii ajon aikana, mitä työkaluja kutsua. Jos annat sille staattisen avaimen, olet antanut autonomiselle ohjelmistolle pysyvän pääsyn tuotantoon, ja agentit toimitetaan ilman mitään muutosprosessia; kehittäjä kytkee MCP‑palvelimen tiistaina ja se käsittelee asiakastietoja perjantaina.

Väite ei muuttunut. Laajuus kuitenkin. Identiteettipohjainen pääsy oli oikea vastaus työkuormille. Agenttien osalta se on ainoa toimiva ratkaisu: tiedä jokainen olemassa oleva agentti, anna jokaiselle vähiten toimivaltaa oletuksena, ja tarkasta jokainen toiminto. Ihmiset saivat IdP:n. Agentit tarvitsevat myös sellaisen, ja se on Hush.

Hush väittää, että yritysten AI-agenttien tulisi omistaa omat identiteettinsä ja delegoidut oikeudet sen sijaan, että ne yksinkertaisesti perisivät käyttäjiensä käyttöoikeudet. Miksi perinteiset identiteetti‑ ja pääsynhallintajärjestelmät (IAM) kamppailevat autonomisten agenttien kanssa, ja mitä on muutettava?

Ilmeisin tapaus on agentti, joka toimii käyttäjän puolesta. Vaikeampi tapaus on agentti ilman lainkaan käyttäjää: ajoitettu tehtävä, autonominen SOC‑vastaaja, putki, joka pohtii ja toimii itsenäisesti. Ei ole ketään, jolta delegoida, joten tiimit turvautuvat ainoaan käytössään olevaan työkaluun, staattiseen palvelutiliin, jossa on laajat oikeudet ja avain, joka ei koskaan vanhene. Tämä on sama jaettu‑salaisuusmalli, joka on ollut rikki vuosikymmenen ajan, nyt liitettynä improvisoivaan ohjelmistoon.

Toisessa päässä olevat järjestelmät pahentavat tilannetta. Useimmat sisäiset API:t, tietokannat ja MCP‑palvelimet eivät tee todellista valtuutusta. Ne tarkistavat, onko sinulla kelvollinen token, eivätkä mitä voit tehdä sillä. Omistus on yhtä kuin lupa.

Mitä on muutettava: jokainen agentti saa oman identiteettinsä, joka myönnetään kryptografisesti, riippumatta siitä, onko sen takana ihminen. Pääsy myönnetään toiminnon mukaan, lyhytaikaisesti ja rajoitetusti, politiikka toteutettuna suoraan eikä luotettuna kohdejärjestelmään. Kun käyttäjä on läsnä, agentin oikeudet ovat käyttäjän mahdollisuuksien ja sen, mitä agentin on sallittu tehdä kyseisessä tehtävässä, leikkaus. Kun käyttäjää ei ole, agentin oma identiteetti ja politiikka kertovat koko tarinan. Ihmiset saivat vähiten oikeuksia. Agentit tarvitsevat vähiten toimivaltaa.

Käytät käsitettä “vähiten toimivaltaa” keskustellessasi AI-turvallisuudesta. Miten vähiten toimivalta eroaa perinteisestä kyberturvallisuuden periaatteesta, eli vähiten oikeuksista, ja miten organisaatiot voivat tarkasti määrittää, mitä AI‑agentin tulisi sallia tehdä tietyn tehtävän osalta?

Agentit eivät omaa kiinteää käyttäytymistä. Jos annat yhdelle lukuoikeuden CRM:ään ja kirjoitusoikeuden sähköpostiin, et ole myöntänyt kahta erillistä oikeutta, vaan olet myöntänyt kaikki polut niiden välillä. Vähiten oikeuksia rajoittaa, mitä agentti voi koskettaa. Se ei kerro, mitä sen tulisi tehdä niiden kanssa.

Least agency lisää puuttuvan ulottuvuuden: mitkä toiminnot, mille tehtävälle, juuri nyt. Lipun triagoiva agentti tarvitsee lukea ja kommentoida. Sen ei tarvitse sulkea, poistaa tai koskea laskutukseen, vaikka token sen sallisi. Kun tehtävä päättyy, pääsy päättyy.

Päätös siitä, mitä on sallittua, alkaa havainnoinnista, ei arvailusta. Aja agentti, tarkkaile mitä se todella kutsuu, ja anna sen määrittää peruslinja. Sitten tarkenna kolmen syötteen avulla: tehtävä, johon se on olemassa, käyttäjä, jonka puolesta se toimii (ei koskaan enempää kuin käyttäjä itse voisi tehdä), ja jokaisen toiminnon vaikutusalue, koska kommentin julkaisemisen ja maksun käsittelyn ei pitäisi jakaa samaa hyväksyntäpolkua.

Least privilege päätti, kuka saa avaimet. Least agency päättää, mitä ne voivat tehdä sisäänpäästyään.

Lainamme usein identiteettiämme agentille, mutta emme halua, että agentilla on samat käyttöoikeudet kuin meillä – tämä on least agency -määritelmä.

Hush keräsi äskettäin $30 miljoonaa Series A, mikä nosti kokonaisrahoituksen $41 miljoonaan, ja Akamai liittyi strategiseksi sijoittajaksi Battery Venturesin ja YL Venturesin ohella. Mitä Akamain osallistuminen tuo pääomaa lukuun ottamatta, ja miten odotat kumppanuuden vaikuttavan Hushin laajentumiseen yritysten AI-agenttiturvallisuuteen?

Akamai sijaitsee suurimpien maailman yritysten liikenteen reitillä, ja juuri siellä agenttiturvallisuuden on oltava. Et hallinnoi agenttia hallintapaneelista jälkikäteen. Hallinnoi sitä suoraan, sillä hetkellä kun se kutsuu työkalua tai API:a. Akamai rakensi liiketoimintansa tähän malliin.

Pääoman lisäksi he tuovat kolme asiaa: jakelun CISO:ille, jotka jo kysyvät, miten agentteja ja MCP‑liikennettä hallitaan; vahvistuksen, että agenttien identiteetti on oma luokkansa, ei vain ominaisuus; sekä vuosikymmenten kokemuksen kone‑kone‑liikenteen suojaamisesta globaalilla mittakaavalla, mikä on juuri se, mihin agentti‑työkalu‑liikenne on menossa.

Model Context Protocol (MCP) on nopeasti nousemassa tärkeäksi kerrokseksi AI‑agenttien yhdistämisessä työkaluihin ja yritystietoihin. Turvallisuuden näkökulmasta, mitä uusia riskejä MCP tuo, ja miten organisaatioiden tulisi ajatella identiteettiä ja valtuutusta agentin, MCP‑palvelimen ja taustaresurssin välillä?

MCP teki agentin yhdistämisen työkaluun triviaaliksi. Se on riski. Kehittäjä lisää palvelimen konfigurointitiedostoon, ja malli voi nyt lukea Jiran, kysyä tietokantaa tai lähettää sähköpostia. Ei tarkistusta, ei inventaariota, ei politiikkaa. Turvallisuus saa tiedon vasta, kun jokin menee pieleen.

Nyt on kolme uutta ongelmaa:

1. Shadow MCP – kukaan ei tiedä, kuinka monta palvelinta on käynnissä tai mitä ne koskettavat.
2. Credential sprawl – suurin osa palvelimista autentikoi staattisella tokenilla, joka antaa koko pinnan käyttöoikeuden, joten agentti saa kaiken, mitä token voi tehdä.
3. Kaatunut ketju – resurssi näkee vain MCP‑palvelimen tunnistetiedot, eikä se pysty kertomaan, mikä agentti, minkä käyttäjän puolesta, teki kutsun. Identiteetin on oltava jokaisen vuorovaikutuksen perusta, pääsyn on oltava tilapäinen, rajattu ja perustuttava agentin ja käyttäjän oikeuksiin.

Hush rakennettiin alun perin ajatuksen ympärille, että staattiset salaisuudet ja pitkäikäiset tunnistetiedot ovat rikkinäinen perusta koneiden pääsylle. Koska suurin osa yritys‑infrastruktuurista edelleen luottaa voimakkaasti API‑avaimiin, tokeneihin ja muihin salaisuuksiin, miten yritykset voivat realistisesti siirtyä identiteettipohjaiseen, lyhytikäiseen pääsyyn ilman koko teknologiakokonaisuuden uudelleenrakentamista?

Et rakenna uudelleen. Kukaan, joka väittää toisin, ei ole tavannut yritystä. Suurin osa siitä, mitä suojaamme, on syntynyt ennen termiä ei‑ihmisidentiteetti, eikä sitä ole uudelleenkirjoitettu.

Siksi emme pyydä sitä. Hush otetaan käyttöön ilman koodimuutoksia ja sijoittuu pääsypolulle. Ensimmäinen askel on kartoitus: jokainen salaisuus, kuka sitä käyttää, mihin se ulottuu, mitä se oikeasti tekee ajon aikana. Useimmat yritykset eivät ole koskaan nähneet tätä kuvaa.

Sitten se on matka, ei migraatio. Kartoitus näyttää, mitkä salaisuudet ovat kuolleita, ylikattavia tai suurimman riskin alaisia. Korjaa ne ensin. Sitten vaihda staattiset avaimet lyhytikäisiin, identiteetti‑myönnettyihin tunnistetietoihin yksi järjestelmä kerrallaan. Sovellus luulee edelleen käyttävänsä avainta. Avain vain lakkaa olemaan pitkäikäinen, ja politiikka siirtyy meille.

Sama malli kattaa viisitoista‑vuotiaan Java‑palvelun ja viime viikolla otetun MCP‑palvelimen. Aloita riskialueelta, todista toimivuus, jatka eteenpäin.

AI‑agentit työskentelevät yhä enemmän ihmisten puolesta ja monissa tapauksissa delegoivat tehtäviä muille agenteille. Kun nämä monen agentin työnkulut monimutkaistuvat, miten pidät selkeän identiteetin, valtuutuksen, omistajuuden ja vastuullisuuden ketjun jokaiselle tapahtumalle?

Epäonnistumismalli: käyttäjä pyytää orkestroijaa, se delegoi toiselle agentille, joka kutsuu työkalua MCP‑palvelimen kautta, joka puolestaan osuu tietokantaan palvelutilillä. Neljä hyppyä myöhemmin loki näyttää yhden asian, kelvollisen tokenin. Kuka pyysi, kuka päätti ja kuka on vastuussa, on kadonnut.

Korjaus on estää identiteetin romahtaminen missään hyppyssä. Jokaisella agentilla on oma kryptografinen identiteettinsä. Kun se delegoi, se ei luovuta omaa tokeniaan. Se myöntää rajatun delegoinnin: tämä aliedentti, tämä tehtävä, nämä toiminnot, käyttäjän puolesta. Jokainen hyppy kantaa koko ketjun ja omat oikeutensa.

Vastuullisuus syntyy toteuttamalla ja kirjaamalla tapahtumat suoraan toiminnan kohteessa. Yhdyskäytävän loki tallentaa, mitä sille sallittiin tehdä, mitä se kutsui ja sen takana oleva ketju.

Moni‑agenttijärjestelmistä tulee vaikeampia hahmottaa. Kunkin toiminnon hallintaketjun ei tarvitse olla.

Prompt‑injektio ja muut hyökkäykset voivat mahdollisesti manipuloida muuten laillisen AI‑agentin suorittamaan toimintoja, joita sen operaattori ei koskaan aikonut. Kuinka pitkälle identiteettipohjaiset käyttöoikeusvalvonnat voivat rajoittaa vahinkoa, jonka kompromettoitu tai manipuloitu agentti aiheuttaa, vaikka taustalla oleva AI‑malli käyttäytyy virheellisesti?

Et voi estää prompt‑injektioita mallitasolla. Mallit on suunniteltu lukemaan epäluotettavaa sisältöä. Oleta, että agentti lopulta suostuu johonkin väärään. Kysymys on, mitä se voi tehdä, kun näin tapahtuu.

Identiteettipohjainen käyttöoikeus rajoittaa vaikutusaluetta. Manipuloitu agentti, jolla on vähiten valtaa, voi väärinkäyttää vain ne toiminnot, jotka sille on myönnetty kyseistä tehtävää varten. Jos se voi lukea tukipyyntöjä ja julkaista kommentteja, mikään injektio ei saa sitä vuotamaan asiakastietokantaa. Tokenilla ei ole siihen riittävää ulottuvuutta.

Käyttäjän attribuutio pitää ketjun eheänä: kuka käyttäjä, mikä agentti, mikä tehtävä, jokaisessa kutsussa. Agentti ei koskaan ylitä käyttäjän oikeuksia, ja jokainen toiminto voidaan jäljittää takaisin.

Poikkeamien havaitseminen nappaa sen, mitä politiikka sallii, mutta jonka tarkoitus ei toteutunut. Agentti, joka normaalisti lukee viisi tietuetta ja yhtäkkiä hakee viisituhatta, poikkeaa normaalista, vaikka jokainen kutsu olisi valtuutettu. Koska yhdyskäytävä toimii suoraan ja tuntee peruslinjan, se voi merkitä tai estää sen reaaliajassa.

Malli on joskus väärä. Rajattu identiteetti, attribuutio ja käyttäytymisperuslinjat tekevät virheestä selviytyvän.

Hush keskittyy ensisijaisesti AI:n turvaamiseen, mutta miten hyödynnätte AI:ta itse Hushissa? Onko esimerkiksi alueita, kuten ei‑ihmisidentiteettien löytäminen, käyttömallien analysointi, riskien priorisointi tai politiikkojen toteuttaminen, joissa AI voi merkittävästi parantaa turvallisuusalustaa?

Käytämme sitä siellä, missä se ansaitsee paikkansa.

Tuotteessa haaste ei ole salaisuuksien löytäminen, vaan niiden ymmärtäminen. Avain ilmestyy liikenteeseen. Työkuorman identiteetti, toimittajien integraatio, kehitys‑testitoken, kuollut tunnistetieto? LLM lukee suoritusaikaisen kontekstin ja omistajan signaalit ja ehdottaa vastausta luottamuspisteillä. Se tiivistää, mitä identiteetti todellisuudessa tekee selkeällä inhimillisellä kielellä, jolloin politiikka on sellainen, jonka ihminen hyväksyy. Se luokittelee riskin todellisen vaikutusalueen ja räjähdysalan perusteella, ei staattisen vakavuuden. Valvonta pysyy deterministisenä. AI auttaa politiikan kirjoittamisessa – se ei saa äänestysvaltaa suoritusaikana.

Hushin sisällä agenttipohjainen ohjelmointi muutti aikatauluamme. Ominaisuudet, jotka aiemmin veivät sprintin, vievät nyt päiviä, ja toimitamme integraatioita nopeudella, jonka Series A -tiimi ei muuten olisi voinut sallia. LLM:t priorisoivat tukipyyntöjä, ryhmittelevät perimmäiset syyt ja tuovat esiin asiakkaiden toiveet tiekarttakeskusteluihin. Oma MCP‑yhdyskäytävämme sijaitsee kaiken edessä, auttaen asiakkaitamme hahmottamaan ja hyödyntämään NHI‑ ja agenttiriskejä.

Hush kertoo, että useat Fortune 500 -yritykset käyttävät nyt sen teknologiaa, kun taas Kyndryl on ottanut Hushin käyttöön sisäisesti ja aloittanut sen jälleenmyynnin yritysasiakkaille. Mitä opitte näistä laajamittaisista käyttöönotosta todellisista hallintahaasteista, joita yritykset kohtaavat, kun AI‑agentit siirtyvät kokeiluvaiheesta tuotantoon?

Kukaan ei tiedä, mitä heillä on. Jokainen suuri käyttöönotto alkaa samalla tavalla: turvallisuus uskoo tuotannossa olevan kymmeniä agenteja, mutta löydöt paljastavat satoja, jotka jo käsittelevät asiakastietoja. Hallintahaaste ei ole politiikka, vaan ensin inventaario.

Tunnistetiedot ovat pahempia kuin agentit. Lähes jokainen tuotanto‑agentti toimii staattisella palvelutilillä, joka on luotu ennen sitä, ja jolla on vuosien aikana kerättyjä oikeuksia muuhun tarkoitukseen. Sillä ei ole rajattua käyttöoikeutta.

Omistajuus puuttuu. Kysyt, kuka on vastuussa agentista tai NHI:stä, ja saat korkeintaan tiimin nimen, entisen alihankkijan tai hiljaisuuden.

Ja ostaja vaihtui. Tämä oli alusta‑tiimin ongelma. Nyt CISO omistaa sen, koska hallitus sitä vaatii. Tämä siirsi meidät pilotteista yritystason käyttöönottoihin, ja siksi Kyndryl otti sen käyttöön sisäisesti ennen jälleenmyyntiä.

Agentit eivät luoneet uusia hallintahaasteita. Ne ottivat ne ongelmat, joita yritykset ovat jättäneet huomiotta vuosikymmenen ajan palvelutilien kanssa, ja pahensivat ne merkittävästi.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa käydä Hush Security -sivustolla.