Custom AI Agent für Burp Suite: MCP-Werkzeuge, lokale Modelle und die Lehren aus 0.9.x

Ein Proxy, der jetzt selbst Werkzeuge anbietet

Burp Suite sammelt HTTP-Verkehr und bietet Prüfwerkzeuge für manuelles Testen. Was fehlte, war eine Brücke zu Modellen und zu externen Agenten, die den Proxy steuern können. Genau diese Brücke baut Custom AI Agent, veröffentlicht unter dem Repository-Namen six2dez/burp-ai-agent. Die Erweiterung registriert sich in Burp als Custom AI Agent, um Verwechslungen mit dem eingebauten Burp-AI-Anbieter zu vermeiden. Der Name ist eine Auflage der BApp-Store-Einreichung, während Repository, Dokumentationsseite und das Konfigurationsverzeichnis ~/.burp-ai-agent/ den alten Bezeichner behalten.

Die Zielgruppe ist eng umrissen. Wer Burp Professional mit eigenen Scans betreibt und zusätzlich einen MCP-fähigen Client wie Claude Desktop oder eine der unterstützten CLIs nutzt, bekommt einen gemeinsamen Werkzeugkasten. Wer nur einen Proxy zum Intercepten braucht, ist hier falsch adressiert. Die Erweiterung ist in Kotlin geschrieben und läuft als JVM-Erweiterung in Community- und Professional-Edition, wobei der passive Scanner als Burp PassiveScanCheck ausdrücklich Professional voraussetzt.

Zwei Builds, zwei Werkzeugmengen

Das Projekt liefert zwei Varianten aus demselben Quellbaum. Der Standardbuild enthält alle 59 MCP-Werkzeuge und wird als GitHub-Release veröffentlicht. Der Store-Build wird mit -PstoreBuild=true gebaut und enthält nur die acht erweiterungseigenen KI-Werkzeuge. Diese Trennung ist keine Kosmetik: Die MCP-Werkzeugmenge bestimmt, was ein externer Agent im Proxy auslösen kann, und die Store-Variante reduziert diesen Umfang bewusst.

Im Repository ist die Einreichung in den BApp Store seit Januar 2026 offen, verwiesen wird auf das Issue 231 im extension-portal. Bis dahin bleibt der Bezug über die Releases oder ein eigener Build der einzige Weg. Für Umgebungen, die Erweiterungen ausschließlich aus dem Store beziehen, ist das ein Ausschlusskriterium, das nichts mit der Funktionsfähigkeit zu tun hat.

MCP als Angriffsfläche: was 1.0.0 geradegerückt hat

Der Sicherheitsteil ist der wichtigste Teil dieser Version. Laut SECURITY.md hat eine externe Prüfung von 0.9.2 am 5. August 2026 zwei ausnutzbare Defekte durch Ausführen des ausgelieferten Codes bestätigt. Beide betreffen jede veröffentlichte 0.9.x-Version, und für keinen der beiden existiert eine CVE- oder GHSA-Kennung. Wer nach einer solchen Kennung sucht, sucht vergeblich.

SEC-04 sitzt in der Zugriffskontrolle. Die Prüfungen liefen nicht auf aufgelösten Routen. Mit aktiviertem externem Zugriff nahm der Listener nicht authentifizierte Werkzeugaufrufe an; im lokalen Modus waren die Prüfungen auf Origin, Host und User-Agent sowie die Sicherheitsantwortheader auf passenden Routen wirkungslos. Die Entscheidung liegt jetzt vor dem Routing. Die zweite Lücke, PRIV-05, betrifft die Redaktion: Session-Cookies erreichten die KI-Backends in den Modi STRICT und BALANCED unredigiert, weil der passive Scanner Cookies als bloßes name=value ausgab und damit die Präfix-Redaktion unterlief, auf die sich die Filterung stützt. Nur ein Cookie mit dem exakten Namen session wurde erfasst. Die Empfehlung im Advisory lautet, den MCP-Token und die betroffenen Cookies zu rotieren. Das ist kein optionaler Schritt nach dem Upgrade, sondern der eigentliche Grund dafür.

Weitere Härtungen betreffen die Werkzeugaufrufe selbst: Ein aus Modellausgabe geparster Aufruf erreicht Burp erst nach einer Entscheidung, und unbekannte Werkzeugnamen werden jedes Mal bestätigt statt still ausgeführt. Der MCP-Token wird bei einer Portübernahme nicht mehr offengelegt; ein lokaler Prozess, der den Port besetzt und den Identitätsheader zurückspiegelt, bekommt stattdessen einen HMAC-Nachweis zu sehen, und unter TLS wird das Serverzertifikat an den eigenen Keystore gebunden. Die Klasse SsrfGuard erkennt abweichende IP-Notationen wie http://2852039166/ und führt bei der Klassifizierung keine Namensauflösung mehr durch. Shell-Argumente werden über eine Allowlist quotiert, womit ein Pfad von einem Einstellungsimport zur Kommandoausführung geschlossen wurde.

