Micha Rave, CEO i współzałożyciel Hush Security – seria wywiadów

Micha Rave, CEO i współzałożyciel Hush Security, jest doświadczonym menedżerem ds. cyberbezpieczeństwa i technologii, którego kariera obejmuje inżynierię oprogramowania, zarządzanie produktami, sieci korporacyjne, bezpieczeństwo w chmurze i tożsamość. Przed współzałożeniem Hush Security w 2024 r. spędził ponad pięć lat w Proofpoint jako starszy dyrektor ds. zarządzania produktem w obszarze bezpieczeństwa w chmurze, gdzie był odpowiedzialny za linie produktów Zero Trust Network Access (ZTNA) oraz Secure Web Gateway (SWG). Wcześniej pełnił funkcję wiceprezesa ds. zarządzania produktem w Meta Networks, koncentrując się na sieciach korporacyjnych i bezpieczeństwie, a także zajmował stanowiska kierownicze w dziedzinie produktu i inżynierii w firmach HARMAN International, Redbend, SanDisk, Hola, Jungo i Elbit Systems. Jego doświadczenie łączy praktyczne programowanie z ponad dwudziestoletnim doświadczeniem w budowaniu i komercjalizacji produktów z zakresu bezpieczeństwa, sieci, wirtualizacji oraz technologii wbudowanych.

Hush Security jest firmą zajmującą się cyberbezpieczeństwem, koncentrującą się na zabezpieczaniu agentów AI oraz innych tożsamości niebędących ludźmi poprzez zastąpienie długotrwałych poświadczeń i statycznych sekretów dostępem opartym na tożsamości i kontrolowanym politykami. Jej platforma wykrywa agenty AI, w tym agenty cieniowe i wewnętrznie opracowane, przydziela im weryfikowalne tożsamości i zarządza ich interakcjami z systemami korporacyjnymi przy użyciu ograniczonych, przyznawanych w czasie rzeczywistym uprawnień, scentralizowanych polityk oraz audytowalnych zapisów aktywności. Firma została założona przez weteranów bezpieczeństwa z zespołu stojącego za Meta Networks, które Proofpoint przejęło w 2019 r. W lipcu 2026 r. Hush pozyskało $30 million Series A, przy czym Akamai Technologies dołączyło jako strategiczny inwestor obok Battery Ventures i YL Ventures, podnosząc łączną kwotę finansowania do $41 million, gdy firma rozwija technologię zarządzania agentami AI w przedsiębiorstwach oraz infrastrukturą niebędącą ludźmi.

Przed założeniem Hush Security spędziłeś lata budując i prowadząc produkty bezpieczeństwa, w tym bezpieczeństwo w chmurze w Proofpoint. Co zauważyłeś na rynku, co przekonało Cię, że istnieje potrzeba założenia Hush, i jak pierwotna teza ewoluowała wraz z szybkim rozwojem agentic AI?

W Proofpoint obserwowaliśmy, jak przedsiębiorstwa rozwiązują kwestie tożsamości ludzkiej, podczas gdy wszystko niebędące ludźmi nadal działało na statycznych sekretach. Konta serwisowe, obciążenia, potoki, wszystkie uwierzytelniane przy użyciu kluczy, które nikt nie posiadał i które nigdy nie wygasały. Branża odpowiedziała lepszymi sejfami. To lepszy sejf, a nie rozwiązanie.

Tezą założycielską było przeniesienie dostępu niebędącego ludźmi z sekretów na tożsamość. Weryfikowalna tożsamość obciążenia, krótkotrwałe poświadczenia przyznawane w czasie rzeczywistym, polityka egzekwowana w linii. Brak konieczności przepisania kodu.

Agentic AI uczyniło to pilnym. Agent jest NHI, które rozumuje i decyduje w czasie wykonywania, które narzędzia wywołać. Przekazanie mu statycznego klucza oznacza, że autonomiczne oprogramowanie uzyskuje stały dostęp do produkcji, a agenci są wdrażani poza jakimkolwiek procesem zmian; programista podłącza serwer MCP we wtorek i już w piątek dotyka danych klientów.

