Micha Rave, CEO und Mitbegründer von Hush Security – Interviewreihe

Micha Rave, CEO und Mitbegründer von Hush Security, ist ein erfahrener Führungskraft im Bereich Cybersicherheit und Technologie, dessen Karriere Softwareentwicklung, Produktmanagement, Unternehmensnetzwerke, Cloud‑Sicherheit und Identität umfasst. Vor der Mitbegründung von Hush Security im Jahr 2024 verbrachte er mehr als fünf Jahre bei Proofpoint als Senior Director of Product Management für Cloud Security, wo er für die Produktlinien Zero Trust Network Access (ZTNA) und Secure Web Gateway (SWG) verantwortlich war. Zuvor war er VP of Product Management bei Meta Networks, mit Fokus auf Unternehmensnetzwerke und Sicherheit, und hatte Führungspositionen im Produkt‑ und Ingenieurwesen bei HARMAN International, Redbend, SanDisk, Hola, Jungo und Elbit Systems. Sein Hintergrund verbindet praktische Softwareentwicklung mit über zwei Jahrzehnten Erfahrung im Aufbau und der Kommerzialisierung von Sicherheits‑, Netzwerk‑, Virtualisierungs‑ und Embedded‑Technologieprodukten.

Hush Security ist ein Cybersicherheitsunternehmen, das sich darauf konzentriert, KI‑Agenten und andere nicht‑menschliche Identitäten zu sichern, indem langlebige Anmeldeinformationen und statische Geheimnisse durch identitätsbasierte, richtliniengesteuerte Zugriffe ersetzt werden. Seine Plattform entdeckt KI‑Agenten, einschließlich Schatten‑ und intern entwickelter Agenten, weist ihnen verifizierbare Identitäten zu und steuert ihre Interaktionen mit Unternehmenssystemen mittels scoped, just‑in‑time Berechtigungen, zentralisierten Richtlinien und prüfbaren Aktivitätsprotokollen. Das Unternehmen wurde von Sicherheitsexperten des Teams hinter Meta Networks gegründet, das 2019 von Proofpoint übernommen wurde. Im Juli 2026 sammelte Hush eine Series A‑Finanzierung in Höhe von $30 million, wobei Akamai Technologies als strategischer Investor neben Battery Ventures und YL Ventures einstieg, wodurch die Gesamtfinanzierung auf $41 million anstieg, während das Unternehmen seine Technologie zur Steuerung von Unternehmens‑KI‑Agenten und nicht‑menschlicher Infrastruktur ausbaut.

Bevor Sie Hush Security gegründet haben, haben Sie Jahre damit verbracht, Sicherheitsprodukte zu entwickeln und zu leiten, einschließlich Cloud‑Security bei Proofpoint. Was haben Sie auf dem Markt gesehen, das Sie davon überzeugt hat, dass ein Unternehmen wie Hush notwendig ist, und wie hat sich diese ursprüngliche These mit dem raschen Aufstieg der agentischen KI entwickelt?

Bei Proofpoint beobachteten wir, wie Unternehmen die menschliche Identität lösten, während alles Nicht‑Menschliche weiterhin mit statischen Geheimnissen arbeitete. Service‑Accounts, Workloads, Pipelines, alle authentifizierten sich mit Schlüsseln, die niemand besaß und die nie abliefen. Die Branche reagierte mit besseren Tresoren. Das ist ein besserer Safe, aber keine Lösung.

Die Gründungsthese war, den nicht‑menschlichen Zugriff von Geheimnissen auf Identität zu verlagern. Verifizierbare Workload‑Identität, kurzlebige Anmeldeinformationen, just‑in‑time ausgestellt, Richtlinien inline durchgesetzt. Keine Code‑Umstellungen.

Agentische KI machte das dringend nötig. Ein Agent ist ein NHI, das zur Laufzeit überlegt und entscheidet, welche Werkzeuge es aufrufen soll. Gibt man ihm einen statischen Schlüssel, hat man autonomer Software dauerhaften Zugriff auf die Produktion gewährt, und Agenten werden außerhalb jedes Änderungsprozesses ausgeliefert; ein Entwickler verbindet am Dienstag einen MCP‑Server und am Freitag greift er bereits auf Kundendaten zu.

