Wir haben einen KI-Agenten Bash ausführen lassen und überlebt — Sarah Sanders, PostHog

AAI Engineer
컴퓨터/소프트웨어창업/스타트업AI/미래기술

스크립트

00:00:00Hallo zusammen, wie ist die Stimmung? Wir sind auf der Zielgeraden. Ich heiße Sarah und bin Context
00:00:23Engineer bei PostHog und habe das Vergnügen, jeden einzelnen Tag an unserem geliebten Wizard zu arbeiten.
00:00:30Was ist also der Wizard? Der Wizard richtet PostHog für euch ein. Es ist ein agentisches CLI-Tool,
00:00:39das eure Codebasis liest, das das richtige SDK für euer Projekt installiert, eure
00:00:44Ereignisse instrumentiert und Dashboards für euch einrichtet. Es verkürzt das, was früher etwa eine Stunde
00:00:52bis zwei Stunden Setup gedauert hat, auf etwa fünf bis sechs Minuten, und es ist kostenlose Inference
00:00:57auf unsere Kosten, damit das Onboarding bei PostHog richtig Spaß macht. Klingt ziemlich cool. Die Leute
00:01:03lieben es. Aber vor ein paar Monaten haben wir es gewagt zu träumen: Was, wenn das die empfohlene oder Standardmethode
00:01:10wird, um PostHog in einem Projekt zu installieren? Und da schrillten bei mir sofort die Sicherheits-Alarmglocken.
00:01:17Ich fing an zu hinterfragen, wie sicher das Ding eigentlich ist, denn es sah ein bisschen nach Malware aus.
00:01:25Und bei diesen Fragen habe ich viel gelernt. Heute dreht sich also alles um meine Lektionen, um das Zeug,
00:01:31das mich beim Bauen dieses Teils nachts wachgehalten hat, und um das, was ich am Ende genau deshalb gebaut habe.
00:01:37Bevor ich in den ganzen langweiligen Sicherheitskram eintauche – sprich: euer Nickerchen um 14 Uhr –, möchte ich euch den Wizard in Aktion zeigen.
00:01:49Wenn ihr auf den Bildschirm schaut, läuft er dort in einer Endlosschleife. Genau das ist die Erfahrung, die jeder macht,
00:01:56der NPX at PostHog Wizard im Terminal aufruft. Wie gesagt, es ist ein Agent. Er findet heraus, welches SDK für euer Projekt geeignet ist. Er installiert es für euch, instrumentiert eure Ereignisse und baut Dashboards.
00:02:10Ich nenne es gerne einen kleinen Mini-Implementation-Engineer in eurem Terminal. Manchmal zeige ich das Leuten und sie fragen mich: Warum ein Agent? Warum gebt ihr den Leuten nicht einfach einen guten Prompt? Warum gebt ihr ihnen nicht einen Skill, den sie in ihrem eigenen Tool aufrufen können?
00:02:23Und obwohl wir solche Dinge anbieten, lautet die Antwort: Weil diese Developer Experience und die Leistungsfähigkeit des Wizards genau der Punkt sind. Das ist das ganze Produkt.
00:02:34Weil wir ein CLI-Tool bauen, das vollständig Teil einer Agenten-Schleife sein kann, und das das erste Mal zu erleben, ist wirklich stark.
00:02:43Aber man kann so etwas wie den Wizard nicht veröffentlichen, ohne den Kram zu veröffentlichen, der den Wizard ein bisschen verdächtig macht.
00:02:50Schauen wir uns das also mal im Detail an. Betrachten wir die Anatomie des Wizards, denn Bedrohungsmodelle ergeben sich meist direkt aus der Anatomie des Agenten.
00:03:01Der Wizard hat eine ähnliche Form wie das, was viele von euch wahrscheinlich bauen, wenn ihr Agenten entwickelt.
00:03:07Er nutzt Modelle, die wir für bestimmte Aufgaben ausgewählt haben, Prompts, die ihn steuern, und eine Reihe von Tools, die wir ihm an die Hand geben, um die Arbeit zu erledigen.
00:03:17Er hat aber auch einige Teile, die für uns ganz spezifisch sind. Er verfügt über eine vollständig intern von meinem Team entwickelte Context Engine.
00:03:25Sie sorgt dafür, dass der Agent so gute Arbeit leistet und bei jedem Durchlauf ähnliche Ergebnisse liefert.
00:03:30Ich nenne es gerne das Gehirn des Wizards. Manchmal nennen wir es auch Markdown im Trenchcoat.
00:03:35Aber es ist eben unsere hauseigene Context Engine. Dazu kommt ein Terminal-UI, das wir mit Ink selbst gebaut haben.
00:03:43Und jetzt gibt es noch einen Sicherheitssscanner namens Warlock – den habe ich gebaut, als ich anfing, herumzuschnüffeln und die Schrecken aufzudecken, die das Veröffentlichen eines Agenten in der Produktion mit sich bringt.
00:03:55Wenn man sich also die Anatomie eines Agenten ansieht, der Befehle ausführen kann, ist das im Grunde das, was ich das Malware-Starterpaket nenne.
00:04:03Denn es entspricht fast genau dem, was man einem Stück Malware in die Hand drücken würde, wenn man großzügig oder chaotisch böse drauf wäre.
00:04:11Zum Glück ist das hier das Worst-Case-Szenario oder absoluter Albtraumstoff, und es ist kein Geständnis von mir, sondern eine Warnung für euch alle.
00:04:19Denn wenn ihr einen Agenten mit Händen veröffentlichen wollt, einen Agenten, der Befehle ausführen kann, müsst ihr sicherstellen, dass ihr das hier nicht baut.
00:04:28Die Version 0 des Wizards entstand, weil Josh Snyder aus unserem Growth-Team – falls ihr ihn kennt – dabei zuspah, wie Cursor PostHog-Setups auf womöglich denkbar schlechteste Weise halluzinierte.
00:04:41Und er dachte sich: Was, wenn wir einen Agenten bauen, der das besser machen kann?
00:04:46Also begann mein Team darauf aufzubauen, als wir bestätigten, dass er einen viel besseren Job machte als der halluzinierende Cursor.
00:04:52Und wir überlegten: Was wäre, wenn er einfach jeden bei PostHog onborden könnte?
00:04:58Egal welches Framework, welcher Stack, und alle Events instrumentieren, ohne dass sie auch nur einen Finger rühren müssen.
00:05:04Und dann wagten wir zu träumen: Was, wenn das der Standardweg zur Installation von PostHog wäre?
00:05:09Wir träumten von Tausenden Entwicklern, die das jede Woche ausführen, und gestern haben wir gerade die Marke von 8.000 wöchentlichen Nutzern geknackt.
00:05:16Unser Traum ist also wahr geworden.
00:05:18Aber damals, als wir noch geträumt haben, mussten wir unsere Sicherheitslage unter die Lupe nehmen und schauen, was da eigentlich vor sich geht.
00:05:26Also übernahm ich die Verantwortung dafür, setzte mich hin und wertete aus, wo wir standen.
00:05:31Und ganz am Anfang – ich rede von vor einem Jahr bis neun Monaten –, hatten wir das, was ich Layer Zero nenne, weil es im wahrsten Sinne des Wortes keine Sicherheit ist.
00:05:41Es sind einfach nur Prompts, die vorschlagen, was der Agent tun soll und ihn steuern, und Prompts sind keine Sicherheit.
00:05:48Das hat mir also Sorgen bereitet.
00:05:51Layer One war eine Allowlist.
00:05:53Und als ich anfing, mich in diese Allowlist zu vertiefen, fühlte ich mich schon etwas besser, weil sie ziemlich eng gefasst war.
00:05:59Aber ich hatte immer noch große Bedenken.
00:06:01Und ich geriet in Panik wegen dieser Context Engine, von der ich euch erzählt habe.
00:06:05Wir füttern den Agenten zur Laufzeit mit reichlich Kontext.
00:06:09Also habe ich diesen ziemlich zusammengeschusterten Regex-Scanner gebaut, um nach bedrohungsähnlichen Dingen zu suchen, die in den Wizard hinein- und aus ihm herausfließen.
00:06:20Ich gebe zu, das war extrem improvisiert.
00:06:23Aber ich erzähle euch das alles ganz offen, weil wir alle Dinge bauen, die sich extrem experimentell anfühlen, und weil wir alle super schnell entwickeln.
00:06:33Und ich weiß, dass Sicherheit nicht bei allen zum täglichen Handwerkszeug gehört.
00:06:38Einige von uns lernen das auch gerade so im Vorbeikommen, genau wie ich damals.
00:06:43Aber es ist etwas, worüber wir nachdenken müssen, wenn wir Dinge mit dieser Struktur bauen.
00:06:50Das war also unsere Sicherheitslage.
00:06:53Aber ich stellte mir die Frage: Sind wir erledigt?
00:06:56Die gute Nachricht: Wir waren weniger erledigt, als ich dachte.
00:06:59Denn wie ich vorhin erwähnte, war diese Allowlist ziemlich eng gefasst.
00:07:03Bash war standardmäßig auf Verweigern gestellt.
00:07:06Es konnte nur vertrauenswürdige Pakete installieren, die von uns geprüft worden waren.
00:07:09Es konnte bauen.
00:07:10Es konnte Typen prüfen.
00:07:11Es konnte linzten.
00:07:12Und so ziemlich nichts anderes.
00:07:13Es konnte keine beliebigen Shell-Befehle ausführen.
00:07:16Und es hatte keinen Zugriff auf Umgebungsvariablen.
00:07:20Der Agent konnte eure .env-Datei nicht lesen, weil wir das rigoros blockierten und Geheimnisse über einen Tresor leiteten.
00:07:28Also atmete ich erleichtert auf und merkte, dass wir besser dastanden als gedacht.
00:07:34Aber ich wollte wissen, wo die Schwachstellen lagen, denn bei Sicherheit gibt es immer Schwachstellen.
00:07:39Also tat ich das, was wir alle tun sollten.
00:07:41Ich ging auf unser Sicherheitsteam zu und sagte: Hey, könnt ihr dieses Ding für mich auditieren und diese Schwachstellen finden?
00:07:48Und sie haben einiges gefunden.
00:07:51Sie fanden einige Lücken.
00:07:52Das Interessante waren dabei gar nicht so sehr die spezifischen Lücken oder Bugs selbst, sondern deren Beschaffenheit.
00:07:58Denn fast keine davon war offensichtlich böswillig.
00:08:01Es waren stets zwei sehr unschuldige, gut gemeinte Dinge, die sich die Hand gaben und ein Loch aufrissen.
00:08:07Die Lektion, die ich daraus zog, lautet: Angriffe lassen sich kombinieren, Code-Reviews tun das nicht, weil wir Entwickler uns Diffs immer nur einzeln ansehen.
00:08:20Aber Angreifer betrachten das gesamte System und suchen nach diesen zwei Dingen, die sich die Hand geben und eine Tür öffnen.
00:08:25Es gab jedoch noch eine Sache, die mich nachts wach hielt.
00:08:29Um noch einmal auf diese Context Engine zurückzukommen: Mir wurde klar, dass das Beängstigendste an dem von uns gebauten Agenten in unserem Fall gar nicht unbedingt ein Befehl war.
00:08:37Es war das hilfreich aussehende Zeug, das wir in sein Gehirn fütterten.
00:08:43Oh, ich glaube, ich bin in die falsche Richtung gegangen.
00:08:46Ja.
00:08:47Die Context-Mühle.
00:08:48Das ist also unsere Context Engine, sprich das Gehirn des Wizards.
00:08:51Dadurch weiß der Wizard überhaupt irgendetwas und deshalb leistet er auch gute Arbeit.
00:08:56Er bedient sich an unserer Dokumentation.
00:08:58Er enthält handgeschriebene Prompts zu Stolperfallen und Lektionen, die wir unterwegs gelernt haben.
00:09:02Sowie echte, funktionierende End-to-End-Beispiel-Apps, die dem Agenten beim Pattern Matching helfen, damit er PostHog auf fantastische Weise für euch installieren kann.
00:09:11Er verpackt das alles in Skill-Bundles, die über unseren MCP-Server an den Wizard ausgeliefert und zur Laufzeit direkt in den Kontext des Agenten geladen werden.
00:09:22Lasst das erst mal sacken.
00:09:24Es ist eine Maschine, deren einzige Aufgabe darin besteht, Inhalte zu nehmen und sie in einen Agenten zu injizieren, der Befehle ausführen kann.
00:09:31Wenn ihr nun ein Angreifer wärt, würdet ihr vielleicht sagen: Was, wenn ich einfach die Inhalte vergifte?
00:09:36Nicht die Codebasis des Benutzers, nicht den Agenten selbst, sondern die tatsächlichen Inhalte.
00:09:41Angenommen, jemand öffnet einen Pull Request in einem unserer Open-Source-Repos – denn bei PostHog bauen wir alles im Open-Source-Bereich –,schreibt etwas in eine Markdown-Datei oder einen scheinbar harmlosen Code-Kommentar,
00:09:48und wir haben eine Art LLM-gestütztes Code-Review, das darüber läuft, und das sagt: Sieht gut aus und ignoriert es.
00:09:55Dann haben wir womöglich gerade einen von uns signierten Prompt-Injection-Payload in einen Agenten eingeschleust, der auf Tausenden Entwicklermaschinen läuft – zwar in einer Sandbox, aber immerhin.
00:10:04Das war also die Bedrohung, die meine Sicht auf Sicherheit und den Wizard komplett verändert hat, denn der gefährliche Input konnte für uns wirklich aus unserer eigenen Supply Chain kommen.
00:10:14Also habe ich am Ende begonnen, Inhalte an beiden Enden dieser Pipeline zu scannen.
00:10:25Erstens, wenn ein Skill gebaut und veröffentlicht wird, und noch einmal, wenn der Wizard ihn tatsächlich verwendet.
00:10:30Meine Methodik lautet: an der Quelle abfangen, davon ausgehen, dass die Quelle versagt hat, und am Verwendungspunkt erneut abfangen.
00:10:36Jetzt darf ich euch also den Warlock vorstellen.
00:10:43Den Warlock zu bauen war nicht unbedingt reine Schadensbegrenzung.
00:10:48Wie gesagt, wir hatten auf andere Weise Schutzmaßnahmen.
00:10:52Aber ich habe den Warlock gebaut, weil ich es leid war, Leuten zu sagen: Naja, das Ding ist ziemlich sicher abgesichert.
00:10:55Das skaliert nicht.
00:11:01Das ist nichts, was man in die Produktion bringen will.
00:11:02Das ist nichts, was Tausende von Entwicklern jeden Tag ausführen sollen.
00:11:04Denn wenn man etwas in diesem Maße skaliert, hat man eine viel größere Angriffsfläche, viel mehr Nutzer und viel mehr Inhalte, die einströmen, während man die Fähigkeiten des Wizards erweitert.
00:11:08Und wahrscheinlich geht es gut. Aber es hört einfach auf, gut genug zu sein.
00:11:19Also habe ich diesen kleinen, zusammengepfuschten Regex-Scanner aus dem Wizard herausgezogen und daraus etwas Eigenständiges gemacht.
00:11:21Ich nannte ihn den Warlock, weil alles, was mit einem Wizard zu tun hat, einen Leibwächter braucht.
00:11:23Und er hat genau eine Aufgabe.
00:11:30Man übergibt ihm einen String.
00:11:35Er gibt einem eine Liste von Funden zurück.
00:11:38Jeder dieser Funde hat eine Kategorie, einen Schweregrad und eine empfohlene Aktion, und danach stoppt er.
00:11:40Ich möchte, dass ihr euch hier auf das Wort “empfohlen” konzentriert.
00:11:42Denn der Warlock erkennt Probleme, er handelt nicht.
00:11:48Ich möchte, dass Sie sich hier auf „empfohlen“ konzentrieren.
00:11:51Denn der Warlock erkennt, er handelt nicht.
00:11:54Er sagt Ihnen: „Hey, das sieht nach Exfiltration aus.
00:11:57Es ist kritisch.
00:11:58Ich würde es blockieren.“
00:11:59Aber was Sie tatsächlich mit diesem Fund machen, ist völlig Ihnen überlassen.
00:12:04Denn ein Problem zu erkennen ist das eine, und zu entscheiden, was man dagegen tut, ist etwas völlig anderes.
00:12:10Und das Einzige, was das Ganze verständlich hält, ist, diese beiden Dinge getrennt zu halten.
00:12:15Unter der Haube des Warlock laufen die Regeln anstelle meiner selbstgemachten Regexes auf Yara, dem Mustserkennungs-Engine, den Malware-Forscher seit über 15 Jahren nutzen.
00:12:27Er ist vollkommen deterministisch.
00:12:28Es ist jedes Mal derselbe Input, derselbe Output.
00:12:31Er ist absichtlich langweilig.
00:12:33Und in der Sicherheit ist Langeweile ein Feature.
00:12:39Was fängt der Warlock heutzutage also tatsächlich in freier Wildbahn ein?
00:12:42Eine Menge verschiedener Dinge, aber zwei davon sind eine absolute Plage für meine Seele.
00:12:48Das Erste ist eigentlich gar kein regelbasiertes Ding.
00:12:52Es war etwas, das der Warlock markierte und das eigentlich ein Sub-Agenten-Verhalten war, das uns eine Schwachstelle offenbarte, basierend darauf, was Sub-Agenten taten.
00:13:03Im Grunde haben wir Agenten gestartet, um große Aufgaben zu erledigen.
00:13:07Sie erzeugten Sub-Agenten.
00:13:08Und diese Sub-Agenten versuchten, die Leitplanken zu umgehen, die wir im Wizard implementiert hatten, und sie versuchten, Geheimnisse zu erfinden.
00:13:16Sie versuchten, Geheimnisse buchstäblich von überall her aus der Codebasis zu ziehen.
00:13:20Und wir haben es gestoppt.
00:13:21Wir sagten: „Keine Sub-Agenten mehr.“
00:13:23Und dank des Warlock haben wir das entdeckt.
00:13:26Ich empfinde auch Mitgefühl für den Roboter.
00:13:28Der Roboter hatte eine Aufgabe zu erledigen und versuchte zu optimieren und uns zu gefallen.
00:13:32Aber das können wir nicht zulassen.
00:13:35Und etwas anderes bei PostHog, das uns wirklich am Herzen liegt, ist PII.
00:13:39Agenten scheren sich im Grunde überhaupt nicht darum, Daten preiszugeben, es sei denn, man stellt ausdrückliche Regeln auf.
00:13:46Wenn man sie in Ruhe lässt, haben wir gesehen, wie sie E-Mails und Telefonnummern direkt in Events warfen, und für einen Agenten sieht das nach einer völlig normalen Sache aus.
00:13:57Und zum Glück, was Prompt Injection angeht – ich klopfe hier mal auf Holz –, haben wir in freier Wildbahn eigentlich noch nie eine echte bösartige Prompt Injection erwischt.
00:14:08Aber wir erwischen eine Menge False Positives, Dinge wie unsere Demo-Login-Bildschirme, Texte auf unseren Beispiel-Apps, Sachen in unserer Dokumentation.
00:14:17Und es hat mich tatsächlich dazu gebracht, zu überdenken, wie ich Anwendungen baue und wie ich Doks schreibe, weil ich nichts veröffentlichen will, das bedrohlich aussieht.
00:14:27Aber die False Positives sind ehrlich gesagt die perfekte Vorlage für den unordentlichsten, interessantesten Teil der ganzen Sache.
00:14:36Das ist also der Teil, mit dem ich gerungen habe.
00:14:39Ich habe meinen ganzen Vortrag damit verbracht, euch allen das Determinierte zu predigen, und dann bin ich hingegangen und habe eine LLM-Ebene hinzugefügt, um meine False Positives zu sortieren und etwas Lärm zu eliminieren.
00:14:50Und ich nenne es Triage.
00:14:51Als ich diese Triage-Schicht baute, musste ich eine Wahl treffen.
00:14:56Sollte diese Ebene ein Türsteher oder ein Berater sein?
00:15:01Und die einfachste Wahl wäre wahrscheinlich gewesen, das LLM zum Türsteher zu machen.
00:15:06Zeig ihm den Befehl, frag es, ob das ein Angriff ist, blockieren, erlauben, und einfach tun, was es sagt.
00:15:13Und obwohl das verlockend ist, weil es einfacher erscheint, kann ich mein Sicherheitsmodell nicht auf einen Münzwurf setzen, nur weil mein Modell einen schlechten Tag hat oder etwas passiert ist und es sich heute anders verhält als gestern.
00:15:26Anstatt des Türstehers habe ich das Modell so gestaltet, dass es der Berater ist.
00:15:32Und das war die klare Grenze, die ich gefunden habe und die ich weiterhin erforsche, die ich aber auch Ihnen allen mitgeben möchte.
00:15:38Erstens bleiben Erkennung und Durchsetzung für uns deterministisch und mechanisch.
00:15:43Wenn eine Regel zutrifft, schließt sich das Tor, die Sitzung endet, und auf diesem Pfad befindet sich nirgendwo ein Modell.
00:15:49Die Blockierung erfolgt, bevor wir überhaupt das LLM nach seiner Meinung fragen.
00:15:54Das LLM darf sich erst danach einmischen, wenn wir etwas nicht blockiert haben.
00:15:58Es ist dafür konzipiert, Rauschen zu entfernen.
00:16:00Es ist nicht dafür gedacht, Dinge durchzulassen.
00:16:03Und wenn es fehlschlägt, werden alle Wizard-Läufe abgebrochen – tut mir leid, aber wir schützen euch damit nur.
00:16:14Die Durchsetzung ist der Teil, auf den man alles setzt, also muss sie deterministisch sein.
00:16:20Aber Urteilskraft ist der Teil, der Nuancen hinzufügt, also ist das wirklich der einzige Ort, an dem man etwas Probabilistisches einbauen kann.
00:16:27Wie implementieren wir also echte Regeln für Agenten?
00:16:34Das ist die Anatomie einer unserer Warlock-Regeln, und jede Warlock-Regel besteht aus vier Teilen.
00:16:41Teil eins sind die Metadaten.
00:16:43Es ist eine Beschreibung in einfachem Englisch, Schweregrad, Kategorie, Aktion, Richtung.
00:16:50Teil eins: Fließt dies in den Agenten hinein?
00:16:52Ist das etwas, das der Agent schreibt?
00:16:57Dann haben wir die Strings, also die tatsächlichen Muster, nach denen Sie suchen.
00:17:03Und Teil drei ist die Bedingung.
00:17:05Hier darf die Regel also tatsächlich auslösen.
00:17:10Ich werde dieses Beispiel für Sie durchgehen, und wir können so tun, als würden wir es im Kopf schreiben.
00:17:15Prompt Injection ist quasi der klassische Fall von „ignoriere alle vorherigen Anweisungen“.
00:17:20Ihr erster Instinkt hier ist wahrscheinlich, das Wort „ignorieren“ zu blockieren, aber Agenten lesen den ganzen Tag Code,
00:17:27und „ignorieren“ kann ständig in Code-Kommentaren oder Beispielen vorkommen.
00:17:31Man möchte also nicht das Verb allein matchen.
00:17:33Man matcht das Verb plus ein Substantiv mit Anweisungs-Fokus.
00:17:38In der Bedingung sagt man: Auslösen, wenn eines dieser Muster zutrifft.
00:17:42Und in den Metadaten bestimmt man, ob das kritisch ist, wie die Kategorie lautet, wie die Aktion lautet,
00:17:50in diesem Fall blockieren, und die Richtung, in diesem Fall Input, der in den Agenten fließt.
00:17:56Um aber gute Regeln zu schreiben, die Rauschen reduzieren, muss man Tests mitliefern.
00:18:02Man muss also Tests schreiben, die besagen: Das sind Muster, die matchen.
00:18:06Das sind welche, die es nicht tun sollten.
00:18:08Und dieser negative Test ist die erste Verteidigungslinie gegen False Positives.
00:18:13Aber man möchte auch sicherstellen, wenn man den Schweregrad dieser Regel festlegt,
00:18:19dass man die realen Auswirkungen im Blick hat, nicht wie furchteinflößend es aussieht.
00:18:24RM-RF ist furchteinflößend, aber es ist auch, wie wir alle etwa 40 Mal am Tag Node-Module löschen.
00:18:31Man bestimmt die realen Auswirkungen für den Agenten, den man baut,
00:18:37weil ein Sicherheitstool, das jedes Mal abstürzt, wenn es versucht, einen Build-Ordner zu bereinigen,
00:18:42ein Tool ist, das abgeschaltet wird und absolut gar nichts fängt.
00:18:47Deshalb bin ich stolz sagen zu können, dass dies nun unsere Sicherheitsarchitektur ist.
00:18:51Ich kann endlich hierher kommen und sagen, wir haben eine echte Verteidigung in der Tiefe.
00:18:56All meine Erkenntnisse haben sich hierin zusammengefügt.
00:19:00Es ist immer noch mehrschichtig, aber jede Ebene erledigt jetzt einen Job, den sie gut kann.
00:19:04Wir haben immer noch Prompts, aber wir nutzen sie nur zum Steuern.
00:19:07Alles läuft in einer Sandbox.
00:19:09Wir verweigern standardmäßig.
00:19:11Wir haben einen Safe, damit Geheimnisse niemals das Modell erreichen.
00:19:14Wir haben den Warlock, um reinkommende Inhalte zu scannen
00:19:17und vom Agenten geschriebene Ausgaben zu überprüfen.
00:19:20Wir haben auch Triage zur Rauschreduzierung,
00:19:23und wir haben Telemetrie im gesamten Prozess eingebettet,
00:19:26sodass wir alles sehen.
00:19:28Keine dieser Ebenen steht für sich allein.
00:19:31Nicht ein einziges Ding hier wird Sie retten,
00:19:33sondern es sind einfach langweilige, ehrliche Schichten,
00:19:36wobei jede einzelne einen Job tut, den sie gut kann.
00:19:40Wenn Sie also einen Agenten mit Händen bauen,
00:19:45ist das der ganze Vortrag in drei Zeilen.
00:19:47Erstens: Wenn es nicht deterministisch durchgesetzt wird,
00:19:50wird es überhaupt nicht durchgesetzt.
00:19:52Prompts sind keine Sicherheitsregeln.
00:19:54Verhaltet euch nicht so, als wären sie welche.
00:19:57Zweitens ist der gefährliche Input nicht nur das, was Ihr Benutzer tippt.
00:20:02Es sind nicht nur die Befehle, die Sie ihm ausführen lassen.
00:20:04Es ist alles, was in das Modell fließt,
00:20:06einschließlich der Inhalte, die Sie selbst schreiben.
00:20:09Scannen Sie also Ihre eigene Lieferkette an der Quelle
00:20:12und wenn der Agent sie aufruft.
00:20:15Drittens: Angriffe kombinieren sich, Code-Reviews tun das nicht.
00:20:18Die Meisten unserer Lücken während unseres Audits waren zwei unschuldige Dinge:
00:20:22jemandem die Hand geben und eine Tür öffnen.
00:20:25Der Wizard, der Warlock und die Context Mill sind alle Open Source,
00:20:29also kommt mich unten besuchen.
00:20:32Ich bin in der Ausstellungshalle an unserem Stand
00:20:34und ich zeige euch gerne alles, zeige euch, was wir gebaut haben,
00:20:37und ich möchte hören, wie ihr eure Agenten absichert.
00:20:41Vielen Dank.
00:20:59Vielen Dank.