Teza się nie zmieniła. Zakres się zmienił. Dostęp oparty na tożsamości był właściwą odpowiedzią dla obciążeń. Dla agentów jest to jedyna działająca opcja: znać każdego istniejącego agenta, przyznać każdemu domyślnie minimalną agencję i audytować każde działanie. Ludzie otrzymali IdP. Agenci także jej potrzebują i to jest Hush.

Hush twierdzi, że agenci AI w przedsiębiorstwach powinni mieć własne tożsamości i delegowane uprawnienia, zamiast po prostu dziedziczyć prawa dostępu ludzi, którzy je używają. Dlaczego tradycyjne systemy zarządzania tożsamością i dostępem (IAM) mają trudności z autonomicznymi agentami i co musi się zmienić?

Oczywistym przypadkiem jest agent działający w imieniu użytkownika. Trudniejszym przypadkiem jest agent bez żadnego użytkownika: zaplanowane zadanie, autonomiczny responder SOC, potok, który sam rozumuje i działa. Nie ma nikogo, od kogo można delegować, więc zespoły wracają do jedynego dostępnego narzędzia – statycznego konta serwisowego z szerokimi uprawnieniami i kluczem, który nigdy nie wygasa. To ten sam model współdzielonego sekretu, który psuje się od dekady, a teraz jest powiązany z improwizującym oprogramowaniem.

Systemy po drugiej stronie pogarszają sytuację. Większość wewnętrznych API, baz danych i serwerów MCP nie wykonuje rzeczywistej autoryzacji. Sprawdzają, czy posiadasz ważny token, a nie co możesz zrobić przy jego użyciu. Posiadanie równa się uprawnieniu.

Co musi się zmienić: każdy agent otrzymuje własną tożsamość, wydawaną kryptograficznie, niezależnie od tego, czy za nim stoi człowiek. Dostęp jest przyznawany per akcja, krótkotrwały i ograniczony, a polityka jest egzekwowana w linii, a nie ufana systemowi docelowemu. Gdy istnieje użytkownik, uprawnienia agenta są przecięciem tego, co użytkownik może zrobić, i tego, co dany agent może wykonać w ramach zadania. Gdy takiego użytkownika nie ma, tożsamość i polityka samego agenta stanowią całość. Ludzie otrzymali zasadę najmniejszych uprawnień. Agenci potrzebują zasady najmniejszej agencji.

Używasz pojęcia „least agency” w dyskusjach o bezpieczeństwie AI. Jak „least agency” różni się od tradycyjnej zasady cyberbezpieczeństwa „least privilege” i jak organizacje mogą dokładnie określić, co agent AI powinien mieć zezwolenie wykonywać w ramach konkretnego zadania?

Agenci nie mają stałego zachowania. Przyznanie jednemu dostępu do odczytu w CRM i zapisu w e‑mailu nie oznacza przyznania dwóch uprawnień, lecz udzielenie każdej ścieżki pomiędzy nimi. Zasada najmniejszych uprawnień ogranicza, co agent może dotknąć. Nie mówi nic o tym, co powinien z tym zrobić.

Least agency dodaje brakujący wymiar: które działania, dla którego zadania, właśnie teraz. Agent przydzielający zgłoszenia musi móc czytać i komentować. Nie musi zamykać, usuwać ani dotykać rozliczeń, nawet jeśli token na to pozwala. Gdy zadanie się kończy, kończy się dostęp.

Decydowanie o tym, co jest dozwolone, zaczyna się od obserwacji, nie od domysłów. Uruchom agenta, obserwuj, co faktycznie wywołuje, i niech to określi bazę. Następnie zawęź to trzema czynnikami: zadaniem, do którego istnieje, użytkownikiem, którego reprezentuje (nigdy nie więcej niż on sam może zrobić) oraz zasięgiem każdej akcji, ponieważ publikowanie komentarza i realizacja płatności nie powinny dzielić tej samej ścieżki zatwierdzania.