Die These hat sich nicht geändert. Der Umfang jedoch schon. Identitätsbasierter Zugriff war die richtige Lösung für Workloads. Für Agenten ist er die einzige praktikable: Kennen Sie jeden existierenden Agenten, geben Sie jedem standardmäßig die geringste Handlungsbefugnis und protokollieren Sie jede Aktion. Menschen erhalten einen IdP. Agenten benötigen ebenfalls einen, und das ist Hush.

Hush argumentiert, dass Unternehmens‑KI‑Agenten eigene Identitäten und delegierte Berechtigungen besitzen sollten, anstatt lediglich die Zugriffsrechte der von ihnen genutzten Menschen zu erben. Warum haben traditionelle Identity‑and‑Access‑Management‑Systeme (IAM) Schwierigkeiten mit autonomen Agenten, und was muss sich ändern?

Der offensichtliche Fall ist ein Agent, der für einen Benutzer agiert. Der schwierigere Fall ist ein Agent ohne jeglichen Benutzer: ein geplanter Job, ein autonomer SOC‑Responder, eine Pipeline, die eigenständig überlegt und handelt. Es gibt niemanden, von dem delegiert werden kann, sodass Teams auf das einzige verfügbare Werkzeug zurückgreifen – ein statisches Service‑Account mit breiten Berechtigungen und einem Schlüssel, der nie abläuft. Das ist dasselbe Shared‑Secret‑Modell, das seit einem Jahrzehnt scheitert und nun an improvisierende Software angehängt ist.

Die Systeme auf der anderen Seite verschlimmern das Problem. Die meisten internen APIs, Datenbanken und MCP‑Server führen keine echte Autorisierung durch. Sie prüfen lediglich, ob Sie ein gültiges Token besitzen, nicht, was Sie damit tun dürfen. Besitz bedeutet Berechtigung.

Was sich ändern muss: Jeder Agent erhält seine eigene, kryptografisch ausgestellte Identität, unabhängig davon, ob ein Mensch dahintersteht. Zugriff wird pro Aktion, kurzlebig und scoped, mit inline durchgesetzten Richtlinien gewährt, anstatt dem Zielsystem zu vertrauen. Gibt es einen Benutzer, bilden die Berechtigungen des Agenten die Schnittmenge dessen, was der Benutzer darf, und dessen, was der Agent für diese Aufgabe ausführen darf. Gibt es keinen Benutzer, bestimmen die eigene Identität und Richtlinie des Agenten die gesamte Berechtigung. Menschen erhielten das Prinzip der geringsten Privilegien. Agenten benötigen das Prinzip der geringsten Handlungsbefugnis.

Sie verwenden das Konzept der „geringsten Handlungsbefugnis“ (least agency) bei der Diskussion über KI‑Sicherheit. Wie unterscheidet sich die geringste Handlungsbefugnis vom traditionellen Cybersicherheitsprinzip der geringsten Privilegien, und wie können Organisationen genau bestimmen, welche Aufgaben einem KI‑Agenten für eine bestimmte Aufgabe erlaubt sein sollten?

Agenten haben kein festes Verhalten. Gewährt man einem Agenten Lesezugriff auf ein CRM und Schreibzugriff auf E‑Mail, hat man nicht zwei Berechtigungen vergeben, sondern jeden möglichen Pfad dazwischen. Die geringste Privilegierung begrenzt, was ein Agent berühren kann. Sie sagt nichts darüber aus, was er damit tun soll.

Least agency fügt die fehlende Dimension hinzu: welche Aktionen, für welche Aufgabe, gerade jetzt. Ein Agent, der Tickets triagiert, muss lesen und kommentieren können. Er muss nicht schließen, löschen oder die Abrechnung berühren, selbst wenn das Token dies erlaubt. Wenn die Aufgabe endet, endet auch der Zugriff.

Die Entscheidung, was erlaubt ist, beginnt mit Beobachtung, nicht mit Vermutungen. Führen Sie den Agenten aus, beobachten Sie, welche Aufrufe er tatsächlich tätigt, und lassen Sie das den Ausgangspunkt definieren. Dann verengen Sie es anhand von drei Eingaben: der Aufgabe, für die er existiert, dem Nutzer, für den er handelt (niemals mehr, als dieser selbst tun könnte), und dem Wirkungsradius jeder Aktion, weil das Verfassen eines Kommentars und das Durchführen einer Zahlung nicht denselben Genehmigungsweg teilen sollten.