Datenfluss: vom Proxy zum Modell und zurück

Der Weg ist in der Beschreibung klar umrissen. Burp erzeugt Anfragen und Scan-Befunde, die Erweiterung reicht sie an eines von zwölf Backends weiter: das eingebaute Burp AI, Anthropic, Ollama, LM Studio, NVIDIA NIM, Perplexity, einen generischen OpenAI-kompatiblen Endpunkt sowie die CLIs Gemini, Claude, Codex, OpenCode und Copilot. Lokale Laufzeiten wie Ollama und LM Studio sind der einzige Weg, auf dem keine Daten den Rechner verlassen. Bei den Cloud-Anbietern und den CLIs entscheidet der jeweilige Anbieter, was mit den übermittelten Inhalten geschieht.

Vor dem Versand greifen die drei Privacy-Modi STRICT, BALANCED und OFF. Wie tief die Redaktion reicht, zeigt der Cookie-Fehler aus 0.9.x: Sie hängt an der Form, in der ein Wert weitergereicht wird. Die Modi sind eine Redaktionsschicht, keine Datenhaltungsgarantie. Wer regulatorische Anforderungen prüft, sollte das nicht als Kontrolle über den Empfänger missverstehen.

In die andere Richtung laufen Werkzeugaufrufe, die das Modell emittiert. Sie werden geparst, gegen die Freigabelogik geprüft und erst dann ausgeführt. Read-only-Werkzeuge mit begrenztem Umfang laufen still, alles andere erzeugt eine Freigabekarte im Chat. Die MCP-Werkzeuge lassen sich optional auf In-Scope-Hosts beschränken, damit ein externer Client keine Ziele außerhalb des Prüfbereichs durch den Proxy erreicht. Diese Einschränkung ist die sinnvollste Voreinstellung für Auftragsarbeit und sollte nicht als Komfortfunktion abgetan werden.

Für Nachvollziehbarkeit schreibt die Erweiterung ein Audit-Log im JSONL-Format mit SHA-256-Integritätshash. Jeder Start wird mit promptSource und contextKind markiert, damit sich später rekonstruieren lässt, woher ein Prompt kam. Zusätzlich gibt es eine Prompt-Bibliothek pro Kontext, also für eine HTTP-Anfrage oder einen Scanner-Befund, aufrufbar über das Kontextmenü oder ad hoc über Custom.

Installation und Konfiguration

Der Bezug läuft über die Releases oder über einen eigenen Build. Für den Build ist Java 21 nötig, JAVA_HOME muss auf das JDK zeigen:

git clone https://github.com/six2dez/burp-ai-agent.git cd burp-ai-agent JAVA_HOME=/path/to/jdk-21 ./gradlew clean shadowJar

Das Ergebnis liegt unter build/libs/Custom-AI-Agent-full-<version>.jar. Für die Store-Variante kommt -PstoreBuild=true hinzu, das Ergebnis heißt dann build/libs/Custom-AI-Agent-<version>.jar. In Burp folgt der übliche Weg: Extensions > Installed > Add, als Erweiterungstyp Java wählen und die JAR-Datei auswählen.

Beim ersten Start legt die Erweiterung die mitgelieferten Profile unter ~/.burp-ai-agent/AGENTS/ ab. Eigene Profile sind zusätzliche *.md-Dateien in diesem Verzeichnis. Die Konfiguration selbst liegt im selben Verzeichnis, was für Skripting und Backups praktisch ist, aber auch bedeutet, dass dort Zugangsdaten für die Backends landen können. Die Rechte auf diesem Pfad sind Teil der Angriffsfläche, nicht nur eine Frage der Ordnung.

Für den MCP-Betrieb ist der Token das zentrale Geheimnis. Nach der Aktualisierung auf 1.0.0 gehört er rotiert, und die Cookies, die in den Modi STRICT oder BALANCED durchgelaufen sind, gehören ebenfalls ersetzt. Wer den externen Zugriff nie eingeschaltet hat, ist von SEC-04 weniger betroffen, sollte aber die Cookie-Rotation trotzdem prüfen.

Wo die Erweiterung das falsche Werkzeug ist

Der passive Scanner setzt Burp Professional voraus. In der Community-Edition bleibt nur der manuelle Teil, und damit fällt ein beworbener Kern weg. Das ist keine Kleinigkeit, sondern eine harte Grenze für alle, die mit der kostenlosen Edition arbeiten.

Die zweite Einschränkung liegt im Modell selbst. Ein Modell, das Werkzeugaufrufe ausgibt, ist eine zusätzliche Entscheidungsebene zwischen Prüfer und Proxy. Die Freigabekarten fangen unbekannte Werkzeugnamen ab, aber sie ersetzen keine Prüfung des Vorschlags. Wer die Bestätigung aus Gewohnheit durchklickt, hat die Kontrolle nur formal.