Najmniejsze przywileje decydują, kto otrzymuje klucze. Najmniejsza agencja decyduje, co może zrobić po wejściu.

Często „pożyczamy” naszą tożsamość naszemu agentowi, ale nie chcemy, aby agent miał taki sam poziom uprawnień jak my – to jest definicja najmniejszej agencji.

Hush niedawno pozyskał runda serii A o wartości 30 mln dolarów, podnosząc łączną kwotę finansowania do $41 million, a Akamai dołączyło jako strategiczny inwestor wraz z Battery Ventures i YL Ventures. Co wnosi zaangażowanie Akamai poza kapitał i jak oczekujecie, że partnerstwo wpłynie na ekspansję Hush w zakresie bezpieczeństwa agentów AI w przedsiębiorstwach?

Akamai znajduje się w ścieżce ruchu większości światowych przedsiębiorstw i to właśnie tam musi funkcjonować bezpieczeństwo agentów. Nie zarządzasz agentem z pulpitu po fakcie. Zarządzasz nim inline, w momencie, gdy wywołuje narzędzie lub API. Akamai zbudowało swój model biznesowy na tej zasadzie.

Poza kapitałem wnoszą trzy rzeczy: dystrybucję do CISO, którzy już pytają, jak kontrolować agentów i ruch MCP; potwierdzenie, że tożsamość agenta jest rzeczywistą kategorią, a nie jedynie funkcją; oraz dekady doświadczenia w zabezpieczaniu ruchu maszynowego na skalę globalną, co właśnie ma stać się ruchem agent‑to‑tool.

Model Context Protocol (MCP) szybko staje się ważną warstwą łączącą agenty AI z narzędziami i danymi przedsiębiorstwa. Z perspektywy bezpieczeństwa, jakie nowe ryzyka wprowadza MCP i jak organizacje powinny myśleć o tożsamości oraz autoryzacji pomiędzy agentem, serwerem MCP a zasobem podstawowym?

MCP uczyniło podłączenie agenta do narzędzia trywialnym. To jest ryzyko. Programista dodaje serwer do pliku konfiguracyjnego i model może teraz czytać Jira, zapytać bazę danych lub wysłać e‑mail. Brak przeglądu, brak inwentaryzacji, brak polityki. Bezpieczeństwo dowiaduje się o problemie dopiero, gdy coś się zepsuje.

Obecnie pojawiają się trzy nowe problemy:

1. Shadow MCP – nikt nie wie, ile serwerów działa i do czego mają dostęp.
2. Rozproszenie poświadczeń – większość serwerów uwierzytelnia się statycznym tokenem, który przyznaje pełny dostęp, więc agent otrzymuje wszystko, co token może zrobić.
3. Zawieszony łańcuch – zasób widzi tylko poświadczenia serwera MCP, więc nie może określić, który agent, działający w imieniu którego użytkownika, wykonał wywołanie. Tożsamość musi znajdować się w bazie każdej interakcji, dostęp powinien być efemeryczny, ograniczony i oparty na uprawnieniach agenta i użytkownika.

Hush pierwotnie powstał wokół idei, że statyczne sekrety i długotrwałe poświadczenia są zepsytą podstawą dostępu maszynowego. Ponieważ większość infrastruktury przedsiębiorstw wciąż silnie opiera się na kluczach API, tokenach i innych sekretach, jak firmy mogą realistycznie przejść do dostępu opartego na tożsamości, krótkotrwałego, bez przebudowy całego stosu technologicznego?

Nie przebudowujemy. Nikt, kto twierdzi inaczej, nie spotkał się z przedsiębiorstwem. Większość tego, co chronimy, powstała przed określeniem tożsamość nie‑ludzka i nie jest przepisana.

Dlatego nie pytamy o to. Hush wdraża się bez zmian w kodzie i znajduje się w ścieżce dostępu. Pierwszy krok to odkrycie: każdy sekret, kto go używa, do czego dociera, co faktycznie robi w czasie działania. Większość firm nigdy nie widziała takiego obrazu.

