Deno hat seine Agent-Firewall (Claw Patrol) als Open Source veröffentlicht

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

Transcript

00:00:00Das ist Claw Patrol, eine Open-Source-Sicherheits-Firewall, die vom Dino-Team entwickelt wurde und zwischen
00:00:04deinen KI-Agenten und dem Internet sitzt. Sie löst drei zentrale Sicherheitsprobleme bei KI-Agenten.
00:00:09Zugriff ist keine echte Kontrolle, dein Agent sollte keine Geheimnisse sehen, und du kannst nicht sehen, was dein Agent
00:00:14getan hat. Ich habe in letzter Zeit viele Sicherheits-Tools für KI-Agenten ausprobiert und mir gefällt der Ansatz,
00:00:19den Claw Patrol hier verfolgt, sehr gut, aber perfekt ist es noch nicht. Claw Patrol funktioniert so: Du hast
00:00:28einen Server namens Gateway, der deine Regeln, Anmeldedaten, Protokolle und das Claw Patrol-
00:00:32Dashboard verwaltet. Dazu hast du eine beliebige Anzahl an Maschinen, auf denen Agenten laufen, und sie können
00:00:36diesem Gateway beitreten und ihren Agenten-Verkehr darüber leiten. Tatsächlich kannst du wählen, ob du einzelne Befehle
00:00:40über das Gateway ausführst oder deine gesamte Maschine hinzufügst. In meinem Fall ist mein Gateway einfach ein Ubuntu-
00:00:45Server, mit dem ich mich über Tailscale verbinde, was Claw Patrol von Haus aus unterstützt, ebenso wie
00:00:50WireGuard oder beides. Meine Agenten sind mein Mac und mein OpenClaw-Server. Ich lasse das OpenClaw-Gateway
00:00:55über Claw Patrol laufen, und auf meinem Mac nutze ich einfach den “run”-Befehl mit Clawd, wann immer ich ihn brauche.
00:01:00Mit diesem Hintergrundwissen schauen wir uns die drei Hauptprobleme an, die Claw Patrol löst, und ich
00:01:04fange tatsächlich mit Nummer zwei an: Dass Agenten keine Geheimnisse sehen sollten, da dies gut zu den
00:01:09anderen Problemen überleitet. Auf dem Claw Patrol-Gateway kannst du deine Anmeldedaten wie Postgres-Benutzer,
00:01:14Clawd-Abonnements, GitHub-Konten sowie Bearer-Token oder benutzerdefinierte Header konfigurieren, so wie ich es hier für meinen
00:01:19Produktions-API-Server getan habe. Wenn wir unsere Agenten dann über das Gateway mit dem Claw Patrol-
00:01:25Befehl “run” ausführen, benötigen sie keine dieser Anmeldedaten, damit die Anfragen funktionieren. Sie werden einfach
00:01:30eingefügt, wenn die Anfrage das Gateway passiert. Wenn ich also Claw bitte, meine API und meine
00:01:35Datenbank zu nutzen, um mir einen Überblick über beides zu verschaffen, kann es das problemlos tun, und ich kann in
00:01:41den Befehlen sehen, die es ausführt, dass keine API-Schlüssel in diesen Curl-Anfragen enthalten sind,
00:01:46obwohl es einen benötigt. Bei Postgres wird nur ein gefälschtes Passwort “X” verwendet, das definitiv nicht das echte
00:01:51Passwort ist, aber die Verbindung steht und die relevanten Informationen werden abgerufen, da das Gateway
00:01:56diese Anfragen abgefangen und die echten Anmeldedaten angehängt hat. Das bedeutet, dass der Agent niemals
00:02:00Zugriff auf die tatsächlichen Werte hat. Wenn also jemand meine Agenten-Protokolle sehen würde oder eine Prompt-Injection versuchte,
00:02:06würde er diese Anmeldedaten niemals erhalten, da sie auf einem völlig separaten Server liegen und der Agent keine
00:02:10Möglichkeit hat, darauf zuzugreifen. Um diesen Injektionsprozess noch deutlicher zu zeigen: Wenn ich diesen Curl-Befehl auf meinem
00:02:15Terminal hier ausführe, siehst du, dass er abgelehnt wird, weil ich keinen API-Schlüssel übergeben habe. Wenn ich jedoch exakt
00:02:20denselben Befehl über “claw patrol run” ausführe, werden die Daten wie gewohnt zurückgegeben, da der API-Schlüssel eingefügt wird.
00:02:26Das nächste Problem, das Claw Patrol lösen will, ist, dass Zugriff keine echte Kontrolle bedeutet. Claw Patrol gibt dir
00:02:31eine sehr feingliedrige Kontrolle darüber, was ein Agent mit einer Anfrage tun darf. Wenn ich zum Beispiel erneut
00:02:36die Postgres-Fähigkeit nutze, diesmal aber verlange, eine Tabelle zu löschen und eine neue zu erstellen, wird dies sofort
00:02:41mit einer benutzerdefinierten Fehlermeldung abgelehnt, die ich eingerichtet habe: Schemaänderungen sind nur via Migrations-
00:02:46PRs erlaubt, nicht durch den Agenten. Das Gateway hat die Postgres-Anfrage meines Agenten überprüft,
00:02:51sie mit einem Regelwerk abgeglichen, das ich definiert habe, und dank einer dieser Regeln das Löschen der Tabelle verweigert.
00:02:56Ein weiterer Ansatz wäre “Human-in-the-loop”, sodass ich diese Regel so einstellen kann, dass sie mich
00:03:00benachrichtigt, um die Aktion zu genehmigen. Momentan unterstützt dies nur Slack, aber weitere Optionen
00:03:04folgen bald. Es gibt sogar eine Option, ein LLM als Prüfer zu verwenden,
00:03:09und die Regeln sind unglaublich anpassbar und flexibel. Du kannst sogar Regeln haben, die deinen
00:03:13Kundensupport-API-Endpunkt prüfen, der Antworten sendet, und dort nach beleidigendem
00:03:18Inhalt, fehlenden Begrüßungen oder allem, was du nicht in einer solchen Anfrage sehen willst, suchen. Und auch hier:
00:03:22Da dies alles bei der Anfrage auf dem Gateway geschieht, ist das theoretisch gegen
00:03:27Prompt-Injections und fast jede andere Art von KI-Angriff geschützt. Das dritte Problem, das Claw Patrol
00:03:31löst, ist die mangelnde Transparenz darüber, was der Agent getan hat. Mit Claw Patrol ist jede Anfrage im
00:03:37Dashboard sichtbar, und du kannst sogar aktive Sitzungen sowie die verwendeten Token sehen. Klickst du
00:03:42in eine Anfrage, siehst du relevante Details wie den Postgres-Befehl, der tatsächlich ausgeführt wurde,
00:03:46oder im Falle eines API-Aufrufs die API-Anfrage sowie die erhaltene Antwort.
00:03:51Auf diese Weise musst du keine Zeit damit verbringen, alle Protokolle der einzelnen Dienste zu durchforsten,
00:03:55die der Agent berührt hat, um herauszufinden, was er getan hat. Stattdessen kannst du einfach sehen, was er
00:03:59zum Zeitpunkt der Anfrage getan hat, sodass du so gut wie alles sehen solltest, was der Agent macht.
00:04:03Das sind die drei Probleme, die Claw Patrol lösen möchte. Aber wie wird das alles eingerichtet? Nun,
00:04:07sobald Claw Patrol installiert ist, wird das Gateway komplett über eine einzige HCL-Datei konfiguriert.
00:04:12Darin definierst du die verschiedenen Endpunkte, für die du Regeln und Anmeldedaten haben wirst,
00:04:16zum Beispiel OpenAI, Slack, SSH, Postgres und so weiter. Wenn also eine Anfrage durch das Gateway geht,
00:04:22die einem dieser Endpunkte entspricht, weiß es, dass es die Regeln und Anmeldedaten prüfen muss.
00:04:26Die Einrichtung der Anmeldedaten selbst ist ebenfalls ziemlich einfach.
00:04:30Du gibst an, um welchen Typ es sich handelt und für welchen Endpunkt diese Anmeldedaten gelten sollen.
00:04:34Es gibt Unterstützung für zahlreiche Typen wie Anthropic-Abonnements, Codex-Token,
00:04:39ClickHouse, Postgres sowie grundlegende Dinge wie Bearer-Token und benutzerdefinierte Header.
00:04:43Du solltest also fast alle benötigten Typen finden,
00:04:46und falls nicht, kannst du sogar Plugins programmieren, um eigene Typen hinzuzufügen.
00:04:50Sobald du Anmeldedaten definiert hast, musst du nur noch im Dashboard den eigentlichen Wert eintragen.
00:04:54Das Einrichten von Regeln ist auch ziemlich einfach.
00:04:56Du gibst einfach den Endpunkt an, für den die Regel gelten soll, und schreibst die Regel
00:05:00mithilfe der Common Expression Language (CEL). Dies kann eine breite Palette abdecken, wie HTTP,
00:05:05Postgres, Kubernetes und so weiter. Danach legst du das Urteil für die Regel fest,
00:05:09also ob sie “genehmigen” (approve) oder “verweigern” (deny) soll. “Approve” würdest du verwenden,
00:05:14wenn du einen Allow-List-Ansatz statt einer Block-List verfolgst; du würdest also standardmäßig alles blockieren
00:05:18und nur bestimmte Dinge erlauben. Ich habe in meinem Fall einfach die Block-List-Methode verwendet.
00:05:22Ein weiteres sehr nützliches Feature sind Profile. Du kannst deine Anmeldedaten
00:05:26in mehreren Profilen gruppieren, was bedeutet, dass alle Regeln und Endpunkte, die mit diesen Anmeldedaten
00:05:31verknüpft sind, ebenfalls zusammengefasst werden. Das ermöglicht dir eine Art rollenbasierte Steuerung für deine
00:05:35Agenten und Teams, sodass Entwickler andere Zugriffsrechte und Regeln für ihre Anmeldedaten
00:05:40haben können als etwa ein Support-Team, das andere Anmeldedaten und Regeln benötigt.
00:05:45Um dich bei Regeländerungen zu unterstützen, gibt es einen Test-Befehl, mit dem du
00:05:49Regelaktionen aus dem Dashboard herunterladen und gegen deine lokalen Regeländerungen erneut ausführen kannst, um zu sehen,
00:05:54ob sich das Ergebnis verändert hat, damit du mögliche versehentliche Datenlecks entdeckst.
00:05:59Ich muss zugeben, dass ich diesen Einrichtungsprozess etwas mühsam fand, und ich bin sicher,
00:06:02dass das bald verbessert wird, da sich das Projekt noch in einem sehr frühen Stadium befindet. Wenn es aber einen einfachen Weg gäbe,
00:06:07Anmeldedaten und Regeln direkt über das Dashboard hinzuzufügen, wäre das absolut genial. Vielleicht etwas Ähnliches wie
00:06:11AdGuard, wo man einfach eine eingehende Anfrage sieht und mit einem Klick eine Regel oder
00:06:15Anmeldedaten für diese Anfrage hinzufügen kann. Ich hatte auch viele Probleme, als ich Endpunkte
00:06:19hinzufügen wollte, die nur IP-Adressen meines lokalen Proxmox-Servers waren. Aus irgendeinem Grund wollte es diese
00:06:24Anfragen einfach nicht abfangen, und ich konnte keine davon im Dashboard sehen, was mir
00:06:28einige Kopfschmerzen bereitete. Es sind also definitiv noch einige Korrekturen nötig, oder vielleicht habe ich es nur falsch benutzt,
00:06:33aber so oder so: Es wird etwas Arbeit erfordern, bis es so benutzerfreundlich ist, dass es
00:06:38deinen Arbeitsfluss nicht mehr unterbricht. Aber das ergibt irgendwie Sinn, da es hier um Sicherheit geht und nicht darum,
00:06:43seinen Agenten einfach im “YOLO-Modus” laufen zu lassen. Lass mich in den Kommentaren wissen, was du von Claw Patrol hältst
00:06:47und welche Sicherheitstools du für deine Agenten verwendest. Wenn du schon dabei bist, abonniere den Kanal und
00:06:51wie immer: Wir sehen uns im nächsten Video.

