Micha Rave, CEO și co-fondator al Hush Security – Seria de interviuri

Micha Rave, CEO și co-fondator al Hush Security, este un executiv cu experiență în securitatea cibernetică și tehnologie, a cărei carieră cuprinde inginerie software, management de produs, rețelistică enterprise, securitate cloud și identitate. Înainte de a co-fonda Hush Security în 2024, a petrecut peste cinci ani la Proofpoint în calitate de Senior Director de Product Management pentru Cloud Security, unde a fost responsabil pentru liniile de produse Zero Trust Network Access (ZTNA) și Secure Web Gateway (SWG). Anterior a ocupat funcția de VP de Product Management la Meta Networks, concentrându-se pe rețelistică enterprise și securitate, și a deținut roluri de conducere în product și engineering la HARMAN International, Redbend, SanDisk, Hola, Jungo și Elbit Systems. Background‑ul său combină dezvoltarea practică de software cu peste două decenii de experiență în construirea și comercializarea produselor de securitate, rețelistică, virtualizare și tehnologie încorporată.

Hush Security este o companie de securitate cibernetică axată pe protejarea agenților AI și a altor identități non-umane prin înlocuirea acreditărilor pe termen lung și a secretelor statice cu acces bazat pe identitate și controlat prin politici. Platforma sa descoperă agenții AI, inclusiv agenții shadow și cei dezvoltați intern, le atribuie identități verificabile și guvernează interacțiunile lor cu sistemele enterprise utilizând permisiuni limitate, acordate în timp real, politici centralizate și înregistrări de activitate auditabile. Compania a fost fondată de veterani în securitate din echipa care a dezvoltat Meta Networks, pe care Proofpoint a achiziționat-o în 2019. În iulie 2026, Hush a strâns o rundă Series A de 30 de milioane de dolari, cu Akamai Technologies alăturându-se ca investitor strategic alături de Battery Ventures și YL Ventures, aducând finanțarea totală la 41 de milioane de dolari pe măsură ce compania își extinde tehnologia pentru guvernarea agenților AI enterprise și a infrastructurii non-umane.

Înainte de a fonda Hush Security, ați petrecut ani construind și conducând produse de securitate, inclusiv securitatea cloud la Proofpoint. Ce ați observat pe piață care v-a convins că există o nevoie de a înființa Hush și cum a evoluat acea teză inițială odată cu ascensiunea rapidă a AI‑ului agentic?

La Proofpoint am observat cum întreprinderile rezolvă identitatea umană, în timp ce tot ce este non-uman încă funcționa pe secrete statice. Conturi de serviciu, sarcini de lucru, fluxuri de lucru, toate autentificându-se cu chei pe care nimeni nu le deținea și care nu expirau. Industria a răspuns cu seifuri mai bune. Aceasta este un seif mai bun, nu o soluție.

Teza fondatoare a fost să mutăm accesul non-uman de la secrete la identitate. Identitate verificabilă a sarcinilor de lucru, acreditări pe termen scurt emise în timp real, politică aplicată inline. Fără rescrieri de cod.

AI‑ul agentic a făcut acest lucru urgent. Un agent este un NHI care raționează și decide în timpul execuției ce instrumente să invoce. Dacă îi oferi o cheie statică, îi acorzi software‑ului autonom acces permanent la producție, iar agenții sunt livrați în afara oricărui proces de schimbare; un dezvoltator conectează un server MCP marți și acesta atinge datele clienților până vineri.

Teza nu s‑a schimbat. Scopul s‑a schimbat. Accesul bazat pe identitate a fost răspunsul corect pentru sarcinile de lucru. Pentru agenți este singurul viabil: cunoaște fiecare agent existent, oferă fiecăruia cel mai mic grad de agenție implicit și auditează fiecare acțiune. Oamenilor li s‑a furnizat un IdP. Agenților le este necesar unul și acesta este Hush.

Hush susține că agenții AI enterprise ar trebui să aibă propriile identități și permisiuni delegate, în loc să moștenească pur și simplu drepturile de acces ale oamenilor care îi utilizează. De ce sistemele tradiționale de Identity and Access Management (IAM) întâmpină dificultăți cu agenții autonomi și ce trebuie să se schimbe?