To więc podróż, a nie migracja. Odkrycie pokazuje, które sekrety są nieaktywne, nadmiernie uprawnione lub najgroźniejsze. Najpierw naprawiamy te. Następnie wymieniamy statyczne klucze na krótkotrwałe, wydawane na podstawie tożsamości, po jednym systemie na raz. Aplikacja nadal myśli, że używa klucza. Klucz po prostu przestaje być długotrwały, a polityka przechodzi do nas.

Ten sam model obejmuje piętnastoletnią usługę Java oraz serwer MCP uruchomiony w zeszłym tygodniu. Zacznij tam, gdzie ryzyko jest największe, udowodnij skuteczność, kontynuuj.

Agenty AI będą coraz częściej działać w imieniu ludzi i, w wielu przypadkach, delegować zadania innym agentom. W miarę jak te wielo‑agentowe przepływy pracy stają się bardziej złożone, jak utrzymać przejrzysty łańcuch tożsamości, autoryzacji, własności i odpowiedzialności za każde działanie?

Tryb awaryjny: użytkownik pyta orchestratora, który deleguje do drugiego agenta, który wywołuje narzędzie przez serwer MCP, który trafia do bazy danych przy użyciu konta serwisowego. Cztery przeskoki później log pokazuje jedną rzecz – ważny token. Kto zapytał, kto podjął decyzję i kto jest odpowiedzialny, znikają.

Rozwiązanie polega na odmowie dopuszczenia do zaniknięcia tożsamości na jakimkolwiek przeskoku. Każdy agent ma własną kryptograficzną tożsamość. Gdy deleguje, nie przekazuje swojego tokenu. Wydaje ograniczoną delegację: ten pod‑agent, to zadanie, te akcje, w imieniu tego użytkownika. Każdy przeskok przenosi pełny łańcuch i własne uprawnienia.

Odpowiedzialność wynika z egzekwowania i rejestrowania w miejscu, w którym zachodzi działanie. Rejestr bramki zawiera informacje o tym, co było dozwolone, co wywołała oraz łańcuch stojący za tym.

Systemy wieloagentowe będą trudniejsze do zrozumienia. Łańcuch opieki nad każdą akcją nie musi.

Wstrzyknięcie promptu i inne ataki mogą potencjalnie zmanipulować pozornie legalnego agenta SI, aby podjął działania, których operator nigdy nie zamierzał. Do jakiego stopnia kontrola dostępu oparta na tożsamości może ograniczyć szkody spowodowane przez przejętego lub zmanipulowanego agenta, nawet gdy podstawowy model SI zachowuje się niepoprawnie?

Nie powstrzymasz wstrzyknięcia promptu na poziomie modelu. Modele z założenia odczytują niezweryfikowaną treść. Zakładaj, że agent ostatecznie zostanie namówiony do czegoś niewłaściwego. Pytanie brzmi, co może zrobić w takiej sytuacji.

Kontrola dostępu oparta na tożsamości ogranicza zasięg szkód. Zmanipulowany agent o minimalnych uprawnieniach może nadużywać jedynie działań przydzielonych mu do tego zadania. Jeśli może czytać zgłoszenia i publikować komentarze, żadne wstrzyknięcie nie spowoduje wycieku bazy danych klientów. Token nie ma takiego zasięgu.

Atrybucja użytkownika utrzymuje łańcuch nienaruszony: który użytkownik, który agent, które zadanie, przy każdym wywołaniu. Agent nigdy nie przekracza tego, co mógłby zrobić użytkownik, a każda akcja jest możliwa do odtworzenia.

Wykrywanie anomalii łapie to, co polityka zezwala, ale intencja nie. Agent, który zwykle odczytuje pięć rekordów, a nagle pobiera pięć tysięcy, zachowuje się niezgodnie z charakterem, nawet jeśli każde wywołanie jest autoryzowane. Ponieważ bramka działa w miejscu i zna bazowy poziom, może w czasie rzeczywistym oznaczyć lub zablokować takie zdarzenie.

