Sean Blanchfield, Mitgründer und CEO von Jentic – Interviewreihe

Sean Blanchfield, Mitgründer und CEO von Jentic, ist ein erfahrener Technologieunternehmer mit jahrzehntelanger Erfahrung im Aufbau großer Software- und Infrastrukturunternehmen. Er lebt in Dublin und leitet Jentic, während er gleichzeitig Mitglied des irischen KI-Beirats ist und die Regierung in Fragen der KI-Politik berät. Zuvor gründete er DemonWare, eine leistungsstarke Online-Service-Plattform für große Videospielverlage, die später von Activision Blizzard übernommen wurde, sowie PageFair, ein Venture-Capital-finanziertes Startup mit Fokus auf Ad-Blocking-Analysen, das von Blockthrough akquiriert wurde. Er hat außerdem mehrere Startups gegründet oder geleitet und unterstützt weiterhin das irische Startup-Ökosystem durch Initiativen wie Techpreneurs.

Jentic Jentic entwickelt eine universelle Integrationsschicht, die KI-Agenten die sichere Interaktion mit Unternehmenssystemen und APIs ermöglicht. Die Plattform erlaubt es Unternehmen, KI-Modelle mit internen Tools, externen Diensten und operativen Workflows zu verbinden und gleichzeitig Governance, Authentifizierung und Kontrolle zu gewährleisten. Durch die Umwandlung fragmentierter APIs in strukturierte Schnittstellen, die KI-Agenten zuverlässig nutzen können, unterstützt Jentic Unternehmen bei der skalierbaren Implementierung KI-gestützter Automatisierung in komplexen Softwareumgebungen.

Sie haben mehrere Technologieunternehmen gegründet und geleitet, von DemonWare (übernommen von Activision Blizzard) über PageFair bis hin zu Jentic, und sind außerdem Mitglied des irischen KI-Beirats. Was hat Sie dazu bewogen, mit Jentic wieder auf der Infrastrukturebene zu arbeiten, und welche Lücke im entstehenden Ökosystem der KI-Agenten haben Sie erkannt, die andere übersehen haben?

Wenn man ein Muster zum dritten Mal erkennt, muss man es ernst nehmen. Bei DemonWare sprachen alle über Online-Multiplayer – doch das eigentliche Problem war die zugrundeliegende Netzwerkinfrastruktur. Dasselbe passiert jetzt mit KI-Agenten. Die Modelle sind bemerkenswert. Der Flaschenhals ist die Integrationsschicht – das war schon immer so. KI-Agenten laufen über APIs, und diese APIs wurden für Menschen entwickelt: dokumentiert, gesichert und strukturiert. Setzt man einen autonomen Agenten auf diese Infrastruktur, bricht er schnell zusammen. KI-Pilotprojekte in Unternehmen scheitern nicht, weil das Modell die Aufgabe falsch verstanden hat, sondern weil der Agent keine zuverlässige Verbindung zu den benötigten Systemen herstellen konnte. Generative KI bietet einen neuen Lösungsansatz – indem sie Integration als Wissensproblem und nicht als Programmierproblem betrachtet. Diese Erkenntnis hat mich fasziniert.

Als Sie Jentic im Jahr 2024 gründeten, war die Agentensicherheit von Anfang an Ihr Hauptthema, oder hat sich der Fokus erst geschärft, als Sie beobachteten, wie Unternehmen autonome Agenten tatsächlich in der Produktion einsetzen?

