Sean Blanchfield, Co-Founder und CEO von Jentic – Interview-Serie

Sean Blanchfield, Co-Founder und CEO von Jentic, ist ein serielles Technologie-Unternehmer mit jahrelanger Erfahrung im Aufbau von groß angelegten Software- und Infrastruktur-Unternehmen. Mit Sitz in Dublin leitet er derzeit Jentic und ist auch Mitglied des irischen AI-Beirats, der die Regierung in Fragen der künstlichen Intelligenz berät. Zu Beginn seiner Karriere gründete er DemonWare, eine Online-Service-Plattform für große Videospiel-Verleger, die später von Activision Blizzard (ATVI ) übernommen wurde, und PageFair, ein von Risikokapitalgebern unterstütztes Start-up, das sich auf Ad-Blocking-Analytics spezialisiert hat und von Blockthrough übernommen wurde. Er hat auch mehrere Start-ups gegründet oder geleitet und unterstützt weiterhin das irische Start-up-Ökosystem durch Initiativen wie Techpreneurs.

Jentic entwickelt eine universelle Integrations-Schicht, die es künstlichen Intelligenz-Agenten ermöglicht, sicher mit Unternehmens-Systemen und APIs zu interagieren. Die Plattform ermöglicht es Organisationen, künstliche Intelligenz-Modelle mit internen Tools, externen Diensten und betrieblichen Workflows zu verbinden, während sie Governance, Authentifizierung und Überwachung aufrechterhalten. Durch die Umwandlung von fragmentierten APIs in strukturierte Schnittstellen, die künstliche Intelligenz-Agenten zuverlässig nutzen können, zielt Jentic darauf ab, Unternehmen dabei zu helfen, künstliche Intelligenz-gesteuerte Automatisierung im großen Maßstab über komplexe Software-Umgebungen hinweg zu implementieren.

Sie haben mehrere Technologie-Unternehmen gegründet und geleitet, von DemonWare (übernommen von Activision Blizzard) bis hin zu PageFair und jetzt Jentic, und Sie sind auch Mitglied des irischen AI-Beirats. Was hat Sie dazu gebracht, wieder auf der Infrastruktur-Ebene aufzubauen, und welche Lücke haben Sie im aufstrebenden Ökosystem der künstlichen Intelligenz-Agenten gesehen, die andere verpasst haben?

Beim dritten Mal, wenn man ein Muster bemerkt, muss man es ernst nehmen. Bei DemonWare sprach jeder über Online-Multiplayer – aber das harte Problem war die Netzwerk-Infrastruktur darunter. Das gleiche passiert mit künstlichen Intelligenz-Agenten. Die Modelle sind bemerkenswert. Der Flaschenhals ist die Integrations-Schicht – immer war es so. Künstliche Intelligenz-Agenten laufen auf APIs, und diese APIs wurden für Menschen erstellt: dokumentiert für Menschen, gesichert für Menschen und strukturiert für Menschen. Wenn man einen autonomen Agenten auf diese Infrastruktur richtet, bricht er schnell zusammen. Enterprise-KI-Piloten scheitern nicht, weil das Modell die Aufgabe missverstand, sondern weil der Agent nicht zuverlässig mit den Systemen verbinden konnte, die er benötigte. Generative KI bietet eine neue Möglichkeit, dieses Problem zu lösen – indem man die Integration als Wissens-Problem und nicht als Codier-Problem behandelt. Diese Erkenntnis hat mich angezogen.

Als Sie Jentic 2024 gründeten, war die Sicherheit der Agenten von Anfang an das Hauptanliegen, oder hat sich der Fokus verschärft, als Sie beobachteten, wie Organisationen autonome Agenten in der Produktion einsetzten?

