Pipelock: Agenten-Firewall mit signierten Aktionsbelegen für MCP und Egress
luckyPipewrench/pipelock bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Pipelock aus Go sitzt zwischen KI-Agent und Netzwerk, scannt vermittelten HTTP-, WebSocket-, MCP- und A2A-Verkehr auf Exfiltration, SSRF und Prompt-Injection und schreibt vom Vermittler signierte Belege, die offline prüfbar sind.
- Für wen ist es gedacht?
- Pipelock passt zu Teams, die Agenten wie Claude Code oder OpenAI Codex mit Netzwerkzugriff betreiben und nachvollziehbare Grenzentscheidungen brauchen; wer nur eine Web-Filterliste sucht, braucht eine Agenten-Firewall nicht. Vor dem Ernstfall lohnt der Lauf von pipelock demo, der sieben signierte Belege plus signer.pub schreibt, deren Signaturen sich mit pipelock verify-receipt selbst prüfen lassen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Die Grenze zwischen Agentengeheimnissen und dem offenen Netz
Pipelock (luckyPipewrench/pipelock) ist eine Open-Source-Agenten-Firewall in Go für das, was das Projekt Verifiable Egress Control nennt. Die Ausgangslage im README: Ein Agent hat eine Provider-API-Schlüssel in seiner Umgebung und Shell-Zugriff, ein einziger curl-Aufruf an eine Angreifer-Domain genügt, um den Schlüssel abzugreifen. Pipelock wird zur Grenze, indem der Agent durch seinen Proxy, MCP-Wrapper, Sandbox- oder Cluster-Pfad geroutet wird. Gescannt wird vermittelter HTTP-, WebSocket-, MCP- und A2A-Verkehr auf Geheimnis-Exfiltration, Prompt-Injection, SSRF, Tool-Poisoning und riskante Tool-Aufrufketten; bei aktivierter TLS-Interception auch CONNECT-Tunnelinhalte, einfaches CONNECT auf Hostname- und URL-Ebene. Als Integrationziele nennt das README Claude Code, OpenAI Codex, Cline, OpenCode, Zed, Cursor, VS Code, JetBrains, das OpenAI Agents SDK, Google ADK, AutoGen, CrewAI und LangGraph. Metadaten: Apache-2.0, 821 Sterne, Release v3.4.0 vom 20. August 2026, Projektseite pipelab.org.
Fähigkeitstrennung und drei Proxy-Modi auf einem Port
Das Architekturprinzip ist Fähigkeitstrennung: In einer erzwungenen Bereitstellung trägt der Agentenprozess die Geheimnisse, hat aber keinen direkten Netzwerkzugriff, während Pipelock Netzwerkzugriff hat, aber keine Agentengeheimnisse sieht. Die Firewall bedient auf demselben Port drei HTTP-Proxy-Modi: einen Fetch-Proxy, der Inhalte extrahiert und nach dem Injection-Scan sauber zurückgibt, einen Forward-Proxy für reguläres CONNECT-Tunneling, der mit Standard-HTTPS_PROXY-Variablen arbeitet, und einen WebSocket-Proxy für bidirektionales Frame-Scannen. Ein dedizierter MCP-Proxy umschließt stdio- oder HTTP-Server, die A2A-Inspektion läuft auf Forward- und MCP-Pfaden. Das Textdiagramm im README zeigt drei Zonen: privilegierte Zone für den Agenten, Firewall-Zone mit Pipelock und Internet. Damit bleibt der Grenzpunkt ein einzelner, prüfbarer Ort, an dem jede Maschinenaktion vorbeiführt, bevor sie das Haus verlässt.
DLP mit 65 Mustern und DNS-vor-Auflösung-Scannen
Die Erkennungspipeline reicht von einem geordneten URL-Scanner mit Allowlist- und Blocklist-Richtlinie über DLP mit 65 eingebauten Mustern für API-Schlüssel und Zugangsdaten bis zum Antwort-Scan mit 33 Prompt-Injection-Mustern und Sechs-Pass-Normalisierung. Streaming-SSE-Inhalte, Anfragetexte und kanarische Kanarien-Token sind abgedeckt; Adressschutz blockiert Zugriffe auf interne Zielbereiche. Ein praktisch relevantes Detail: DLP läuft vor der DNS-Auflösung, sodass ein Geheimnis erkannt wird, bevor eine DNS-Abfrage den Proxy überhaupt verlässt. Die Anforderungs-Redaktion schreibt JSON so um, dass übereinstimmende Geheimniswerte durch typisierte Marker ersetzt werden, und Belege zeichnen Zählungen statt Klartext-Schlüsseln auf. Für Nachvollziehbarkeit gibt es pipelock explain, das Befunde erklärt, und pipelock skill-scan, das Skill-Dateien inventarisiert. Der README-Einstieg testet das Verhalten direkt: pipelock check --url auf eine Beispiel-AWS-Zugriffs-ID wird blockiert, ein Aufruf von docs.python.org wird durchgelassen.
MCP-Umschließung mit Tool-Richtlinie und Integritätsmanifesten
Für MCP umschließt Pipelock Server bidirektional: Client-Anfragen werden auf DLP-Lecks und Injection geprüft, Serverantworten gescannt, bevor der Agent sie sieht, und Tool-Poisoning wird in tools/list-Beschreibungen erkannt. Eine Tool-Richtlinie bringt 17 eingebaute Regeln plus 10 Muster für riskante Tool-Aufrufketten mit. Authentifizierte MCP-HTTP-Listener schlagen standardmäßig für Nicht-Loopback-Adressen fehl, was versehentliche Netzwerkexposition verhindert. Mit pipelock mcp proxy lässt sich ein lokaler Server umschließen oder zu einem entfernten Streamable-HTTP-Server brücken. MCP-Integritätsmanifeste fixieren Server-Binärdateien per Hash, und über pipelock init sidecar entsteht ein Kubernetes-Sidecar-Startvertrag. Damit deckt das Projekt sowohl die lokale Einzelwerkbank als auch Cluster-Bereitstellungen ab, ohne dass die Grenzlogik auseinanderläuft.
Signierte Belege statt grüner Häkchen im Dashboard
Der auffälligste Anspruch von Pipelock ist Beweis statt Vertrauen: Jede Grenzentscheidung wird als vom Vermittler signierter Aktionsbelege ausgegeben, mit Urteil, Policy-Hash, Transport und Scanner-Ebene. Das eingebaute Demo feuert echte Angriffsszenarien ohne Konfiguration und Netzwerk ab, blockiert sie und schreibt sieben signierte Belege plus signer.pub auf die Platte; mit pipelock verify-receipt prüft man eine Signatur offline selbst, ohne Konto und Server. Der kostenlose Evidence-Viewer liest eine Flugschreiber-Sitzung, die Pipelock im Betrieb schreibt, und erzeugt mit pipelock evidence view einen statischen Offline-Report oder serviert ihn über evidence serve schreibgeschützt. Der Flugschreiber schreibt hash-verkettete JSONL-Beweise mit Ed25519-signierten Checkpoints. Das README benennt seine Grenzen ehrlich: Das Demo signiert mit einem flüchtigen Schlüssel und beweist nur Selbstkonsistenz, und da der Betreiber den Signaturschlüssel hält, belegt ein Beleg die Entscheidung der Grenze, nicht die Ehrlichkeit des Betreibers. pipelock anchor receipts verankert Receipt-Chain-Checkpoints in einem lokalen Backend oder einem Rekor-Transparenzlog, wobei die operator-unabhängige Prüfung dagegen laut README noch Ende-zu-Ende bewiesen wird.
Modi strict, balanced und audit mit der Voreinstellung hostile-model
Pipelock läuft in drei Modi: strict blockiert ausgehenden HTTP-Verkehr außer erlaubter API-Domains, balanced blockiert naive Angriffe und erkennt raffinierte, audit protokolliert nur. Eine Vergleichstabelle im README zeigt das Verhalten je Modus bei Szenarien wie curl-Exfiltration, base64-kodierten Geheimnissen, DNS-Tunneling und Chunked-Exfiltration. Über pipelock generate config stehen Voreinstellungen namens balanced, strict, audit und hostile-model bereit; hostile-model schaltet aggressive Entropieschwellen und pauschales Netzwerk-Tool-Blocking für ungefilterte oder unzensierte Modelle hinzu. Das macht die Wahl nach Bedrohungsmodell statt nach Geschmack: Wer Modelle mit entzogenen Sicherungen einsetzt, fährt strenger als ein Team, das vor allem versehentliche Lecks abdecken will. Installation läuft über go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest mit Go 1.25 oder höher, binär über GitHub Releases, als Container über ghcr.io/luckypipewrench/pipelock oder auf macOS über brew install luckyPipewrench/tap/pipelock.
Apache-2.0-Kern, Pro-Stufen und Release-Integrität
Der Kern steht unter Apache-2.0; laut README bleiben alle Erkennung, Durchsetzung, Containment und Einzelagenten-Beweise dauerhaft kostenlos, während Pro Multi-Agenten-Koordination und Enterprise Flottenverwaltung und Compliance hinzufügen. Vorgefertigte Release-Artefakte enthalten den kostenpflichtigen Code, der erst mit einem Lizenzschlüssel aktiviert wird, während Quellcode-Builds über go install ein Community-only-Binärprogramm erzeugen. Für Release-Integrität dokumentiert das README die Prüfung über gh attestation verify gegen den Eigentümer luckyPipewrench. Öffentliche Qualitätssignale sind der Scorecard-Viewer, ein Best-Practices-Eintrag, Codecov und drei CI-Workflows inklusive eines continuous-gauntlet, der geplante Kandidatenprüfungen gegen einen fixierten Korpus-Commit fährt, ohne öffentliche Punkte automatisch zu veröffentlichen. Das öffentliche agent-egress-bench-Korpus macht die Erkennungen von außen nachprüfbar, und ein Live-Playground auf pipelab.org erlaubt einen ersten Eindruck ohne lokale Installation.
Redaktionelles Fazit
Pipelock passt zu Teams, die Agenten wie Claude Code oder OpenAI Codex mit Netzwerkzugriff betreiben und nachvollziehbare Grenzentscheidungen brauchen; wer nur eine Web-Filterliste sucht, braucht eine Agenten-Firewall nicht. Vor dem Ernstfall lohnt der Lauf von pipelock demo, der sieben signierte Belege plus signer.pub schreibt, deren Signaturen sich mit pipelock verify-receipt selbst prüfen lassen.
Community-Notizen