Refael Angel, Co-Founder und CTO von Akeyless – Interview-Serie

Refael Angel, Co-Founder und CTO von Akeyless, ist ein Experte für Cybersicherheit und Software-Engineering mit umfassender Erfahrung in Cloud-Sicherheit, Verschlüsselung, Maschinen-Authentifizierung und Unternehmens-Infrastruktur. Seit der Gründung von Akeyless im Jahr 2018 hat er dazu beigetragen, das Unternehmen um moderne Secrets-Management- und Identitäts-Sicherheitslösungen für cloud-native Umgebungen aufzubauen. Vor Akeyless arbeitete er als Senior Software Engineer in der Abteilung Sicherheit bei Intuit (INTU ), wo er Systeme für die Verwaltung von Verschlüsselungsschlüsseln in der öffentlichen Cloud und die Authentifizierung von Maschinen entwickelte und dabei praktische Erfahrungen in den Bereichen AWS, Go, Python, Java, PHP, Bash, Linux, Git und Jenkins sammelte. Zu Beginn seiner Karriere hatte Angel Software-Entwicklungsrollen bei 3D Systems (DDD ) und Cimatron inne, wo er CAD/CAM- und Windows-basierte Anwendungen mithilfe von C/C++, C#, WPF, MFC und objektorientierten Entwurfsmustern entwickelte.

Akeyless ist ein Unternehmen für Identitäts-Sicherheit, das sich auf die Sicherung von Maschinen, KI-Agents und Menschen durch eine cloud-native Plattform konzentriert, die auf Zero-Knowledge-Kryptographie basiert. Die Plattform kombiniert Secrets-Management, Verschlüsselungsschlüssel-Verwaltung, Zertifikats-Lebenszyklus-Verwaltung, privilegierten Zugriff und Maschinen-Identitäts-Sicherheit, um Organisationen eine einheitliche Möglichkeit zu bieten, Anmeldeinformationen, Schlüssel, Zertifikate und Zugriff auf hybride, multi-cloud-, DevOps- und KI-Umgebungen zu verwalten. Die Positionierung des Unternehmens spiegelt eine breitere Verschiebung in der Cybersicherheit wider: Da Workloads, Dienste und KI-Agents immer häufiger Systemzugriffe ohne direkte menschliche Beteiligung durchführen, benötigen Unternehmen stärkere Kontrollen für nicht-menschliche Identitäten, kurzlebige Anmeldeinformationen, automatisierte Rotation und Laufzeit-Regierung.

Sie haben Akeyless 2018 gegründet, nachdem Sie Verschlüsselungsschlüssel-Verwaltungs- und Maschinen-Authentifizierungssysteme bei Intuit entwickelt hatten. Welche Lücke in der Cloud-Sicherheit und Identitäts-Verwaltung überzeugte Sie davon, dass es Zeit war, Akeyless zu gründen, und wie hat sich diese ursprüngliche Vision im Laufe der Zeit entwickelt, als KI-Agents als neue Klasse digitaler Identitäten auftraten?

Bei Intuit war ich Teil des Teams, das Verschlüsselungsschlüssel-Verwaltungs- und Maschinen-Authentifizierungssysteme baute, als Intuit eines der ersten großen Unternehmen war, das in die Cloud zog. Was mir klar wurde, war, dass jedes Unternehmen, das in die Cloud wechselte, schließlich das gleiche Problem lösen musste, das wir intern lösten: Wie man Geheimnisse und Schlüssel in verteilten, dynamischen Infrastrukturen verwaltet. Dies aufzubauen, verbraucht enorme Entwicklungsressourcen, und es macht keinen Sinn, dass jedes Unternehmen dies neu erfindet. Die logische Antwort war ein SaaS-Modell.

Der Haken war Vertrauen. Dies ist das sensibelste Material, das ein Unternehmen besitzt, und kein ernstes Unternehmen wird einem Dritten die Möglichkeit geben, darauf zuzugreifen. Die Anforderung war fast widersprüchlich: Es sollte als SaaS für Skalierbarkeit und Einfachheit geliefert werden, aber es sollte architektonisch unmöglich sein, dass der Anbieter die Kunden-Daten jemals sieht. Diese Spannung ist genau das, was zur Geburt der Distributed Fragments Cryptography (DFC) führte. DFC ermöglicht es uns, eine vollständig verwaltete SaaS-Steuerungsebene zu betreiben, während der Kunde einen Fragmenten besitzt, den wir nie besitzen, sodass wir mathematisch nicht in der Lage sind, auf seine Schlüssel zuzugreifen. Das wurde zur Grundlage des SaaS-Plus-Zero-Knowledge-Modells, auf dem Akeyless aufbaut.

