Micha Rave, CEO a spoluzakladatel Hush Security – série rozhovorů

Micha Rave, CEO a spoluzakladatel Hush Security, je zkušený výkonný ředitel v oblasti kybernetické bezpečnosti a technologií, jehož kariéra zahrnuje softwarové inženýrství, produktový management, podnikové sítě, cloudovou bezpečnost a identitu. Před založením Hush Security v roce 2024 strávil více než pět let ve společnosti Proofpoint jako senior ředitel produktového managementu pro cloudovou bezpečnost, kde byl zodpovědný za produktové řady Zero Trust Network Access (ZTNA) a Secure Web Gateway (SWG). Dříve působil jako viceprezident produktového managementu ve společnosti Meta Networks, zaměřený na podnikové sítě a bezpečnost, a zastával vedoucí pozice v produktovém a inženýrském řízení ve společnostech HARMAN International, Redbend, SanDisk, Hola, Jungo a Elbit Systems. Jeho zázemí kombinuje praktický vývoj softwaru s více než dvacetiletou zkušeností se stavbou a komercializací produktů v oblasti bezpečnosti, sítí, virtualizace a vestavěných technologií.

Hush Security je společnost zabývající se kybernetickou bezpečností, která se soustředí na zabezpečení AI agentů a dalších ne‑lidských identit nahrazením dlouhodobých pověření a statických tajemství přístupem založeným na identitě a řízeném politikou. Její platforma objevuje AI agenty, včetně stínových a interně vyvíjených agentů, přiřazuje jim ověřitelné identity a řídí jejich interakce s podnikovými systémy pomocí omezených oprávnění „just‑in‑time“, centralizovaných politik a auditovatelných záznamů o činnosti. Společnost byla založena veterány v oblasti bezpečnosti z týmu stojícího za Meta Networks, kterou v roce 2019 získala Proofpoint. V červenci 2026 získala Hush sérii A ve výši 30 milionů dolarů, přičemž Akamai Technologies se připojila jako strategický investor vedle Battery Ventures a YL Ventures, čímž celkové financování vzrostlo na 41 milion dolarů, zatímco společnost rozšiřuje svou technologii pro řízení podnikových AI agentů a ne‑lidské infrastruktury.

Před založením Hush Security jste strávili roky budováním a vedením bezpečnostních produktů, včetně cloudové bezpečnosti ve společnosti Proofpoint. Co jste na trhu zaznamenali, co vás přesvědčilo, že je potřeba založit Hush, a jak se původní teze vyvíjela s rychlým nárůstem agentické AI?

Ve společnosti Proofpoint jsme sledovali, jak podniky řeší lidskou identitu, zatímco vše ne‑lidské stále fungovalo na statických tajemstvích. Služební účty, pracovní zátěže, pipeline, všechny ověřované pomocí klíčů, které nikdo nevlastní a které nikdy nevyprší. Průmysl na to reagoval lepšími trezory. To je lepší trezor, nikoli řešení.

Zakládající teze spočívala v přesunu ne‑lidského přístupu od tajemství k identitě. Ověřitelná identita pracovního zatížení, krátkodobá pověření vydávaná just‑in‑time, politika vynucovaná přímo v řádku. Žádné přepisování kódu.

Agentická AI to učinila naléhavou. Agent je NHI, který v reálném čase uvažuje a rozhoduje, které nástroje zavolat. Pokud mu dáte statický klíč, poskytujete autonomnímu softwaru trvalý přístup k produkci, a agenti jsou nasazováni mimo jakýkoli proces změn; vývojář připojí MCP server v úterý a již v pátek manipuluje se zákaznickými daty.

Teze se nezměnila. Rozsah ano. Přístup založený na identitě byl správnou odpovědí pro pracovní zátěže. Pro agenty je to jediná funkční možnost: znát každého existujícího agenta, každému poskytnout výchozí nejmenší agenci a auditovat každou akci. Lidé získali IdP. Agenti také potřebují IdP a to je Hush.

Hush tvrdí, že podnikové AI agenty by měly mít vlastní identity a delegovaná oprávnění místo toho, aby jednoduše dědily přístupová práva lidí, kteří je používají. Proč tradiční systémy Identity and Access Management (IAM) mají problémy s autonomními agenty a co je potřeba změnit?