Cazul evident este un agent care acționează pentru un utilizator. Cazul mai dificil este un agent fără niciun utilizator: un job programat, un răspunzător SOC autonom, un pipeline care raționează și acționează de unul singur. Nu există pe nimeni de la care să se deleghe, așa că echipele recurg la singura unealtă disponibilă, un cont de serviciu static cu permisiuni largi și o cheie care nu expiră niciodată. Acesta este același model de secret partajat care se rupe de un deceniu, acum atașat la software care improvizează.

Sistemele de la capătul celălalt agravează situația. Majoritatea API‑urilor interne, bazelor de date și serverelor MCP nu efectuează o autorizare reală. Ele verifică dacă deții un token valid, nu ce ești autorizat să faci cu acesta. Deținerea înseamnă permisiune.

Ce trebuie să se schimbe: fiecare agent primește propria identitate, emisă criptografic, indiferent dacă există sau nu un om în spatele său. Accesul este acordat pe acțiune, pe termen scurt și limitat, cu politică aplicată inline, în loc să se încredințeze sistemului țintă. Când există un utilizator, permisiunile agentului sunt intersecția dintre ceea ce utilizatorul poate face și ceea ce acel agent are voie să facă pentru sarcina respectivă. Când nu există, identitatea și politica agentului reprezintă întreaga poveste. Oamenilor li s‑a oferit cel mai mic privilegiu. Agenților le trebuie cel mai mic grad de agenție.

Folosiți conceptul de „cel mai mic grad de agenție” când discutați securitatea AI. Cum diferă cel mai mic grad de agenție de principiul tradițional al securității cibernetice de „cel mai mic privilegiu” și cum pot organizațiile să determine exact ce ar trebui să fie permis unui agent AI pentru o sarcină specifică?

Agenții nu au un comportament fix. Dacă acorzi unuia acces de citire la un CRM și acces de scriere la email, nu ai acordat două permisiuni, ci ai acordat fiecare cale dintre ele. Cel mai mic privilegiu limitează ce poate atinge un agent. Nu spune nimic despre ce ar trebui să facă cu acel acces.

Least agency adaugă dimensiunea lipsă: ce acțiuni, pentru ce sarcină, chiar acum. Un agent care triagează tichete trebuie să citească și să comenteze. Nu trebuie să închidă, să șteargă sau să atingă facturarea, chiar dacă tokenul permite acest lucru. Când sarcina se încheie, accesul se încheie.

Decizia a ceea ce este permis începe cu observația, nu cu presupunerea. Rulați agentul, urmăriți ce apelează efectiv și lăsați asta să definească linia de bază. Apoi restrângeți utilizând trei intrări: sarcina pentru care există, utilizatorul pentru care acționează (niciodată mai mult decât ar putea face el) și raza de acțiune a fiecărei operațiuni, deoarece postarea unui comentariu și procesarea unei plăți nu ar trebui să împărtășească același traseu de aprobare.

Principiul celui mai mic privilegiu decide cine primește cheile. Principiul celei mai mici agenții decide ce pot face odată ce sunt în interior.

Adesea „împrumutăm” identitatea noastră agentului, dar nu dorim ca agentul să aibă același nivel de permisiuni pe care le avem noi – aceasta este definiția principiului celei mai mici agenții.

Hush a strâns recent o Seria A de 30 de milioane de dolari, aducând finanțarea totală la $41 million, cu Akamai alăturându-se ca investitor strategic alături de Battery Ventures și YL Ventures. Ce aduce implicarea Akamai dincolo de capital și cum așteptați ca parteneriatul să influențeze extinderea Hush în securitatea agenților AI pentru întreprinderi?

Akamai se află în calea de trafic a majorității întreprinderilor din lume și exact acolo trebuie să trăiască securitatea agenților. Nu guvernați un agent dintr-un tablou de bord după ce s-a întâmplat. Îl guvernați în linie, în momentul în care apelează un instrument sau un API. Akamai și-a construit afacerea pe acest model.

Dincolo de capital, aduc trei lucruri: distribuție către CIO-urile care deja se întreabă cum să controleze agenții și traficul MCP; validarea că identitatea agentului este o categorie reală, nu o funcționalitate; și decenii de experiență în securizarea traficului mașină-la-mașină la scară globală, care este exact ce va deveni traficul agent-la-instrument.