Key Takeaway

Claw Patrol schützt KI-Agenten vor Sicherheitslücken und unbefugtem Zugriff, indem es ein Gateway zwischen Agent und Internet schaltet, das Anmeldedaten isoliert, Anfragen anhand von CEL-Regeln validiert und alle Aktivitäten zentral protokolliert.

Highlights

  • Claw Patrol ist eine Open-Source-Sicherheits-Firewall für KI-Agenten, die Zugriffsrechte, Geheimnisschutz und Transparenz verwaltet.

  • Das Gateway fungiert als zentraler Kontrollpunkt, der Anmeldedaten wie API-Schlüssel oder Postgres-Passwörter in Anfragen einfügt, ohne dass der Agent diese Daten jemals direkt sieht.

  • Regeln werden mithilfe der Common Expression Language (CEL) definiert, um spezifische Aktionen, wie das Löschen von Datenbanktabellen, präventiv zu blockieren.

  • Jede Anfrage und Sitzung des KI-Agenten wird im Dashboard protokolliert, wodurch das manuelle Durchsuchen einzelner Dienst-Logs entfällt.

  • Die Konfiguration erfolgt zentral über eine einzige HCL-Datei, die Endpunkte wie OpenAI, Slack, SSH oder Postgres abdeckt.

Timeline