Die dritte Grenze betrifft den Anwendungsfall. Für reproduzierbare, automatisierte Scans in einer Pipeline ist ein Proxy mit KI-Zwischenschicht der falsche Ort. Die Ergebnisse hängen vom Modell, vom Prompt und vom Backend ab, und die Audit-Markierungen promptSource und contextKind machen das nachvollziehbar, nicht deterministisch. Wer stabile Befunde braucht, ist mit einem klassischen Scanner besser bedient. Und wer Modelle grundsätzlich nicht in den Prüfpfad lassen will, findet hier keine Variante, die das umgeht.

Alternative mit anderem Ansatz

Der naheliegende Vergleich ist die eingebaute Burp-AI-Funktion, die im README ausdrücklich als eigener Anbieter genannt wird und als eines der zwölf Backends angebunden ist. Der Unterschied liegt in der Reichweite: Burp AI bleibt innerhalb von Burp, während Custom AI Agent einen MCP-Server bereitstellt, über den ein externer Client den Proxy fernsteuert. Wer nur gelegentlich eine Anfrage zusammenfassen lassen will, braucht die 59 Werkzeuge nicht und handelt sich mit einem offenen Listener mehr Fläche ein als mit der eingebauten Funktion.

Ein zweiter Vergleichspunkt ist der Weg über eine der CLI-Backends, etwa Claude Code oder Gemini CLI, direkt auf Dateien und Verkehrsdaten. Dort fehlt die Proxy-Integration: Kein Repeater, keine Scan-Befunde, keine In-Scope-Beschränkung. Die Erweiterung gewinnt, sobald der Agent gegen echten Proxy-Zustand arbeiten soll, und verliert, sobald es nur um Textanalyse geht.

Wartung, Lizenz und was vor dem Rollout zu prüfen ist

Die Lizenz ist MIT, was Weitergabe und Änderung erlaubt. Wer die Erweiterung in ein eigenes Produkt einbettet, muss die MIT-Bedingungen einhalten, also Copyright-Hinweis und Lizenztext beilegen. Das ist eine Einordnung, keine Rechtsberatung, und die endgültige Prüfung gehört zu den eigenen Compliance-Prozessen. Ein Punkt, der leicht übersehen wird: Die Lizenz der Erweiterung sagt nichts über die Nutzungsbedingungen der angebundenen Modellanbieter aus, und die sind je Backend verschieden.

Der Wartungsaufwand hängt an der Backend-Liste. Zwölf Anbieter und fünf CLI-Integrationen bedeuten, dass sich Schnittstellen ändern können, ohne dass die Erweiterung etwas dafür kann. Die Versionshistorie zeigt außerdem ein Muster: 0.9.1 und 0.9.2 erschienen am selben Tag, 1.0.0 folgte knapp einen Monat später. Wer früh übernimmt, übernimmt auch die Fehlerkorrektur.

Der Testaufwand ist im Projekt selbst dokumentiert: Die Suite wuchs von 660 auf 1131 Tests in 158 Klassen, die Zeilenabdeckung von 34 auf 58 Prozent, und die detekt-Baseline schrumpfte von 1096 auf 1040 statt zu wachsen. 58 Prozent Abdeckung heißt, dass ein erheblicher Teil des Codes nicht durch Tests abgesichert ist. Für eine Erweiterung, die Zugriffskontrolle und Redaktion implementiert, ist das ein Wert, den man kennen sollte, bevor man sie in einen Kundenauftrag einbindet.

Vor dem Rollout sind drei Dinge konkret zu klären: ob die Zielumgebung Burp Professional mitbringt, weil sonst der passive Scanner entfällt; ob der Auftrag die Übermittlung von Verkehrsdaten an das gewählte Backend erlaubt, wobei nur lokale Laufzeiten wie Ollama und LM Studio den Rechner nicht verlassen; und ob der MCP-Zugriff überhaupt gebraucht wird, denn ohne ihn lässt sich die Angriffsfläche erheblich verkleinern. Wer den externen Zugriff aktiviert, sollte die In-Scope-Beschränkung setzen und nicht darauf verzichten.

Redaktionelles Fazit

Wer die Erweiterung produktiv einsetzt, sollte zuerst auf 1.0.0 wechseln und dabei MCP-Token sowie betroffene Session-Cookies rotieren; das gilt auch für Installationen, die den externen MCP-Zugriff nie aktiviert haben, weil der Token laut Advisory bereits offengelegt sein kann. Wer Burp nur als Proxy für manuelles Testen nutzt und keine externen KI-Clients anbinden will, gewinnt wenig und trägt zusätzliche Angriffsfläche in den Proxy. Vor dem Einsatz im Kundenauftrag ist zu klären, ob der Auftrag Modellausgaben an Cloud-Anbieter überhaupt zulässt, denn die drei Privacy-Modi redigieren, sie verhindern den Versand nicht.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. six2dez/burp-ai-agent on GitHub