Model Context Protocol (MCP) devine rapid un strat important pentru conectarea agenților AI cu instrumente și date enterprise. Din perspectivă de securitate, ce noi riscuri introduce MCP și cum ar trebui organizațiile să abordeze identitatea și autorizarea între agent, serverul MCP și resursa de bază?

MCP a făcut ca conectarea unui agent la un instrument să fie trivială. Acesta este riscul. Un dezvoltator adaugă un server într-un fișier de configurare și modelul poate acum să citească Jira, să interogheze o bază de date sau să trimită e‑mail. Fără revizuire, fără inventar, fără politică. Securitatea află când ceva se strică.

Există acum trei probleme noi:

1. Shadow MCP – nimeni nu știe câte servere rulează sau ce accesează.
2. Răspândirea acreditărilor – majoritatea serverelor se autentifică cu un token static care acordă întreaga suprafață, astfel că agentul primește tot ce poate tokenul.
3. Lanțul colapsat – resursa vede doar acreditarea serverului MCP, deci nu poate spune ce agent, acționând pentru ce utilizator, a făcut apelul. Identitatea trebuie să fie la baza fiecărei interacțiuni, accesul să fie efemer, limitat și bazat pe permisiunile agentului și ale utilizatorului.

Hush a fost inițial construit în jurul ideii că secretele statice și acreditările pe termen lung reprezintă o fundație defectuoasă pentru accesul mașinilor. Având în vedere că majoritatea infrastructurii enterprise se bazează încă puternic pe chei API, tokenuri și alte secrete, cum pot companiile să treacă realist la acces bazat pe identitate, pe termen scurt, fără a reconstrui întregul stack tehnologic?

Nu reconstruiți. Nimeni care spune altceva nu a întâlnit o întreprindere. Majoritatea lucrurilor pe care le protejăm preced expresia identitate non‑umană și nu se rescrie.

Așadar nu cerem asta. Hush se implementează fără modificări de cod și se poziționează în calea de acces. Primul pas este descoperirea: fiecare secret, cine îl folosește, la ce ajunge, ce face efectiv în timpul execuției. Majoritatea companiilor nu au văzut niciodată această imagine.

Apoi este o călătorie, nu o migrare. Descoperirea arată care secrete sunt moarte, supra‑scopate sau cu risc maxim. Remediați-le mai întâi. Apoi înlocuiți cheile statice cu acreditări pe termen scurt, emise de identitate, sistem cu sistem. Aplicația încă crede că folosește o cheie. Cheia pur și simplu nu mai este pe termen lung, iar politica trece la noi.

Același model acoperă un serviciu Java de cincisprezece ani și un server MCP instalat săptămâna trecută. Începeți de unde este riscul, demonstrați, continuați.

Agentii AI vor lucra din ce în ce mai mult în numele oamenilor și, în multe cazuri, vor delega sarcini altor agenți. Pe măsură ce aceste fluxuri de lucru multi‑agent devin mai complexe, cum mențineți un lanț clar de identitate, autorizare, proprietate și responsabilitate pentru fiecare acțiune care are loc?

Modul de eșec: un utilizator solicită unui orchestrator, acesta delegă unui al doilea agent, care apelează un instrument printr-un server MCP, care accesează o bază de date cu un cont de serviciu. Patru salturi mai târziu, jurnalul arată un singur lucru, un token valid. Cine a solicitat, cine a decis și cine este responsabil au dispărut.

Remedierea constă în refuzarea colapsului identității la orice salt. Fiecare agent are propria identitate criptografică. Când delegă, nu își transmite tokenul. Emite o delegare limitată: acest sub‑agent, această sarcină, aceste acțiuni, în numele acestui utilizator. Fiecare salt poartă lanțul complet și propriile permisiuni.

Responsabilitatea provine din aplicarea și înregistrarea în linie, la momentul acțiunii. Înregistrarea gateway-ului cu privire la ce i s-a permis să facă, ce a apelat și lanțul din spatele acestuia.

Sistemele multi-agent vor deveni mai greu de înțeles. Lanțul de custodie pentru fiecare acțiune nu este obligatoriu.

Injectarea de prompturi și alte atacuri pot manipula un agent AI legitimat să efectueze acțiuni pe care operatorul său nu le-a intenționat niciodată. În ce măsură pot controalele de acces bazate pe identitate să limiteze pagubele cauzate de un agent compromis sau manipulat, chiar și atunci când modelul AI de bază se comportă incorect?