Funktionsweise und Sicherheitsarchitektur

  • Claw Patrol fungiert als Gateway zwischen KI-Agenten und dem Internet.
  • Das System unterstützt Anbindungen über Tailscale oder WireGuard.
  • Das Gateway verwaltet Regeln, Protokolle und Anmeldedaten zentral.

Die Architektur besteht aus einem zentralen Gateway-Server und den damit verbundenen Agenten. Nutzer wählen, ob sie einzelne Befehle oder komplette Maschinen über das Gateway führen. Die Integration erfolgt oft über VPN-Lösungen wie Tailscale, um die Netzwerksicherheit zu erhöhen.

Schutz sensibler Anmeldedaten

  • Das Gateway injiziert Anmeldedaten wie API-Schlüssel erst beim Passieren der Anfrageschnittstelle.
  • KI-Agenten erhalten keinen direkten Zugriff auf tatsächliche Anmeldedaten.
  • Sicherheitsrisiken durch Prompt-Injection oder Log-Lecks werden so neutralisiert.

Anmeldedaten wie Postgres-Passwörter oder GitHub-Bearer-Token liegen ausschließlich auf dem Gateway. Ein Agent nutzt im Befehl lediglich Platzhalter; das Gateway ersetzt diese durch die echten Anmeldedaten, bevor die Anfrage den Zielserver erreicht.