Der erste Faden, den ich zog, war die Anmeldeinformationen. Ich stellte mir vor, dass Agenten sich vermehrten, jeder von ihnen benötigte Anmeldeinformationen für Dutzende von Systemen, all diese Geheimnisse flossen in LLM-Kontextfenster, wurden exfiltriert – ein heilloses Durcheinander. Die Antwort ist dieselbe wie vor zwanzig Jahren: Zentralisieren Sie die Authentifizierung und Autorisierung. Aber wenn man diesen Faden zog, führte er direkt zum nächsten Problem: Wenn man die Zentralisierung mithilfe traditioneller Integrations-Tools durchführt, befindet man sich wieder im Land der statischen Konnektoren, und Agenten sind nicht statisch. Was die Vision zementierte, war die Erkenntnis, dass die Fähigkeits-Entdeckung eng mit der Zugriffskontrolle gekoppelt sein sollte – dass ein Agent nur eine Fähigkeit angeboten werden sollte, wenn er tatsächlich autorisiert ist, sie zu verwenden, und dass das System, das die Entdeckung bereitstellt, auch der einzige Punkt der Durchsetzung und Überwachung sein kann.

Die jüngste Aufdeckung einer großen Anzahl von internetfähigen Agenten-Instanzen hat gezeigt, wie Orchestrierung und Anmeldeinformationen oft die gleiche Vertrauens-Grenze teilen. Was ist aus Ihrer Sicht der Kern-Architektur-Fehler in diesem Modell?

Der Fehler ist einfach: Der Agent – ein System, das Anweisungen von einem LLM erhält – ist auch das System, das die Anmeldeinformationen hält und die API-Aufrufe durchführt. Wenn der Agent kompromittiert wird, erhält man alles, was er jemals tun kann. Es ist der gleiche Fehler, den wir in der frühen Web-Ära gemacht haben – Anwendungsserver mit Superuser-Datenbank-Zugriff, weil es bequem war. Jentic sitzt als Schicht zwischen dem Agenten und den APIs, die er aufruft. Der Agent hält nie Anmeldeinformationen. Er stellt Anfragen über unsere verwaltete Ausführungsschicht, die Anmeldeinformationen serverseitig injiziert, Richtlinien durchsetzt und jeden Aufruf protokolliert. Und wenn etwas schiefgeht, gibt es einen einzigen Kill-Schalter – eine Aktion, die den Zugriff des Agenten auf alle verbundenen Systeme gleichzeitig stoppt.

Sie haben über die Trennung von Orchestrierung und Ausführung gesprochen, um den Blast-Radius zu begrenzen. Können Sie erklären, wie diese Trennung die Risiko-Profile ändert, wenn eine Instanz kompromittiert wird?

Im flachen Modell denkt das LLM über das nachzuvollziehende Verfahren nach und ruft direkt APIs mit den Anmeldeinformationen auf, die es hält. Wenn die Denkschicht kompromittiert wird, kontrolliert man die Ausführungsschicht. Bei der Trennung gibt das LLM eine Absicht aus – “rufe die Stripe-Billing-API mit diesen Parametern auf” – eine verwaltete Ausführungsschicht validiert diese Anfrage gegen die Richtlinie, injiziert die Anmeldeinformationen serverseitig und ruft die API auf. Das LLM berührt nie die Anmeldeinformationen. In der Praxis: Die laterale Bewegung wird viel schwieriger, der Blast-Radius wird durch das begrenzt, was die Ausführungsschicht für diese spezifische Agenten-Identität zulässt, und man erhält einen Kill-Schalter. Ein Schalter und der Zugriff des Agenten wird über alle verbundenen Systeme hinweg gestoppt. Der Agent kann immer noch manipuliert werden – aber Manipulation bedeutet nicht mehr automatisch eine vollständige Kompromittierung der Anmeldeinformationen.

In realen Unternehmens-Einsätzen, wie sieht die zentrale Anmeldeinformations-Verwaltung und die sofortige Widerrufbarkeit tatsächlich aus, und wie unterscheidet sie sich von der Art und Weise, wie die meisten Teams derzeit API-Schlüssel und Token für Agenten verwalten?