Least privilege bestimmt, wer die Schlüssel erhält. Least agency entscheidet, was sie tun können, sobald sie drin sind.

Wir „verleihen“ unserem Agenten oft unsere Identität, aber wir wollen nicht, dass der Agent das gleiche Berechtigungsniveau hat wie wir – das ist die Definition von Least agency.

Hush hat kürzlich eine $30 Millionen Series A-Finanzierungsrunde abgeschlossen, wodurch die Gesamtfinanzierung auf $41 Millionen steigt, wobei Akamai als strategischer Investor zusammen mit Battery Ventures und YL Ventures einsteigt. Was bringt das Engagement von Akamai über das Kapital hinaus, und wie erwarten Sie, dass die Partnerschaft die Expansion von Hush in die Unternehmens‑AI‑Agent‑Sicherheit beeinflusst?

Akamai befindet sich im Datenverkehrspfad der meisten Unternehmen weltweit, und genau dort muss die Agentensicherheit existieren. Man steuert einen Agenten nicht nachträglich über ein Dashboard. Man steuert ihn inline, in dem Moment, in dem er ein Tool oder eine API aufruft. Akamai hat sein Geschäft auf diesem Modell aufgebaut.

Über das Kapital hinaus bringen sie drei Dinge mit: Distribution zu CISOs, die bereits fragen, wie man Agenten und MCP‑Traffic kontrolliert; die Bestätigung, dass Agenten‑Identität eine echte Kategorie und kein Feature ist; und jahrzehntelange Erfahrung in der Sicherung von Machine‑to‑Machine‑Traffic in globalem Maßstab, was der Agent‑zu‑Tool‑Traffic bald werden wird.

Model Context Protocol (MCP) entwickelt sich schnell zu einer wichtigen Schicht für die Verbindung von KI‑Agenten mit Tools und Unternehmensdaten. Aus sicherheitstechnischer Sicht, welche neuen Risiken führt MCP ein, und wie sollten Organisationen über Identität und Autorisierung zwischen dem Agenten, dem MCP‑Server und der zugrunde liegenden Ressource nachdenken?

MCP hat das Verbinden eines Agenten mit einem Tool trivial gemacht. Das ist das Risiko. Ein Entwickler fügt einem Konfigurationsfile einen Server hinzu und das Modell kann nun Jira lesen, eine Datenbank abfragen oder E‑Mails senden. Keine Prüfung, keine Inventarisierung, keine Richtlinie. Die Sicherheit erfährt es erst, wenn etwas kaputt geht.

Es gibt jetzt drei neue Probleme:

1. Shadow MCP – niemand weiß, wie viele Server laufen oder was sie berühren.
2. Credential Sprawl – die meisten Server authentifizieren sich mit einem statischen Token, das die gesamte Oberfläche freigibt, sodass der Agent alles erhält, was das Token tun kann.
3. Die zusammengefallene Kette – die Ressource sieht nur das Credential des MCP‑Servers, sodass sie nicht erkennen kann, welcher Agent für welchen Nutzer den Aufruf getätigt hat. Identität muss die Basis jeder Interaktion sein, der Zugriff sollte flüchtig, scoped und basierend auf den Berechtigungen von Agent und Nutzer sein.

Hush wurde ursprünglich um die Idee herum entwickelt, dass statische Geheimnisse und langlebige Credentials eine fehlerhafte Grundlage für den Maschinenzugriff darstellen. Da die meisten Unternehmens‑Infrastrukturen nach wie vor stark auf API‑Schlüssel, Tokens und andere Geheimnisse setzen, wie können Unternehmen realistisch zu identitätsbasiertem, kurzlebigem Zugriff übergehen, ohne ihren gesamten Technologiestack neu aufzubauen?

Man baut nicht neu. Niemand, der das Gegenteil behauptet, hat ein Unternehmen kennengelernt. Das meiste, was wir schützen, stammt aus der Zeit vor dem Begriff nicht‑menschliche Identität, und es wird nicht neu geschrieben.