Model będzie czasami błędny. Tożsamość w określonym zakresie, atrybucja i bazowe zachowania sprawiają, że błąd jest możliwy do przetrwania.

Hush koncentruje się głównie na zabezpieczaniu SI, ale jak wykorzystujecie SI wewnątrz samego Hush? Czy istnieją obszary, takie jak wykrywanie tożsamości niebędących ludźmi, analizowanie wzorców dostępu, priorytetyzacja ryzyka lub egzekwowanie polityk, w których SI może znacząco ulepszyć platformę bezpieczeństwa?

Używamy jej wszędzie tam, gdzie zasługuje na miejsce.

W produkcie trudną częścią nie jest znajdowanie sekretów, lecz ich rozumienie. Klucz pojawia się w ruchu sieciowym. Tożsamość obciążenia, integracja dostawcy, token testowy dewelopera, martwe poświadczenie? LLM odczytuje kontekst uruchomieniowy i sygnały właściciela oraz proponuje odpowiedź z oceną pewności. Streszcza, co tożsamość faktycznie robi w prostym języku ludzkim, dzięki czemu polityka jest taką, którą zatwierdzi człowiek. Ocenia ryzyko według rzeczywistego zasięgu i promienia rażenia, a nie statycznej ciężkości. Egzekwowanie pozostaje deterministyczne. SI pomaga pisać politykę – nie otrzymuje głosu w czasie wykonywania.

W Hush programowanie agentowe zmieniło nasz rytm pracy. Funkcje, które zajmowały sprint, teraz trwają dni, a my dostarczamy integracje w tempie, na które zespół na etapie Series A nie mógłby sobie pozwolić. LLM-y triagują zgłoszenia wsparcia, grupują przyczyny podstawowe i wyświetlają prośby klientów do dyskusji o roadmapie. Nasza własna bramka MCP znajduje się przed wszystkim, pomagając naszym klientom rozumieć i wykorzystywać NHI oraz ryzyko agentowe.

Hush twierdzi, że wiele firm z listy Fortune 500 korzysta teraz z ich technologii, podczas gdy Kyndryl wdrożył Hush wewnętrznie i rozpoczął jego odsprzedaż klientom korporacyjnym. Czego uczą się Państwo z tych szeroko zakrojonych wdrożeń o rzeczywistych problemach zarządzania, z którymi firmy spotykają się, gdy agenci SI przechodzą z fazy eksperymentów do produkcji?

Nikt nie wie, co posiada. Każde duże wdrożenie zaczyna się tak samo: bezpieczeństwo uważa, że w produkcji jest kilkanaście agentów, a odkrycie znajduje setki, już mające dostęp do danych klientów. Problem zarządzania nie polega na polityce, lecz najpierw na inwentaryzacji.

Poświadczenia są gorsze niż agenci. Prawie każdy agent produkcyjny działa na statycznym koncie serwisowym, które istnieje przed nim, z uprawnieniami nagromadzonymi przez lata dla innego celu. Nie otrzymało ono dostępu w określonym zakresie.

Brakuje właściciela. Zapytaj, kto jest odpowiedzialny za agenta lub NHI, a otrzymasz co najwyżej nazwę zespołu, byłego kontrahenta lub ciszę.

A nabywca się zmienił. To był problem zespołu platformowego. Teraz CISO jest właścicielem, ponieważ zarząd tego wymaga. To przeniosło nas z fazy pilotażowej do wdrożeń korporacyjnych i jest powodem, dla którego Kyndryl wdrożył wewnętrznie przed odsprzedażą.

Agenci nie stworzyli nowych problemów zarządzania. Przejęli te, które przedsiębiorstwa ignorowały przez dekadę w kontekście kont serwisowych, i pogorszyli je znacznie.

Dziękujemy za świetny wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Hush Security.