Der erste Gedanke, den ich weiterverfolgte, betraf die Anmeldeinformationen. Ich stellte mir vor, wie sich die Agenten explosionsartig vermehren würden, jeder mit Anmeldeinformationen für Dutzende von Systemen. All diese Geheimnisse würden in die Kontextfenster von LLM fließen und abgegriffen werden – ein heilloses Durcheinander. Die Lösung wäre dieselbe wie vor zwanzig Jahren: Zentralisierung von Authentifizierung und Autorisierung. Doch dieser Gedanke führte direkt zum nächsten Problem: Bei der Zentralisierung mit herkömmlichen Integrationswerkzeugen landet man wieder im Bereich statischer Konnektoren, und Agenten sind nicht statisch. Was die Vision schließlich festigte, war die Erkenntnis, dass die Ermittlung von Berechtigungen eng mit der Zugriffskontrolle verknüpft sein sollte – dass einem Agenten eine Berechtigung nur dann angeboten werden sollte, wenn er tatsächlich zur Nutzung autorisiert ist, und dass das System, das die Ermittlung bereitstellt, gleichzeitig die zentrale Kontrollinstanz für Durchsetzung und Überwachung sein kann.

Die jüngsten Enthüllungen über eine große Anzahl von internetfähigen Agenteninstanzen haben deutlich gemacht, dass Orchestrierung und Anmeldeinformationen oft dieselbe Vertrauensgrenze nutzen. Was ist Ihrer Meinung nach der zentrale Architekturfehler dieses Modells?

Der Fehler ist simpel: Der Agent – ​​ein System, das Eingabeaufforderungen von einem LLM ausführt – ist gleichzeitig das System, das die Anmeldeinformationen speichert und die API-Aufrufe tätigt. Wird der Agent kompromittiert, erhält man uneingeschränkten Zugriff auf alle seine Funktionen. Es ist derselbe Fehler, den wir in der Frühzeit des Webs begangen haben: Anwendungsserver mit Superuser-Datenbankzugriff, weil es bequemer war. Jentic fungiert als Zwischenschicht zwischen dem Agenten und den von ihm aufgerufenen APIs. Der Agent speichert niemals Anmeldeinformationen. Er sendet Anfragen über unsere verwaltete Ausführungsschicht, die die Anmeldeinformationen serverseitig einfügt, Richtlinien durchsetzt und jeden Aufruf protokolliert. Und wenn etwas schiefgeht, gibt es einen einzigen Not-Aus-Schalter: Eine einzige Aktion unterbricht den Zugriff des Agenten auf alle verbundenen Systeme gleichzeitig.

Sie haben davon gesprochen, Orchestrierung und Ausführung zu trennen, um den Wirkungsbereich einzudämmen. Können Sie in praktischen Worten erläutern, wie diese Trennung das Risikoprofil verändert, wenn eine Instanz kompromittiert wird?

Im flachen Modell analysiert das LLM (Language-Level Management) die auszuführenden Aktionen und ruft APIs direkt mit den gespeicherten Zugangsdaten auf. Wird die Analyseebene kompromittiert, kontrolliert man die Ausführungsebene. Bei der Trennung sendet das LLM eine Absicht – „Ruf die Stripe-Abrechnungs-API mit diesen Parametern auf“ – eine verwaltete Ausführungsebene validiert diese Anfrage anhand von Richtlinien, fügt die Zugangsdaten serverseitig ein und führt den Aufruf durch. Das LLM greift dabei nie auf die Zugangsdaten zu. In der Praxis bedeutet dies: Die laterale Ausbreitung wird deutlich erschwert, der Wirkungsbereich ist durch die von der Ausführungsebene für die jeweilige Agentenidentität zugelassenen Maßnahmen begrenzt, und es steht ein Not-Aus-Schalter zur Verfügung. Ein einziger Schalter genügt, um den Zugriff des Agenten auf alle verbundenen Systeme zu unterbinden. Der Agent kann weiterhin manipuliert werden – Manipulation bedeutet jedoch nicht mehr automatisch die vollständige Kompromittierung der Zugangsdaten.

Wie sieht eine zentrale Verwaltung von Anmeldeinformationen und deren sofortiger Widerruf in realen Unternehmensumgebungen aus, und wie unterscheidet sie sich von der aktuellen Vorgehensweise der meisten Teams im Umgang mit API-Schlüsseln und Token für Agenten?