Deshalb verlangen wir es nicht. Hush wird ohne Code‑Änderungen bereitgestellt und sitzt im Zugriffspfad. Schritt eins ist die Entdeckung: jedes Geheimnis, wer es nutzt, worauf es zugreift und was es zur Laufzeit tatsächlich tut. Die meisten Unternehmen haben dieses Bild noch nie gesehen.

Dann ist es eine Reise, keine Migration. Die Entdeckung zeigt, welche Geheimnisse veraltet, überberechtigt oder am risikoreichsten sind. Diese zuerst beheben. Dann tauschen Sie statische Schlüssel nach und nach gegen kurzlebige, von der Identität ausgestellte Credentials aus, System für System. Die Anwendung glaubt weiterhin, einen Schlüssel zu verwenden. Der Schlüssel ist nur nicht mehr langlebig, und die Richtlinie wird an uns übergeben.

Dasselbe Modell deckt einen fünfzehn Jahre alten Java‑Service und einen MCP‑Server ab, der erst letzte Woche eingerichtet wurde. Beginnen Sie dort, wo das Risiko liegt, beweisen Sie es, und machen Sie weiter.

KI‑Agenten werden zunehmend im Auftrag von Menschen arbeiten und in vielen Fällen Aufgaben an andere Agenten delegieren. Wenn diese Multi‑Agent‑Workflows komplexer werden, wie behalten Sie eine klare Kette von Identität, Autorisierung, Eigentum und Verantwortlichkeit für jede durchgeführte Aktion bei?

Der Fehlermodus: Ein Nutzer fragt einen Orchestrator, dieser delegiert an einen zweiten Agenten, der über einen MCP‑Server ein Tool aufruft, das wiederum mit einem Service‑Account auf eine Datenbank zugreift. Vier Hops später zeigt das Log nur ein gültiges Token. Wer gefragt hat, wer entschieden hat und wer verantwortlich ist, ist verschwunden.

Die Lösung besteht darin, zu verhindern, dass die Identität an irgendeinem Hop zusammenbricht. Jeder Agent hat seine eigene kryptografische Identität. Wenn er delegiert, gibt er sein Token nicht weiter. Er erstellt eine scoped Delegation: dieser Sub‑Agent, diese Aufgabe, diese Aktionen, im Auftrag dieses Nutzers. Jeder Hop trägt die vollständige Kette und seine eigenen Berechtigungen.

Verantwortlichkeit entsteht durch Durchsetzung und Protokollierung inline, am Ort der Aktion. Das Gateway protokolliert, was es durfte zu tun, was es aufgerufen hat und die dahinterliegende Kette.

Multi‑Agent‑Systeme werden schwerer zu durchschauen sein. Die Beweiskette für jede Aktion muss es nicht sein.

Prompt‑Injection und andere Angriffe können potenziell einen ansonsten legitimen KI‑Agenten dazu bringen, Handlungen auszuführen, die sein Betreiber nie beabsichtigt hat. Inwieweit können identitätsbasierte Zugriffskontrollen den Schaden durch einen kompromittierten oder manipulierten Agenten begrenzen, selbst wenn das zugrunde liegende KI‑Modell fehlerhaft reagiert?

Prompt‑Injection lässt sich nicht am Modell verhindern. Modelle lesen per Design unzuverlässige Inhalte. Man muss davon ausgehen, dass der Agent irgendwann zu etwas Falschem überredet wird. Die Frage ist, was er dann tun kann.

Identitätsbasierter Zugriff begrenzt den Wirkungsradius. Ein manipulierter Agent mit minimaler Befugnis kann nur die ihm für diese Aufgabe zugewiesenen Aktionen missbrauchen. Wenn er Tickets lesen und Kommentare posten kann, führt keine Injection dazu, dass er die Kundendatenbank exfiltriert. Das Token hat nicht die Reichweite.

Benutzerzuordnung hält die Kette intakt: welcher Benutzer, welcher Agent, welche Aufgabe, bei jedem Aufruf. Der Agent überschreitet nie das, was der Benutzer tun könnte, und jede Aktion lässt sich zurückverfolgen.

Anomalieerkennung erkennt, was die Richtlinie erlaubt, aber nicht beabsichtigt war. Ein Agent, der normalerweise fünf Datensätze liest und plötzlich fünftausend abruft, ist untypisch, selbst wenn jeder Aufruf autorisiert ist. Da das Gateway inline sitzt und die Basislinie kennt, kann es das in Echtzeit kennzeichnen oder blockieren.