Heute verwalten die meisten Teams API-Schlüssel, indem sie sie in einer .env-Datei speichern und sie beim Start des Agenten laden – oft direkt in das LLM-Kontextfenster. Niemand hat ein vollständiges Bild davon, welche Agenten welche Anmeldeinformationen halten. Wenn jemand das Unternehmen verlässt, werden die von ihm bereitgestellten Schlüssel nicht rotiert. Wenn ein Agent sich seltsam verhält, gibt es keine Audit-Spur, um zu rekonstruieren, was passiert ist. Mit Jentic verwalten Entwickler nie rohe Anmeldeinformationen. Sie erklären, welchen Zugriff ein Agent benötigt, die Plattform stellt den Zugriff bereit, und der Agent ruft durch unsere Ausführungsschicht auf, ohne jemals die zugrunde liegende Schlüssel zu sehen. Das bedeutet, dass man eine sofortige Widerrufbarkeit pro Agent, die Möglichkeit, den Zugriff zu pausieren, während man untersucht, und eine zeitgestempelte Audit-Spur jedes API-Aufrufs erhält. Der Unterschied zwischen diesem Ansatz und “API-Schlüssel in einer .env-Datei” ist erheblich.

Viele Teams experimentieren mit Agenten-Frameworks in den Bereichen Vertrieb, Ingenieurwesen und Datenwissenschaft. Welche häufigsten Sicherheits-Fehler sehen Sie, wenn Organisationen von der Experimentierung zur Produktion übergehen?

Die gleichen Muster wiederholen sich: überprivilegierte Agenten, die immer noch auf den Admin-Anmeldeinformationen laufen, mit denen sie prototypisch erstellt wurden; Anmeldeinformationen, die in Anweisungen oder Kontextfenstern übergeben werden, wo sie in Protokollen, Telemetrie und potenziell in Trainingsdaten landen; gemeinsam genutzte Anmeldeinformationen über mehrere Agenten-Instanzen, so dass man nicht isolieren kann, welcher Agent schlecht ist; kein Kill-Schalter, um einen Agenten zu stoppen, ohne das gesamte System herunterzufahren; keine Audit-Spur, die der Rede wert ist; und Anweisungs-Injektion wird nicht ernst genommen – obwohl jeder Agent, der E-Mails liest, Dokumente verarbeitet oder im Internet browsen kann, auf feindlich gestaltete Inhalte stoßen wird. Der gemeinsame Faden ist, dass diese Teams für den glücklichen Pfad gebaut haben und jetzt entdecken, dass die Produktion hauptsächlich aus unglücklichen Pfaden besteht.

Jentic positioniert sich als verwaltete Ausführungsschicht zwischen Agenten-Frameworks und externen Systemen. Wie setzt diese Zwischenschicht Governance um, ohne Entwickler zu behindern oder die Flexibilität der Agenten zu verringern?

Anstatt einen Agenten mit fünfzig verschiedenen APIs zu verbinden – jede mit ihrem eigenen Authentifizierungs-Schema, Rate-Limits und Eigenheiten – verbindet der Entwickler sich mit einem einzigen Endpunkt. Dieser Endpunkt bietet Tools, um unseren gesamten Katalog von API-Fähigkeiten zu durchsuchen, Details zu laden und jeden Aufruf auszuführen. Dies maximiert die Flexibilität durch eine einheitliche Schnittstelle zu unbegrenzten APIs, während es gleichzeitig Governance ermöglicht – welche Agenten greifen auf welche APIs zu, unter welchen Bedingungen, mit welchen Grenzen – all dies wird in der Plattform und nicht im Client-Code verwaltet. Die Ausführungsschicht ist ein Durchgang; Agenten können immer noch mehrschrittige Workflows komponieren, Aufrufe ketten und Fehler dynamisch behandeln. Governance ohne Reibung ist schwierig. Der Shortcut ist, die Last auf die Entwickler zu übertragen. Die Infrastruktur sollte das Gegenteil tun – diese Komplexität absorbieren, damit Entwickler nicht müssen.