Kontrolle und Transparenz für Agenten-Aktionen

  • Regeln auf Basis der Common Expression Language (CEL) ermöglichen eine feingliedrige Kontrolle.
  • Schemaänderungen in Datenbanken lassen sich durch definierte Regelwerke präventiv unterbinden.
  • Das Dashboard bietet Echtzeit-Einblicke in alle Agenten-Anfragen und genutzte Token.

Das Gateway prüft jede Anfrage gegen ein benutzerdefiniertes Regelwerk. Bei Verstößen, etwa dem unerlaubten Löschen von Tabellen, wird die Aktion blockiert. Zusätzlich dient das Dashboard als zentrale Anlaufstelle zur Überwachung, was eine zeitaufwendige Analyse einzelner Dienst-Protokolle überflüssig macht.

Einrichtung und Konfigurationsaufwand

  • Die Konfiguration erfolgt über eine HCL-Datei und ist für diverse Endpunkte erweiterbar.
  • Profile erlauben eine rollenbasierte Steuerung für verschiedene Teams oder Agenten.
  • Die Software befindet sich in einem frühen Stadium und erfordert manuelle Anpassungen.

Die Einrichtung umfasst die Definition von Endpunkten und Anmeldedaten in einer HCL-Datei. Trotz der flexiblen Regelmöglichkeiten und der Unterstützung für eigene Plugins weist der Prozess noch Hürden bei der Benutzerfreundlichkeit und dem Abfangen lokaler IP-Anfragen auf.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video