Zřejmý případ je agent jedná­cí jménem uživatele. Těžší případ je agent bez jakéhokoli uživatele: naplánovaná úloha, autonomní SOC responder, pipeline, která sama uvažuje a jedná. Není nikdo, od koho by se dalo delegovat, takže týmy sáhnou po jediném nástroji, který mají – statickém služebním účtu s širokými oprávněními a klíči, které nikdy nevyprší. Jedná se o stejný model sdíleného tajemství, který se rozpadá již deset let, a nyní je připojen k improvizačnímu softwaru.

Systémy na druhé straně to zhoršují. Většina interních API, databází a MCP serverů neprovádí skutečnou autorizaci. Kontrolují, zda máte platný token, nikoli co s ním můžete dělat. Držení tokenu se rovná oprávnění.

Co je potřeba změnit: každý agent získá vlastní identitu, vydanou kryptograficky, ať už za ním stojí člověk, nebo ne. Přístup je udělován na úrovni jednotlivých akcí, je krátkodobý a omezený, s politikou vynucovanou přímo v řádku místo spolehnutí se na cílový systém. Když existuje uživatel, oprávnění agenta jsou průnikem toho, co uživatel může, a toho, co je agentovi povoleno pro daný úkol. Když uživatel není, identita a politika agenta tvoří celou podstatu. Lidé získali princip nejmenšího oprávnění. Agenti potřebují princip nejmenší agentury.

Používáte pojem „nejmenší agentura“ při diskusi o bezpečnosti AI. Jak se nejmenší agentura liší od tradičního principu kybernetické bezpečnosti nejmenšího oprávnění a jak mohou organizace přesně určit, co by AI agent měl být povolen dělat pro konkrétní úkol?

Agenti nemají pevně dané chování. Pokud jednomu udělíte přístup ke čtení do CRM a zápis do e‑mailu, neposkytujete dvě oprávnění, ale umožňujete všechny cesty mezi nimi. Nejmenší oprávnění omezuje, co může agent dotknout. Neříká nic o tom, co s tím má dělat.

Least agency přidává chybějící rozměr: které akce, pro který úkol, právě teď. Agent třídící tikety potřebuje číst a komentovat. Nemusí uzavírat, mazat ani zasahovat do fakturace, i když token to umožňuje. Až úkol skončí, končí i přístup.

Rozhodování o tom, co je povoleno, začíná pozorováním, ne odhadem. Spusťte agenta, sledujte, co skutečně volá, a nechte to definovat výchozí stav. Pak to zužte pomocí tří vstupů: úkolu, pro který existuje, uživatele, pro kterého jedná (nikdy ne více, než co by on mohl udělat), a dosahu každé akce, protože zveřejnění komentáře a provedení platby by neměly sdílet stejnou schvalovací cestu.

Princip nejmenšího oprávnění určuje, kdo získá klíče. Princip nejmenší agentury rozhoduje, co mohou dělat, jakmile jsou uvnitř.

Často „půjčujeme“ naši identitu našemu agentovi, ale nechceme, aby měl stejnou úroveň oprávnění jako my – to je definice principu nejmenší agentury.

Hush nedávno získal $30 milionů série A, čímž celkové financování vzrostlo na $41 milionů, s Akamai jako strategickým investorem vedle Battery Ventures a YL Ventures. Co přináší zapojení Akamai kromě kapitálu a jak očekáváte, že partnerství ovlivní rozšíření Hush do zabezpečení AI-agentů v podnicích?

Akamai se nachází v cestě provozu většiny světových podniků a právě tam musí bezpečnost agentů existovat. Agent není řízen z dashboardu až po události. Řídíte ho inline, v okamžiku, kdy volá nástroj nebo API. Akamai postavil své podnikání na tomto modelu.

Kromě kapitálu přinášejí tři věci: distribuci k CISO, kteří se již ptají, jak kontrolovat agenty a MCP provoz; potvrzení, že identita agenta je skutečná kategorie, nikoli funkce; a desetiletí zkušeností se zabezpečováním stroj‑stroj komunikace v globálním měřítku, což se stane i pro provoz agent‑tool.