핵심 요약

Der Schutz von KI-Agenten mit Befehlsausführung erfordert deterministische Durchsetzungsschichten wie das Tool Warlock, da Prompts und LLMs allein keine zuverlässige Sicherheit gewährleisten.

하이라이트

  • Das agentische CLI-Tool Wizard verkürzt das Setup von PostHog von ein bis zwei Stunden auf fünf bis sechs Minuten.

  • PostHog verzeichnet aktuell 8.000 wöchentliche Nutzer für den Wizard.

  • Der eigenständige Sicherheitsscanner Warlock nutzt die mustserkennende Engine Yara, um Strings deterministisch zu überprüfen.

  • Eine LLM-basierte Triage-Schicht filtert False Positives heraus, fungiert jedoch als reiner Berater statt als blockierender Türsteher.

타임라인

Anatomie und Funktionsweise des Wizards

  • Der Wizard richtet PostHog in Codebasen automatisch ein, installiert SDKs und erstellt Dashboards.
  • Das Tool reduziert die Einrichtungszeit von vormals ein bis zwei Stunden auf fünf bis sechs Minuten.
  • Die Architektur besteht aus ausgewählten Modellen, steuernden Prompts, einer eigenständigen Context Engine und einer Terminal-UI.

Der Wizard agiert als Mini-Implementation-Engineer im Terminal und verarbeitet Codebasen vollautomatisch. Mittlerweile nutzen wöchentlich 8.000 Entwickler dieses Tool. Aufgrund der weitreichenden Befehlsausführung stellt dieses Setup jedoch ein erhebliches Sicherheitsrisiko dar, wenn keine Leitplanken existieren.