Heutzutage lassen die meisten Teams einen Entwickler API-Schlüssel bereitstellen, diese in einer .env-Datei speichern und beim Agentenstart laden – oft direkt in das Kontextfenster des LLM. Niemand hat einen vollständigen Überblick darüber, welche Agenten welche Anmeldeinformationen besitzen. Wenn ein Mitarbeiter das Team verlässt, werden die von ihm bereitgestellten Schlüssel nicht rotiert. Verhält sich ein Agent ungewöhnlich, gibt es keinen Prüfpfad, um den Vorfall zu rekonstruieren. Mit Jentic hingegen muss der Entwickler niemals direkt mit den Anmeldeinformationen arbeiten. Er deklariert den benötigten Zugriff eines Agenten, die Plattform stellt den entsprechenden Zugriff bereit, und der Agent ruft API-Schlüssel über unsere Ausführungsschicht auf, ohne jemals den zugrunde liegenden Schlüssel zu sehen. Das bedeutet: sofortiger Widerruf pro Agent, die Möglichkeit, den Zugriff während der Untersuchung anzuhalten, und ein mit einem Zeitstempel versehener Prüfpfad für jeden API-Aufruf. Der Unterschied zu „API-Schlüssel in einer .env-Datei“ ist enorm. .Die „env-Datei“ ist von erheblicher Bedeutung.

Viele Teams experimentieren mit Agenten-Frameworks in den Bereichen Vertrieb, Entwicklung und Datenwissenschaft. Welche Sicherheitslücken beobachten Sie am häufigsten beim Übergang von der Experimentierphase zur Produktionsumgebung?

Die gleichen Muster wiederholen sich: Agenten mit überprivilegierten Rechten laufen weiterhin mit den Administratoranmeldeinformationen, mit denen sie prototypisch entwickelt wurden; Anmeldeinformationen werden in Eingabeaufforderungen oder Kontextfenstern übergeben und landen so in Protokollen, Telemetriedaten und möglicherweise sogar in Trainingsdaten; Anmeldeinformationen werden von mehreren Agenteninstanzen gemeinsam genutzt, sodass ein einzelner Angreifer nicht isoliert werden kann; es gibt keinen Not-Aus-Schalter, um einen Agenten zu stoppen, ohne das gesamte System zu beeinträchtigen; es gibt keinen brauchbaren Audit-Trail; und die Manipulation von Eingabeaufforderungen wird nicht ernst genommen – obwohl jeder Agent, der E-Mails liest, Dokumente verarbeitet oder im Internet surft, auf manipulierte Inhalte stößt. Der gemeinsame Nenner ist, dass diese Teams für den Normalfall entwickelt haben und nun feststellen, dass der Produktionsbetrieb größtenteils aus Fehlern besteht.

Jentic positioniert sich als verwaltete Ausführungsschicht zwischen Agenten-Frameworks und externen Systemen. Wie gewährleistet diese Zwischenschicht die Einhaltung von Richtlinien, ohne die Entwickler auszubremsen oder die Flexibilität der Agenten einzuschränken?

Anstatt einen Agenten mit fünfzig verschiedenen APIs zu verbinden – jede mit eigenem Authentifizierungsschema, eigenen Ratenbegrenzungen und Eigenheiten –, greift der Entwickler auf einen einzigen Endpunkt zu. Dieser Endpunkt stellt Tools bereit, mit denen sich unser gesamter API-Katalog durchsuchen, Details laden und beliebige Aufrufe ausführen lassen. Dies maximiert die Flexibilität durch eine einheitliche Schnittstelle für unbegrenzt viele APIs und ermöglicht gleichzeitig die Kontrolle darüber, welche Agenten unter welchen Bedingungen und mit welchen Limits auf welche APIs zugreifen – alles plattformintern und nicht im Client-Code verwaltet. Die Ausführungsschicht ist eine reine Durchleitung; Agenten können weiterhin mehrstufige Workflows erstellen, Aufrufe verketten und Fehler dynamisch behandeln. Reibungslose Kontrolle ist schwierig. Der einfache Weg, die Last auf die Entwickler abzuwälzen, ist, die Infrastruktur genau das Gegenteil zu tun – diese Komplexität zu absorbieren, damit die Entwickler sie nicht tragen müssen.