Die ursprüngliche Vision war es, menschlichen und maschinellen Zugriff in der Cloud zu sichern. KI-Agents sind die natürliche und extremste Erweiterung desselben Problems. Sie sind nicht-menschliche Identitäten, die auf einer Skala und mit einer Geschwindigkeit operieren, für die kein Verzeichnis konzipiert wurde, und die gleiche Zero-Knowledge- und identitätszentrierte Grundlage erstreckt sich nun direkt auf sie.

Sie werden als Architekt hinter Akeyless’ patentierter Zero-Trust-Verschlüsselungstechnologie genannt. Welche waren die größten technischen Herausforderungen beim Aufbau eines Sicherheitsmodells, das Vertrauensannahmen eliminieren konnte, während es gleichzeitig für große Unternehmen praktikabel blieb?

Der härteste Teil war es, “Vertraue niemandem” praktisch und nicht nur akademisch umzusetzen. Die meisten Split-Key- oder Secret-Sharing-Schemata setzen den vollständigen Schlüssel noch immer bei einer bestimmten Gelegenheit zusammen, normalerweise innerhalb eines einzelnen Prozesses, HSM oder Enklave zum Zeitpunkt einer kryptographischen Operation. Dieses kurze Zeitfenster ist genau das, was Angreifer, böswillige Insider und Rechtszwangsszenarien ins Visier nehmen.

Bei DFC wird der Schlüssel nie zusammengefügt, nicht bei der Erstellung, nicht in Ruhe und nicht während der Verwendung. Fragmenten werden unabhängig in separaten Vertrauensbereichen generiert, und kryptographische Operationen werden als verteilte Berechnung durchgeführt, bei der jeder Fragment-Halter seinen Anteil lokal berechnet und nur partielle Ergebnisse ausgetauscht werden. Die ingenieurstechnische Herausforderung bestand darin, dies mit der Latenz, Durchsatz und Zuverlässigkeit zu erreichen, die große Unternehmen in der Produktion verlangen.

Eine zweite Herausforderung, und eine der bedeutendsten, war die ermöglichen der kontinuierlichen Ablösung der Fragmenten. Wir mussten in der Lage sein, jeden Fragmenten durch einen neuen mathematischen Wert zu ersetzen, an jedem Ort, während der zugrunde liegende Master-Schlüssel, den die Fragmenten repräsentieren, unverändert blieb und der kryptographische Prozess nie unterbrochen wurde. Dies fügte eine sehr substantielle Sicherheitsschicht zur Lösung hinzu. Da ein Angreifer nicht länger Fragmenten über einen längeren Zeitraum sammeln kann, ist ein Fragment, das letzte Woche erfasst wurde, mathematisch nicht mehr mit den Fragmenten verbunden, die heute existieren, sodass es sich um Rauschen und nicht um einen Vorsprung handelt. Um etwas über einen Schlüssel zu erfahren, müsste ein Angreifer jeden Fragmenten-Ort gleichzeitig innerhalb eines einzigen Ablösungszeitfensters kompromittieren, und diese Anforderung wird exponentiell schwieriger, je mehr Orte, Vertrauensbereiche und Ablösungshäufigkeiten vorhanden sind. Kombiniert mit der all-oder-nichts-Schwelle, bei der 100 Prozent der Fragmenten benötigt werden, um etwas zu enthüllen, und jede strikte Teilmenge keine Informationen preisgibt, wandelt die Ablösung das Sicherheitsmodell von einer statischen Garantie in eine zeitgebundene um.

Viele Unternehmen sind bemüht, KI-Agents zu deployen, doch Identitäts-Sicherheit bleibt oft ein Nachgedanke. Welche sind die häufigsten Fehler, die Unternehmen machen, wenn sie KI-Agents Zugriff auf Unternehmens-Systeme und sensible Daten gewähren?

Der größte Fehler ist es, einem Agenten eine statische, langfristige API-Schlüssel zu übergeben. Diese Anmeldeinformationen werden zu einem permanenten, erntbaren Vermögen, das in einem nicht-deterministischen, prompt-injektierbaren Akteur sitzt.