Angesichts der Tatsache, dass Infostealer-Malware jetzt aktiv nach Agenten-Konfigurations-Dateien und gespeicherten Anmeldeinformationen zielt, sehen Sie einen Verschiebung der Aufmerksamkeit der Angreifer hin zu AI-Infrastruktur als neuer hochwertiger Angriffsfläche?

Absolut – und die Logik ist offensichtlich. Eine Agenten-Konfigurations-Datei ist effektiv ein Multi-Service-Super-Schlüssel: Anmeldeinformationen für E-Mail-Systeme, CRMs, Billing-Plattformen, interne APIs und GitHub-Konten. Ein erfolgreicher Infostealer-Lauf ergibt Monate des Zugriffs auf alle externen Systeme eines Unternehmens. Das ist ein dramatisch höherer Ertrag als die gezielte Angriffe auf einen einzelnen Dienst. Die andere Dimension ist, dass Agenten, die kontinuierlich in der Produktion laufen, persistente, authentifizierte Präsenzen sind – nicht ein Benutzer, der sich anmeldet und abmeldet. Ein kompromittierter Agent kann als langfristiger Fußabdruck dienen, der unter den Erkennungsschwellen operiert. Die unangenehme Realität ist, dass die Angriffsfläche sich schneller entwickelt als die Abwehr-Tools. Jentic kann die Angriffsfläche der Anmeldeinformationen erheblich reduzieren, aber wir können nicht verhindern, dass ein Agent die ihm gewährten Berechtigungen missbraucht. Dieses schwierigere Problem muss auf der Modell-Ebene gelöst werden, mit Schutzmechanismen und Anweisungs-Injektion-Erkennung.

Was sind die umfassenderen Sicherheits-Prinzipien, die Organisationen annehmen sollten, wenn sie agente KI sicher im großen Maßstab einsetzen möchten?

Die meisten verwalteten Organisationen können nicht-deterministische Systeme nicht in ihre wertvollsten Geschäftsprozesse einsetzen. Eine Bank oder Versicherung kann nicht einen autonomen Agenten auf ihr Billing-System richten und sagen: “Löse es einfach.” Wie also kann man innovativ sein, ohne dass die Risiko-Postur zu einem Bremsklotz wird? Die Antwort ist die Sandkasten-Umgebung. Erstellen Sie eine digitale Kopie Ihres API-Besitzes mit der gleichen Struktur und den gleichen Workflows, aber ohne Produktions-Anmeldeinformationen oder Konsequenzen. Setzen Sie Agenten dort ein, lassen Sie sie erkunden, beobachten Sie, was passiert. Die erfolgreichen Pfade werden als strukturierte, deterministische Workflow-Automatisierungen mit Arazzo, der offenen Workflow-Spezifikation, die innerhalb der OpenAPI-Initiative entwickelt wurde, erfasst: prüfbar, wiederholbar und von jedem Compliance-Team überprüfbar. Dies bedeutet, dass man mit KI-Geschwindigkeit im Sandkasten und mit Unternehmens-Geschwindigkeit in der Produktion agieren kann, und diese beiden Modi koexistieren. Die anderen Prinzipien gelten immer noch – least privilege, Audit-Spuren, Kill-Schalter, Trennung von Orchestrierung und Ausführung. Aber der Sandkasten ist die strukturelle Antwort auf die Frage, mit der sich Unternehmens-Teams tatsächlich auseinandersetzen: Wie können wir mit nicht-deterministischer KI experimentieren, ohne unsere Compliance-Postur darauf zu setzen? Man setzt die Nicht-Deterministik nicht ein. Man extrahiert den Wert daraus unter kontrollierten Bedingungen und setzt nur die deterministischen Ausgaben ein.

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