Nu vei opri injectarea de prompturi la nivelul modelului. Modelele citesc conținut neverificat prin design. Presupune că agentul va fi în cele din urmă convins să facă ceva greșit. Întrebarea este ce poate face atunci când se întâmplă asta.

Accesul bazat pe identitate limitează raza de acțiune. Un agent manipulat cu cea mai mică autonomie poate abuză doar de acțiunile care i s-au acordat pentru acea sarcină. Dacă poate citi tichete și posta comentarii, nicio injectare nu îl face să exfiltreze baza de date a clientului. Token-ul nu are acea acoperire.

Atribuirea utilizatorului păstrează lanțul intact: ce utilizator, ce agent, ce sarcină, la fiecare apel. Agentul nu depășește niciodată ce ar fi putut face utilizatorul, iar fiecare acțiune poate fi urmărită înapoi.

Detectarea anomaliilor prinde ceea ce politica permite, dar intenția nu a făcut-o. Un agent care în mod normal citește cinci înregistrări și brusc extrage cinci mii este în afara caracterului, chiar dacă fiecare apel este autorizat. Deoarece gateway-ul rulează în linie și cunoaște linia de bază, poate semnala sau bloca acest lucru în timp real.

Modelul va greși uneori. Identitatea delimitată, atribuirea și bazele comportamentale fac greșelile suportabile.

Hush se concentrează în principal pe securizarea AI, dar cum utilizați AI în interiorul Hush? Există domenii precum descoperirea identităților non-umane, analizarea tiparelor de acces, prioritizarea riscurilor sau aplicarea politicilor în care AI poate îmbunătăți semnificativ platforma de securitate?

O utilizăm ori de câte ori își justifică prezența.

În produs, partea dificilă nu este găsirea secretelor, ci înțelegerea lor. O cheie apare în trafic. Identitate de sarcină, integrare cu furnizorii, token de testare pentru dezvoltare, acreditare moartă? Un LLM citește contextul de rulare și semnalele proprietarului și propune un răspuns cu un scor de încredere. Rezumă ce face efectiv o identitate în limbaj simplu, astfel încât politica să fie una pe care un om o va aproba. Evaluează riscul în funcție de acoperirea reală și raza de acțiune, nu de severitatea statică. Aplicarea rămâne deterministă. AI ajută la redactarea politicii – nu primește un vot în timpul rulării.

În Hush, programarea agentică ne-a schimbat ritmul. Funcționalități care necesitau un sprint durează zile, iar noi livrăm integrări într-un ritm pe care o echipă Series A nu și-l poate permite. LLM-urile trierează tichetele de suport, grupează cauzele rădăcină și expun solicitările clienților pentru discuții de roadmap. Propriul nostru gateway MCP se află în fața tuturor acestor componente, ajutând clienții să raționeze și să consume NHI și riscul agentic.

Hush afirmă că multiple companii Fortune 500 utilizează acum tehnologia sa, în timp ce Kyndryl a implementat Hush intern și a început să o revândă clienților enterprise. Ce învățați din aceste implementări la scară largă despre problemele de guvernanță din viața reală pe care companiile le întâmpină odată ce agenții AI trec de la experimentare la producție?

Nimeni nu știe ce are. Fiecare implementare mare începe în același mod: securitatea crede că există o duzină de agenți în producție, descoperirea găsește sute, deja accesând datele clienților. Problema de guvernanță nu este politica, ci inventarierea inițială.

Credențialele sunt mai rele decât agenții. Aproape fiecare agent de producție rulează pe un cont de serviciu static, anterior existenței sale, cu permisiuni acumulate de-a lungul anilor pentru altceva. Nu a primit acces delimitat.

Lipsesc responsabilitățile. Dacă întrebi cine este responsabil pentru un agent sau pentru un NHI, primești cel mult numele unei echipe, un contractor plecat sau tăcere.

Și cumpărătorul s-a schimbat. Aceasta era o problemă a echipei de platformă. Acum CISO-ul îl deține deoarece consiliul solicită acest lucru. Aceasta ne-a mutat de la proiecte pilot la lansări enterprise și explică de ce Kyndryl a implementat intern înainte de a revinde.

Agenții nu au creat noi probleme de guvernanță. Au preluat cele pe care întreprinderile le-au ignorat timp de un deceniu cu conturile de serviciu și le-au agravat semnificativ.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze Hush Security.