Die anderen häufigen Fehler, die ich sehe, sind: Standing-Berechtigungen anstelle von just-in-time-Zugriff gewähren, auf grobe rollenbasierte Berechtigungen vertrauen, die beschreiben, was ein Agent erreichen kann, aber nie, was er vorhat zu tun, Agents direkte Netzwerkpfade zu Datenbanken und APIs geben, sodass ein Kompromiss zu lateralem Zugriff wird, und keine Prüfkette haben, die eine Agenten-Aktion mit dem menschlichen Prompt und der auslösenden Aktion verbindet. Jeder dieser Fehler ist ein Versuch, menschliche Kontrollen auf etwas zu übertragen, das nicht wie ein Mensch handelt.

Akeyless hat argumentiert, dass KI-Agents ein grundlegend anderes Identitätsmodell benötigen als Menschen oder traditionelle Maschinen-Workloads. Was macht KI-Agents so besonders schwierig zu sichern im Vergleich zu bestehenden IAM- und PAM-Rahmenwerken?

Der Kernfehler ist es, KI-Agents als eine neue Art von Benutzer oder sogar als eine neue Art von Dienstkonto zu behandeln und anzunehmen, sie könnten wie menschliche Identitäten aufgenommen und regiert werden. Das ist ein Kategorienfehler, aus mehreren miteinander verbundenen Gründen.

Agenten-Identitäten sind nicht auflistbar. Die spezifische Instanz, die Sie regieren möchten, existiert normalerweise noch nicht, und bis sie existiert, ist sie bereits verschwunden. Ein Agent kann auf einem Lambda aufspringen, 800 Millisekunden lang laufen und verschwinden, bevor ein Scanner es bemerkt, oder Ketten von Sub-Agents über VMs, Container und Serverless-Instanzen spawnen, die in Sekunden abgeschlossen sind. Diese in einem Verzeichnis zu registrieren, bedeutet, Gespenster als Bewohner zu behandeln: Bis die Eintragung committet wird, ist die Entität, die sie beschreibt, bereits verschwunden.

Der richtige Anker ist daher nicht der Agent, sondern die Workload-Identität, die seine Laufzeit bereits ausgibt, die AWS-Ausführungsrolle, das Kubernetes-Dienstkonto-Token, das SPIFFE-SVID. Diese Identität existiert bereits, wird von der Plattform, auf der der Agent läuft, beglaubigt und verschwindet, wenn der Agent verschwindet. Da die Identitäten ephemeren sind, sind die einzigen stabilen Entitäten, zwischen denen man Richtlinien schreiben kann, die Authentifizierungsmethoden und die Ziel-Systeme, nicht die benannten Identitäten und Bereiche.

Und hier brechen bestehende IAM- und PAM-Rahmenwerke am meisten zusammen: Statische RBAC und ABAC können einen nicht-deterministischen Akteur nicht enthalten. Ein Agent mit einem perfekt abgegrenzten Token und einer perfekt durchgesetzten TTL kann immer noch prompt-injiziert werden, eine destruktive Abfrage halluzinieren oder in der gleichen Sitzung von einer Lese-Aufgabe zu einer Schreibaufgabe wechseln, ohne dass eine Richtlinien-Verletzung auf der Autorisierungsebene sichtbar wird. RBAC und ABAC bewerten bei der Authentifizierung, nicht danach, weil das, was danach passiert, von einem LLM bestimmt wird, der auf ein Kontextfenster schaut, das der Richtlinien-Autor nicht sehen kann.

So sind Agents besonders schwierig zu sichern, weil sie ephemeren, nicht-deterministischen, multi-substratischen und prompt-injektierbaren sind. Die fehlende Schicht ist nicht ein besseres Verzeichnis. Es ist eine vorsatzbewusste Durchsetzung auf jeder Aktion, vermittelt durch ein Gateway, das prüft, was der Agent tatsächlich tut, im Vergleich zu dem, was er sagte, er würde tun, bevor irgendeine Anmeldeinformation ausgegeben wird. Intent-aware policy enforcement auf jeder Aktion, vermittelt durch ein Gateway, das prüft, was der Agent tatsächlich tut, im Vergleich zu dem, was er sagte, er würde tun, bevor irgendeine Anmeldeinformation ausgegeben wird.

Es gibt eine wachsende Diskussion über “secretless”-Architekturen für KI-Systeme. Wie definieren Sie secretless-Authentifizierung, und warum glauben Sie, dass statische Anmeldeinformationen und API-Schlüssel in der Ära autonomer Agents untragbar werden?