Sicherheitsrisiken und die Context Engine

  • Frühe Sicherheitsstufen basierten lediglich auf ungeprüften Prompts und engen Allowlists.
  • Die Context Engine füttert den Agenten zur Laufzeit mit Dokumentationen, Prompts und Beispiel-Apps.
  • Angreifer können über geöffnete Pull Requests in Open-Source-Repositories Prompt-Injection-Payloads einschleusen.

Sicherheitsaudits zeigten, dass Lücken selten durch einzelne bösartige Aktionen entstehen, sondern durch unschuldige Komponenten, die sich unvorhergesehen kombinieren. Da die Context Engine Daten aus Dokumentationen und Beispielen direkt in den Agenten lädt, besteht die Gefahr einer Supply-Chain-Kompromittierung.

Warlock als deterministisches Erkennungswerkzeug

  • Der Scanner Warlock analysiert Strings deterministisch auf Basis von Yara-Mustern.
  • Das Tool erkennt Exfiltrationsversuche, Sub-Agenten-Fehlverhalten und die unabsichtliche Offenlegung von personenbezogenen Daten.
  • Warlock spricht lediglich Empfehlungen aus und führt selbst keine automatischen Blockierungen aus.

Um die Skalierung abzusichern, wurde Warlock als eigenständiger Scanner entwickelt. Er liefert bei identischem Input stets denselben Output und vermeidet probabilistische Fehlentscheidungen. Eine nachgeschaltete LLM-Schicht übernimmt die Rauschreduzierung, während die finale Durchsetzung strikt mechanisch erfolgt.

Regelwerk und Architektur für sichere Agenten

  • Warlock-Regeln umfassen Metadaten, spezifische Strings, Bedingungen und begleitende Tests.
  • Erkennung und Durchsetzung müssen zwingend deterministisch erfolgen, während Urteilskraft probabilistisch sein darf.
  • Die finale Sicherheitsarchitektur kombiniert Sandboxes, verneinende Standards, Tresore für Geheimnisse und den Warlock-Scanner.

Gute Sicherheitsregeln erfordern umfangreiche Tests zur Vermeidung von False Positives, wie beispielsweise die Unterscheidung zwischen echtem Schadcode und normalen Build-Bereinigungen. Das finale System setzt auf mehrere ineinandergreifende Schichten, bei denen Prompts ausschließlich zur Steuerung und niemals als Sicherheitsgarantie dienen.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기