Das Modell wird gelegentlich falsch liegen. Eingeschränkte Identität, Attribution und Verhaltensbaselines machen Fehler überlebbar.

Hush konzentriert sich hauptsächlich darauf, KI zu sichern, aber wie setzen Sie KI innerhalb von Hush selbst ein? Gibt es Bereiche wie das Aufspüren nicht‑menschlicher Identitäten, die Analyse von Zugriffsmustern, die Priorisierung von Risiken oder die Durchsetzung von Richtlinien, in denen KI die Sicherheitsplattform wesentlich verbessern kann?

Wir setzen sie dort ein, wo sie ihren Platz verdient.

Im Produkt besteht die Schwierigkeit nicht darin, Geheimnisse zu finden, sondern sie zu verstehen. Ein Schlüssel erscheint im Datenverkehr. Workload‑Identität, Anbieter‑Integration, Entwicklungs‑Test‑Token, tote Anmeldeinformation? Ein LLM liest den Laufzeitkontext und die Signale des Eigentümers und schlägt eine Antwort mit einem Vertrauens‑Score vor. Es fasst zusammen, was eine Identität tatsächlich tut, in klarer menschlicher Sprache, sodass die Richtlinie von einem Menschen genehmigt wird. Es bewertet das Risiko nach tatsächlicher Reichweite und Wirkungsradius, nicht nach statischer Schwere. Die Durchsetzung bleibt deterministisch. KI hilft beim Schreiben der Richtlinie – sie erhält zur Laufzeit keine Stimme.

Bei Hush hat agentische Programmierung unsere Zeitskala verändert. Funktionen, die früher einen Sprint dauerten, benötigen jetzt Tage, und wir liefern Integrationen in einem Tempo, das ein Series‑A‑Team sich sonst nicht leisten könnte. LLMs triagieren Support‑Tickets, clustern Ursachen und bringen Kundenanfragen für Roadmap‑Diskussionen ans Licht. Unser eigenes MCP‑Gateway steht vor allem und unterstützt unsere Kunden beim Verstehen und Nutzen von NHI und agentischem Risiko.

Hush sagt, dass mehrere Fortune‑500‑Unternehmen seine Technologie jetzt einsetzen, während Kyndryl Hush intern ausgerollt und begonnen hat, es an Unternehmenskunden weiterzuverkaufen. Welche Erkenntnisse gewinnen Sie aus diesen groß angelegten Einsätzen über die realen Governance‑Probleme, denen Unternehmen begegnen, sobald KI‑Agenten von der Experimentierphase in die Produktion übergehen?

Niemand weiß, was er hat. Jede große Einführung beginnt gleich: Die Sicherheit geht davon aus, dass etwa ein Dutzend Agenten in Produktion sind, die Entdeckung findet Hunderte, die bereits Kundendaten berühren. Das Governance‑Problem ist nicht die Richtlinie, sondern zuerst das Inventar.

Die Anmeldeinformationen sind schlechter als die Agenten. Fast jeder Produktions‑Agent läuft auf einem statischen Service‑Konto, das vor ihm existierte, mit über Jahre hinweg angesammelten Berechtigungen für andere Zwecke. Es erhielt keinen eingeschränkten Zugriff.

Zuständigkeit fehlt. Fragt man, wer für einen Agenten oder ein NHI verantwortlich ist, erhält man höchstens einen Teamnamen, einen ausgeschiedenen Auftragnehmer oder keine Antwort.

Und der Käufer hat sich geändert. Das war ein Problem des Plattform‑Teams. Jetzt besitzt es der CISO, weil der Vorstand danach fragt. Das hat uns von Pilotprojekten zu Unternehmens‑Rollouts geführt, und deshalb hat Kyndryl es intern ausgerollt, bevor es weiterverkauft wurde.

Agenten haben keine neuen Governance‑Probleme geschaffen. Sie haben die Probleme übernommen, die Unternehmen ein Jahrzehnt lang mit Service‑Konten ignorierten, und sie deutlich verschärft.

Danke für das großartige Interview, Leser, die mehr erfahren möchten, sollten Hush Security besuchen.