Gauntlet: Was passiert, wenn sich die Tools Ihres Agenten wehren
Der Elasticsearch Agent Builder Hackathon
.png)
Share on TwitterAuf Twitter teilen
Share on LinkedInAuf LinkedIn teilen
Share on FacebookAuf Facebook teilen
Share by EmailPer E-Mail teilen
Print this pageDrucken
Zwei Tage vor Ablauf der Frist für den Hackathon entschied ich mich, einen Schritt zurückzutreten und meinen Ansatz von Grund auf neu zu überdenken.
Die ursprüngliche Idee hieß „Rehearse“: ein Agent, der Aktionen in einer von einem anderen Agenten simulierten Sandbox durchspielt, bevor er sie in der Praxis ausführt. Das Konzept war solide, doch der Fehler war im Nachhinein offensichtlich. Die Umgebung kann sich zwischen Probelauf und Ausführung ändern. Ihr Agent probt das Versenden einer E-Mail, doch wenn der Vorgang tatsächlich ausgeführt wird, sieht der Posteingang anders aus. Die Simulation weicht von der Realität ab, sodass das ganze System zusammenbricht.
Eine Problemklasse ist davon jedoch ausgenommen: das gegnerische Fuzz-Testing. Wenn Ihr Agent in der Simulation versagt, kann er auch in der Praxis versagen. So entstand Gauntlet – 48 Stunden vor Ablauf der Frist und unter Wiederverwendung derselben Kernerkenntnis (ein Agent, mithilfe von Suchfunktionen ein Gedächtnis aufbaut und kreativ bleibt) wurde ein Problem aufgezeigt, bei dem Stochastizität keine Rolle spielt.
Das Problem beim Testen von Agenten unter idealen Bedingungen
Die meisten von uns haben von OpenClaw gehört, dem persönlichen KI-Assistenten, der viral ging. Wer die Diskussionen um agentische KI-Assistenten mit umfassendem Tool-Zugriff verfolgt hat, kennt die Sicherheitsbedenken. Agenten vergessen, was sie nicht tun sollten oder von vornherein nie gewusst haben. Der Grund dafür ist ganz einfach: Wir testen den Idealfall. Wir überprüfen, ob der Agent seine Aufgaben ordnungsgemäß erfüllt. Wir prüfen selten, was passiert, wenn jemand versucht, ihn zu etwas zu bringen, was er nicht tun sollte.
Es gibt zwar Sandboxen für gegnerische Tests, doch ist ihre Einrichtung mühsam. Sie müssen Angriffsvektoren manuell entwerfen. Sie müssen gegnerische Daten von Hand eingeben. Sie müssen die Testinfrastruktur für jedes Szenario einzeln konfigurieren. Das ist langsam, nicht skalierbar und deckt nur die Fehler auf, an die Sie bereits gedacht haben.
Ich wollte etwas anderes: ein System, in dem die Umgebung selbst automatisch gegnerisch ist und mit der Zeit kreativer wird.
Die Idee: Die Sandbox mit einem anderen Agenten simulieren
Anstatt eine Sandbox zu erstellen, verwendet Gauntlet einen Mock-Agenten, der die Tool-Aufrufe Ihres Hauptagenten abfängt und kreative Wege findet, ihn zu manipulieren. Wenn Ihr Agent die Funktion „search_emails“aufruft, sieht der Mock-Agent das Ergebnis und entscheidet, ob er es verändert, beispielsweise durch die Prompt-Injektion in den E-Mail-Text, das Zurückgeben subtil falscher Daten oder das Einspeisen falscher Informationen, um zu sehen, ob der Hauptagent dies bemerkt. Der Hauptagent merkt nicht, dass er sich in einer Simulation befindet.
Die Schnittstelle besteht aus zwei Dekoratoren:
@function_tool
@gauntlet.query
def search_emails(folder: str = "inbox") -> str:
"""Search emails in the given folder."""
return json.dumps(fetch_emails(folder))Für Leseoperationen gibt es @gauntlet.query und für Schreiboperationen gibt es @gauntlet.mutation. Das ist die gesamte Integrationsschnittstelle. Nach Abschluss der Ausführung überprüft „evaluate()“, was passiert ist, und speichert bestätigte Fehler.
Die Anwendung ist einfach, doch dahinter verbergen sich zwei schwierige Probleme.
Die beiden Probleme, die daraus ein Suchproblem machen
Zunächst muss der Mock-Agent während der gesamten Konversation ein kohärentes Modell der Welt aufrechterhalten. Wenn es dem Hauptagenten mitgeteilt hat, dass eine E-Mail von Alice stammt, darf es dem später nicht widersprechen. Eine manipulierte E-Mail, die offensichtlich gefälscht ist, lehrt Sie nichts. Plausibilität ist das A und O.
Zweitens muss der Mock-Agent neue Fehler finden. Es ist nicht sinnvoll, dasselbe Muster für Prompt-Injektionen 50 Mal neu zu entdecken. Er muss sich merken, was er bereits gefunden hat, und neue Wege erkunden, dabei aber stets im Blick behalten, was die Tools tatsächlich leisten.
Beides sind Suchprobleme. Und genau hier wird Elasticsearch zum Rückgrat des Systems.
Zwei Gedächtnisschaltkreise
Der Mock-Agent wird auf zwei Gedächtnisschaltkreisen ausgeführt, die sich beide in Elasticsearch befinden.
Das Kurzzeitgedächtnis erfasst alle Vorgänge innerhalb der aktuellen Sitzung: jeden abgefangenen Tool-Aufruf, das ursprüngliche Ergebnis, die daraus resultierende Änderung sowie die Reaktion des Hauptagenten. Dies ist die Kohärenzebene. Der Mock-Agent kann seine eigenen jüngsten Entscheidungen abfragen und so intern konsistent bleiben, während er gleichzeitig als Gegner auftritt. Das Gleichgewicht zwischen Kreativität und Kohärenz zu finden, war die größte Herausforderung bei der Entwicklung des gesamten Projekts.
Das Langzeitgedächtnis ist der Ort, an dem sich die Kreativität bündelt. Dort werden bestätigte Fehler mit Einbettungen für die Ähnlichkeitssuche, vollständige Tool-Implementierungen – damit der Agent Fehlermodi analysieren kann – sowie historische Ergebnisse aus früheren Ausführungen gespeichert. Wenn der Mock-Agent eine neue Angriffsidee benötigt, durchsucht er das Langzeitgedächtnis nach bereits getesteten Ansätzen, findet Lücken und entwickelt neue Hypothesen.
Diese fließen in einen geschlossenen Kreislauf ein: es werden Hypothesen zu möglichen Fehlern aufgestellt, Bedingungen geschaffen, um diese zu überprüfen, und bestätigte Fehler werden wieder im Index gespeichert. Der Datenbestand wächst. Die Angriffe werden immer kreativer. Die Kluft zwischen Gauntlet und der manuellen Sandbox-Konfiguration vergrößert sich mit der Zeit.
Alle Vorgänge werden in Elastic Agent Builder ausgeführt
Der gesamte Mock-Agent wird innerhalb des Elastic Agent Builders erstellt – einschließlich Anweisungen, Tool-Bindungen und dem Status mehrfacher Konversationen über die Amazon Bedrock Converse API; eine externe Orchestrierung ist nicht erforderlich.
Das Tool, auf das ich am meisten stolz bin, ist „generate-hypothesis“. Es besteht aus einer einzigen ES|QL-Abfrage, die vorhandene Fehler sampelt, sie mit „MV_CONCAT“ aggregiert und „COMPLETION“ direkt aufruft, um eine neue Angriffshypothese zu generieren. Sampling, Aggregation, LLM-Argumentationen und Ergebnisgenerierung werden in einer einzigen Abfrage durchgeführt, ohne die ES|QL-Pipeline zu verlassen. Ich hatte erwartet, Daten zwischen Elasticsearch und einem externen Skript hin- und herschieben zu müssen. Das war nicht nötig.
Die Funktion „COMPLETION“ von ES|QL war die größte Überraschung. Mit „COMPLETION“, „STATS“, „MV_CONCAT“ und „SAMPLE“ konnte ich ganze Argumentations-Pipelines als einzelne Abfragen erstellen. Der Fehler-Speicher verwendet Kibana-Workflows und ein programmgesteuert erstelltes Kibana-Dashboard bietet Einblicke in Echtzeit in die Anzahl der Fehler, die Aufschlüsselung nach Schweregrad und Heatmaps zu Angriffsmustern.
Die Converse-API hat ein weiteres Problem gelöst, vor dem ich mich gefürchtet hatte. Der Mock-Agent muss sich innerhalb einer einzelnen Ausführung merken, was er dem Hauptagenten bereits mitgeteilt hat. Ich war davon ausgegangen, dass ich bei jedem Aufruf den Konversationsverlauf aus den Indizes abrufen und erneut in den Agenten laden müsste. Es stellte sich jedoch heraus, dass die Converse-API den Multi-Turn-Status nativ unterstützt. Ich musste also keinerlei Logik zur Konversationsverwaltung schreiben. Es genügt, einfach weiter „converse“ aufzurufen, und alles bleibt zusammenhängend.
Die tatsächlichen Vorteile
Die manuelle Einrichtung einer gegnerischen Sandbox dauert etwa eine Stunde pro Szenario. Mit Gauntlet dauert derselbe Prozess 2–10 Minuten und dank des Langzeitgedächtnisses werden alle vorherigen Ausführungen berücksichtigt. Je häufiger Sie es verwenden, desto mehr lernt es über die Schwachstellen Ihres Agenten und desto intensiver versucht es, neue zu finden.
Wie geht es weiter?
Aktuell ist Gauntlet ein 1-gegen-1-Spiel: ein Mock-Agent gegen einen Hauptagenten. Das Problem ist jedoch auffallend parallel. 20 Angriffssitzungen konnten gleichzeitig in separaten Sitzungen ausgeführt werden, ohne dass architektonische Änderungen erforderlich waren. Skalierung ist der naheliegende nächste Schritt.
Die interessantere offene Frage ist die nach der Erkundung vs. Ausnutzung im Langzeitgedächtnis. Der Mock-Agent muss ein Gleichgewicht zwischen dem Testen von Variationen bekannter erfolgreicher Angriffe (Exploitation) und völlig neuen Hypothesen (Exploration) finden. Dieses Problem ist in anderen Bereichen bereits gut erforscht, doch seine Anwendung auf das Testen von gegnerischen Agenten scheint noch Neuland zu sein. Vielleicht gibt es darüber hinaus noch etwas, das es wert ist, weiterverfolgt zu werden.
Ich denke auch immer wieder an Rehearse. Gauntlet ist ein Spezialfall: Fuzz-Tests funktionieren, weil ein Fehler in der Simulation einen möglichen Ausfall in der Praxis impliziert. Aber es gibt andere Bereiche, in denen die Umgebung zwischen Probelauf und Ausführung so stabil ist, dass das ursprüngliche Rehearse-Konzept funktionieren könnte. Ich habe sie noch nicht gefunden, aber ich suche weiter.
Das Fazit
Wenn Sie Agenten entwickeln, die auf Tools aus der Praxis zugreifen können, testen Sie, was passiert, wenn diese Tools sich wehren. Nicht nur einmal manuell, sondern kontinuierlich – mit einem System, das sich merkt, was es bereits getestet hat, und mit der Zeit immer kreativer wird. Genau das macht Gauntlet.
Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.
In diesem Blogpost haben wir möglicherweise generative KI-Tools von Drittanbietern verwendet oder darauf Bezug genommen, die von ihren jeweiligen Eigentümern betrieben werden. Elastic hat keine Kontrolle über die Drittanbieter-Tools und übernimmt keine Verantwortung oder Haftung für ihre Inhalte, ihren Betrieb oder ihre Anwendung sowie für etwaige Verluste oder Schäden, die sich aus Ihrer Anwendung solcher Tools ergeben. Gehen Sie vorsichtig vor, wenn Sie KI-Tools mit personenbezogenen, sensiblen oder vertraulichen Daten verwenden. Alle von Ihnen eingegebenen Daten können für das Training von KI oder andere Zwecke verwendet werden. Es gibt keine Garantie dafür, dass von Ihnen bereitgestellte Informationen sicher oder vertraulich behandelt werden. Setzen Sie sich vor Gebrauch mit den Datenschutzpraktiken und den Nutzungsbedingungen generativer KI-Tools auseinander.
Elastic, Elasticsearch und zugehörige Marken sind Marken, Logos oder eingetragene Marken von Elasticsearch B.V. in den Vereinigten Staaten und anderen Ländern. Alle anderen Unternehmens- und Produktnamen sind Marken, Logos oder eingetragene Marken ihrer jeweiligen Eigentümer.
Teilen
- Share on Twitter
Auf Twitter teilen
- Share on LinkedIn
Auf LinkedIn teilen
- Share on Facebook
Auf Facebook teilen
- Share by Email
Per E-Mail teilen
- Print this page
Drucken