Da Infostealer-Malware nun aktiv Agentenkonfigurationsdateien und gespeicherte Anmeldeinformationen ins Visier nimmt, gehen Sie davon aus, dass Angreifer ihren Fokus auf die KI-Infrastruktur als neues, wertvolles Angriffsziel verlagern werden?

Absolut – und die Logik ist einleuchtend. Eine Agentenkonfigurationsdatei ist im Grunde ein Multi-Service-Superkey: Zugangsdaten für E-Mail-Systeme, CRMs, Abrechnungsplattformen, interne APIs und GitHub-Konten. Ein einziger erfolgreicher Infostealer-Angriff ermöglicht monatelangen Zugriff auf alle externen Systeme eines Unternehmens. Das ist deutlich effektiver als der Angriff auf einen einzelnen Dienst. Hinzu kommt, dass Agenten, die kontinuierlich im Produktivbetrieb laufen, persistente, authentifizierte Präsenzen darstellen – keine Benutzer, die sich an- und abmelden. Ein kompromittierter Agent kann als langfristiger Zugang dienen und unterhalb der Erkennungsschwelle operieren. Die unangenehme Realität ist, dass sich die Angriffsfläche schneller entwickelt als die Abwehrmechanismen. Jentic kann die Angriffsfläche für Zugangsdaten deutlich reduzieren, aber wir können nicht verhindern, dass ein Agent die ihm zugewiesenen Berechtigungen missbraucht. Dieses komplexere Problem muss auf Modellebene gelöst werden, mit Schutzmechanismen und einer schnellen Erkennung von Angriffen.

Über ein einzelnes Rahmenwerk hinaus: Welche übergreifenden Sicherheitsprinzipien sollten Organisationen anwenden, wenn sie agentenbasierte KI sicher und in großem Umfang einsetzen wollen?

Die meisten Unternehmen können nicht-deterministische Systeme nicht in ihre wichtigsten Geschäftsprozesse integrieren. Eine Bank oder Versicherung kann beispielsweise nicht einfach einen autonomen Agenten auf ihr Abrechnungssystem ansetzen und sagen: „Finden Sie es selbst heraus.“ Wie also lassen sich Innovationen vorantreiben, ohne dass die Risikoposition zum Bremsklotz wird? Die Antwort lautet: Sandboxing. Erstellen Sie einen digitalen Zwilling Ihrer API-Landschaft mit derselben Struktur und denselben Workflows, jedoch ohne Zugriffsrechte und ohne Konsequenzen für die Produktion. Setzen Sie Agenten dort ein, lassen Sie sie experimentieren und beobachten Sie die Ergebnisse. Erfolgreiche Pfade werden mithilfe von Arazzo, der offenen Workflow-Spezifikation der OpenAPI Initiative, als strukturierte, deterministische Workflow-Automatisierungen erfasst – auditierbar, wiederholbar und von jedem Compliance-Team überprüfbar. Das bedeutet, dass Sie in der Sandbox mit KI-Geschwindigkeit und in der Produktion mit Unternehmensgeschwindigkeit arbeiten können, wobei beide Modi parallel existieren. Die anderen Prinzipien bleiben bestehen: minimale Berechtigungen, Audit-Trails, Not-Aus-Schalter und die Trennung von Orchestrierung und Ausführung. Die Sandbox ist die strukturelle Antwort auf die Frage, die Unternehmen oft beschäftigt: Wie können wir mit nicht-deterministischer KI experimentieren, ohne unsere Compliance-Position zu gefährden? Man setzt den Nichtdeterminismus nicht ein. Man gewinnt unter kontrollierten Bedingungen Nutzen daraus und setzt nur die deterministischen Ergebnisse ein.

Vielen Dank für das tolle Interview, Leser, die mehr erfahren möchten, sollten vorbeischauen Jentic.