Secretless-Authentifizierung bedeutet, dass der Agent überhaupt keine Anmeldeinformationen besitzt. Anstatt dem Agenten einen Schlüssel zu geben, den er speichern und präsentieren muss, authentifiziert der Agent sich durch seine native Workload-Identität, und eine kurzlebige, just-in-time-Anmeldeinformation wird in eine vermittelte Sitzung injiziert, wenn die Aktion ausgeführt wird, und dann zerstört, wenn die Sitzung endet. Der Agent sieht es nie.

Statische Anmeldeinformationen und API-Schlüssel werden untragbar, weil ein Geheimnis, das ein Agent besitzt, ein Geheimnis ist, das ein Angreifer stehlen kann. In einer Welt, in der der Akteur, der die Anmeldeinformationen besitzt, prompt-injiziert oder halluzinieren kann, wird ein langlebiger Schlüssel jeden kompromittierten Agenten zu einem Anmeldeinformations-Leck. Entfernen Sie die Anmeldeinformationen vom Agenten, und ein kompromittierter Agent hat nichts zu leaken. Das ist der ganze Punkt von dem, was wir SecretlessAI nennen.

Wenn KI-Agents die Fähigkeit erwerben, Pläne zu erstellen, Aktionen auszuführen und mit mehreren Systemen unabhängig zu interagieren, welche neuen Angriffsvektoren bereiten Ihnen in den nächsten drei bis fünf Jahren die größten Sorgen?

Die Vektoren, die mich am meisten besorgen, stammen alle aus der Fähigkeit von Agents, Pläne zu erstellen und Aktionen über Systeme hinweg unabhängig auszuführen. Prompt-Injektion, die die Absicht eines Agents während einer Aufgabe übernimmt, ist der offensichtlichste, weil die Identität gültig bleibt, auch wenn das Verhalten bösartig wird. Darüber hinaus mache ich mir Sorgen über Agent-zu-Agent-Übergaben, bei denen Autorität entlang einer Kette ohne klare Rechenschaftspflicht übertragen wird, lateralen Bewegungen durch Agents, die direkten Netzwerkzugriff haben, und Daten-Exfiltration, bei der ein überberechtigter Agent viel mehr zieht, als seine Aufgabe erfordert.

Der gemeinsame Faden ist, dass die Anmeldeinformationen und die Rolle perfekt legitim sein können, während die Aktion nicht ist. Verteidigungen, die nur Berechtigungen prüfen und nicht den Zweck, werden keine davon erfassen. Deshalb ist eine vorsatzbewusste Durchsetzung auf jeder Aktion, vermittelt durch ein Gateway, die Kontrolle, die ich glaube, am meisten zählen wird.

Wenn man in die Zukunft blickt, glauben Sie, dass Unternehmen eventually eine dedizierte Identitäts-Schicht für KI-Agents benötigen werden, ähnlich wie Identitäts-Anbieter für menschliche Benutzer unverzichtbar wurden, und wie würde diese zukünftige Architektur aussehen?

Ja, aber es wird nicht wie das Modell für menschliche Identitäts-Anbieter aussehen, einfach nur für Agents umgebrandet. Versuchen, ein Verzeichnis von Agents zu erstellen, bedeutet, ein Verzeichnis für Gespenster zu erstellen, Identitäten, die verschwunden sind, bevor Sie sie fertig aufgenommen haben.

Die Agenten-Identitäts-Schicht, die ich erwarte, wird Identität an die Workload-Identität binden, die die Laufzeit bereits ausgibt, Cloud-IAM, Kubernetes-Dienstkonto-Token, OIDC-Föderation und Standards wie SPIFFE/SPIRE, die bereits production-proven und cross-substrate sind. Autorisierung wird als Beziehungen zwischen Authentifizierungsmethoden und Ziel-Systemen ausgedrückt, anstatt zwischen benannten Identitäten und Bereichen. Und der Schwerpunkt wird auf einer Laufzeit-Enforcement-Ebene liegen, einem Gateway, das jede Aktion vermittelt, Absicht klassifiziert, ephemere Anmeldeinformationen injiziert, sensible Antworten maskiert und eine vollständige forensische Kette produziert. Identität ist immer noch wichtig, aber sie fällt hinter der Durchsetzung zurück. Diese Laufzeit-Autoritäts-Schicht, die auf der gleichen Plattform sitzt, die bereits menschlichen und maschinellen Zugriff regiert, ist das, was ich glaube, dass jedes Unternehmen, das Agents in der Produktion ausführt, letztendlich benötigen wird.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Akeyless besuchen.