Model Context Protocol (MCP) se rychle stává důležitou vrstvou pro propojení AI agentů s nástroji a podnikovými daty. Z bezpečnostního hlediska jaká nová rizika MCP zavádí a jak by měly organizace uvažovat o identitě a autorizaci mezi agentem, MCP serverem a podkladovým zdrojem?

MCP učinil připojení agenta k nástroji triviálním. To je riziko. Vývojář přidá server do konfiguračního souboru a model nyní může číst Jira, dotazovat databázi nebo posílat e‑mail. Žádná revize, žádný inventář, žádná politika. Bezpečnost to zjistí až když něco selže.

Nyní existují tři nové problémy:

1. Shadow MCP – nikdo neví, kolik serverů běží ani co ovlivňují.
2. Rozptýlení pověření – většina serverů se autentizuje statickým tokenem, který poskytuje celý povrch, takže agent získá vše, co token umožňuje.
3. Zkolabovaný řetězec – zdroj vidí jen pověření MCP serveru, takže nemůže zjistit, který agent jednal jménem kterého uživatele. Identita musí být základem každé interakce, přístup by měl být krátkodobý, omezený a založený na oprávněních agenta a uživatele.

Hush byl původně postaven na myšlence, že statické tajemství a dlouhodobé pověření jsou poškozeným základem pro přístup strojů. Vzhledem k tomu, že většina podnikového infrastruktury stále silně spoléhá na API klíče, tokeny a další tajemství, jak mohou společnosti realisticky přejít k identitě‑založenému, krátkodobému přístupu, aniž by přestavovaly celý technologický stack?

Přestavovat nemusíte. Nikdo, kdo tvrdí opak, se nesetkal s podnikovým prostředím. Většina toho, co chráníme, předchází pojmu ne‑lidská identita, a není to přepisováno.

Proto o to nepožadujeme. Hush se nasazuje bez změn kódu a umisťuje se do cesty přístupu. Prvním krokem je objevování: každé tajemství, kdo ho používá, čeho dosahuje a co ve skutečnosti dělá během běhu. Většina firem takový obrázek nikdy neviděla.

Pak je to cesta, ne migrace. Objevování ukazuje, která tajemství jsou mrtvá, příliš široká nebo nejvyššího rizika. Nejprve je opravte. Pak postupně vyměňte statické klíče za krátkodobé, identitou vydávané pověření, systém po systému. Aplikace si stále myslí, že používá klíč. Klíč už není dlouhodobý a politika přechází na nás.

Stejný model pokrývá patnáct let starou Java službu i MCP server nasazený minulý týden. Začněte tam, kde je riziko, ověřte to a pokračujte.

AI agenti budou čím dál více pracovat jménem lidí a v mnoha případech delegovat úkoly dalším agentům. Jak, když se tyto workflow s více agenty stávají složitějšími, udržet jasný řetězec identity, autorizace, vlastnictví a odpovědnosti za každou provedenou akci?

Mód selhání: uživatel požádá orchestrátor, ten deleguje druhému agentovi, který volá nástroj přes MCP server, který zasáhne databázi pomocí servisního účtu. Čtyři skoky později log ukazuje jen jeden prvek, platný token. Kdo požádal, kdo rozhodl a kdo je zodpovědný, už není znám.

Řešení spočívá v tom, že se neumožní, aby se identita na jakémkoli skoku zhroutila. Každý agent má vlastní kryptografickou identitu. Když deleguje, nepředává svůj token. Vydává omezenou delegaci: tento podagent, tento úkol, tyto akce, jménem tohoto uživatele. Každý skok nese celý řetězec i své vlastní oprávnění.

Zodpovědnost vyplývá z vynucování a zaznamenávání inline, v místě akce. Záznam brány o tom, co bylo povoleno provést, co volala, a řetězec za tím.

Systémy s více agenty budou obtížnější na pochopení. Řetězec odpovědnosti pro každou akci nemusí.

Prompt injection a další útoky mohou potenciálně manipulovat jinak legitimního AI agenta k provádění akcí, které jeho operátor nikdy neplánoval. Do jaké míry mohou kontroly přístupu založené na identitě omezit škody způsobené kompromitovaným nebo manipulovaným agentem, i když se základní model AI chová nesprávně?

Prompt injection na modelu nezastavíte. Modely jsou navrženy tak, aby četly nedůvěryhodný obsah. Předpokládejte, že agent bude nakonec přemluven k něčemu špatnému. Otázkou je, co může udělat, když k tomu dojde.

Přístup založený na identitě omezuje dosah poškození. Manipulovaný agent s minimální pravomocí může zneužít jen akce, které mu byly přiděleny pro daný úkol. Pokud může číst tikety a přidávat komentáře, žádná injekce ho nenutí vycizit databázi zákazníka. Token nemá takový dosah.

Atributace uživatele udržuje řetězec nedotčený: který uživatel, který agent, který úkol, při každém volání. Agent nikdy nepřekročí, co může uživatel, a každá akce se dá zpětně vysledovat.

Detekce anomálií zachytí, co politika povoluje, ale úmysl ne. Agent, který normálně čte pět záznamů a najednou stáhne pět tisíc, je mimo charakter, i když je každé volání autorizováno. Protože brána funguje inline a zná základní úroveň, může to v reálném čase označit nebo zablokovat.

Model bude občas chybovat. Omezená identita, atribuce a behaviorální základny umožňují přežít chyby.

Hush se primárně zaměřuje na zabezpečení AI, ale jak používáte AI uvnitř samotného Hush? Existují oblasti, jako je objevování ne‑lidských identit, analýza přístupových vzorců, upřednostňování rizik nebo vynucování politik, kde může AI podstatně zlepšit bezpečnostní platformu?

Používáme ji všude, kde si zaslouží své místo.

V produktu není těžké najít tajemství, ale pochopit je. Klíč se objeví v provozu. Identita pracovního zatížení, integrace dodavatele, vývojový testovací token, mrtvá přihlašovací údaje? LLM čte kontext běhu a signály vlastníka a navrhuje odpověď s ukazatelem důvěry. Shrnuje, co identita ve skutečnosti dělá v běžném lidském jazyce, takže politika je taková, kterou člověk schválí. Hodnotí riziko podle skutečného dosahu a rozsahu poškození, nikoli podle statické závažnosti. Vynucování zůstává deterministické. AI pomáhá psát politiku – nedostane hlas při běhu.

Uvnitř Hush změnilo agentické programování náš časový rámec. Funkce, které dříve trvaly sprint, nyní trvají dny, a integrace vydáváme tempem, které by tým Series A jinak nemohl dovolit. LLM třídí podpůrné tikety, seskupují příčiny a zviditelňují požadavky zákazníků pro diskuze o roadmapě. Naše vlastní MCP brána stojí před vším tím, pomáhá našim zákazníkům uvažovat a využívat NHI a agentické riziko.

Hush uvádí, že více společností z Fortune 500 nyní používá její technologii, zatímco Kyndryl nasadila Hush interně a začala ji prodávat podnikovým klientům. Co se učíte z těchto rozsáhlých nasazení o reálných problémech správy, se kterými firmy čelí, jakmile AI agenti přecházejí z experimentování do produkce?

Nikdo neví, co má. Každé velké nasazení začíná stejně: bezpečnost myslí, že v produkci běží tucet agentů, objevování najde stovky, které už přistupují k zákaznickým datům. Problém správy není politika, ale nejprve inventarizace.

Přihlašovací údaje jsou horší než agenti. Téměř každý produkční agent běží na statickém servisním účtu, který existoval dříve, s oprávněními nahromaděnými během let pro jiný účel. Neměl omezený přístup.

Chybí vlastnictví. Když se zeptáte, kdo je zodpovědný za agenta nebo NHI, dostanete nejvýše název týmu, odešel kontraktor nebo ticho.

A kupující se změnil. Šlo o problém platformového týmu. Nyní to vlastní CISO, protože to požaduje představenstvo. To nás posunulo z pilotních projektů na podnikovou implementaci a je důvodem, proč Kyndryl nasadil interně před dalším prodejem.

Agenti nevytvořili nové problémy správy. Vzali ty, které podniky ignorovaly deset let s servisními účty, a zhoršili je.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit Hush Security.