Claude Code for Pentesting vs. Penligent, wo ein Coding Agent aufhört und ein Pentest-Workflow anfängt

Viele Verwirrungen im Zusammenhang mit KI-Pentesting beginnen mit einer falschen Abkürzung. Die Leute sehen, wie ein Kodierungsagent Dateien liest, Befehle ausführt, Tools aufruft und plausible Sicherheitsüberlegungen anstellt, und nennen ihn dann gleich einen KI-Pentester. Diese Abkürzung bricht in dem Moment zusammen, in dem die Arbeit außerhalb der Demo überleben muss. Die Dokumentation von Anthropic beschreibt Claude Code als ein agentenbasiertes Kodierungswerkzeug, das Codebasen liest, Dateien bearbeitet, Befehle ausführt und sich mit Entwicklungswerkzeugen über Terminal-, IDE-, Desktop- und Browseroberflächen integriert. Anthropics Kompetenzmodell fügt spezialisierte Anweisungen hinzu durch SKILL.md, während Subagenten aufgabenspezifische Kontexte, Werkzeuge und Berechtigungen hinzufügen. Die öffentlich zugänglichen Produktunterlagen von Penligent betonen dagegen einen anderen Schwerpunkt: mehr als 200 unterstützte Tools, CVE-Scans auf dem neuesten Stand, PoC-Generierung mit einem Klick, Signal-to-Proof-Ausführung, rückverfolgbare Artefakte, Scope Locking und editierbare Berichte, die mit SOC 2 und ISO 27001 übereinstimmen. Das ist nicht dieselbe Produktkategorie, auch wenn beide Agenten verwenden und beide an offensiven Workflows teilnehmen können. (Claude)

Diese Unterscheidung ist wichtig, weil Sicherheitsarbeit nicht danach beurteilt wird, wie beeindruckend die Argumentation in der Mitte aussieht. Sie wird danach beurteilt, ob das Ergebnis gültig, reproduzierbar, innerhalb des Geltungsbereichs und für jemand anderen nützlich ist. Ein Kodierungsagent kann bei repo-lokalen Schlussfolgerungen brillant sein und trotzdem eine schwache Beweiskette hinterlassen. Ein vertikaler Pentest-Workflow kann weniger flexibel sein als ein Coding Agent und dennoch viel nützlicher für ein echtes Team sein, wenn er konsequent Signale in verifizierte Auswirkungen und verifizierte Auswirkungen in etwas umwandelt, auf das Technik und Compliance reagieren können. Die richtige Frage ist nicht, ob Claude Code für Pentesting verwendet werden kann. Das kann er. Die richtige Frage ist, wo das Coding-Agent-Modell endet und wo das Pentest-Workflow-Modell beginnt und warum diese Grenze die Art und Weise ändert, wie gute Teams ihren Stack aufbauen, kaufen und bewerten sollten. (Claude)

Die Forschung zu LLM-gesteuerten Pentest-Agenten hat begonnen, diese Intuition mit Zahlen zu untermauern. Eine kürzlich durchgeführte 2026-Studie, in der 28 LLM-basierte Penetrationstestsysteme analysiert wurden, ergab, dass viele Fehler nicht verschwinden, nur weil man mehr Werkzeuge oder ein besseres Modell hinzufügt. Die Autoren unterteilten die Fehler in überschaubare technische Lücken und tiefer gehende Planungs- und Zustandsverwaltungsprobleme. Sie zeigten, dass Agenten sich immer noch zu sehr auf Zweige mit geringem Wert konzentrieren, Aufgaben mit langem Zeithorizont falsch handhaben und den Kontext ausschöpfen, bevor sie die Kette beenden. Eine separate Live-Evaluierung in Unternehmen ergab, dass KI-Agenten bei der systematischen Aufzählung, der parallelen Nutzung und der Kosteneffizienz stark sein können, aber dennoch höhere Falsch-Positiv-Raten und eine schwächere Leistung bei GUI-lastigen Aufgaben aufweisen als starke menschliche Fachleute. Diese Ergebnisse weisen auf dieselbe Schlussfolgerung hin: Die Schwierigkeit besteht nicht mehr nur darin, ob das Modell den nächsten Schritt generieren kann. Der schwierige Teil ist, ob das System um das Modell herum die Richtung, die Evidenz und die Kontrolle beibehält. (arXiv)

Claude Code für Pentesting beginnt mit dem richtigen mentalen Modell

Claude Code ist am leichtesten misszuverstehen, wenn man ihn als Chatbot mit Shell-Zugang betrachtet. Die Produktbeschreibung von Anthropic ist da schon etwas genauer. Es handelt sich um eine agentenbasierte Codierungsumgebung, die eine Codebasis lesen, Dateien bearbeiten, Befehle ausführen und sich in Tools integrieren kann. In der Praxis bedeutet dies, dass es sich weniger um einen Sicherheitsscanner als vielmehr um einen programmierbaren Arbeitsbereich für technische Benutzer handelt. Es ist so konzipiert, dass es sich auf der gleichen Oberfläche befindet, auf der Ingenieure bereits arbeiten: das Repo, die Shell, der Editor, der mit dem Browser verbundene Workflow und die Toolchain um sie herum. Das ist genau der Grund, warum es für Sicherheitsforscher so interessant sein kann. Viele offensive und defensive Aufgaben beginnen mit lokalem Verständnis: Verfolgung der Authentifizierungslogik, Kartierung von Vertrauensgrenzen, Überprüfung von Änderungen, Wiederholung von Test-Harnessen, Überprüfung von Build-Skripten oder Instrumentierung kleiner Validierungsschleifen innerhalb eines echten Projekts. (Claude)

In der offiziellen Dokumentation von Claude Code wird dieses Modell noch deutlicher, wenn man sich ansieht, wie die Ausführung geregelt ist. Standardmäßig verwendet Claude Code strikte Nur-Lese-Berechtigungen. Wenn er mehr als nur lesen darf, z. B. Dateien bearbeiten, Tests ausführen oder Befehle ausführen, bittet er um ausdrückliche Genehmigung. Anthropic dokumentiert auch Sandboxing als separate Verteidigungsschicht: Berechtigungen entscheiden, welche Tools und Ressourcen Claude verwenden darf, während Sandboxing die Grenzen des Dateisystems und des Netzwerks des Bash-Tools auf Betriebssystemebene durchsetzt. Mit anderen Worten: Anthropic präsentiert Claude Code nicht als frei umherziehenden, autonomen Hacker. Es handelt sich vielmehr um eine agentechnische Umgebung, die je nach Konfiguration durch den Betreiber und das Unternehmen mehr oder weniger Befugnisse erhalten kann. Diese Unterscheidung ist wichtig, denn "Claude Code for pentesting" ist nur dann sinnvoll, wenn man das Berechtigungsmodell versteht, unter dem es tatsächlich läuft. (Claude)

Wichtig ist auch, dass Claude Code über Zustands- und Spezialisierungsprimitive verfügt, die über eine einzelne Konversation hinausgehen. Anthropic dokumentiert zwei Speicherkanäle, CLAUDE.md und Autospeicher, die beide zu Beginn jeder Konversation geladen werden, mit der ausdrücklichen Warnung, dass Claude sie als Kontext und nicht als harte Durchsetzung behandelt. Anthropic dokumentiert auch Subagenten als separate Assistenten, die in ihren eigenen Kontextfenstern mit ihren eigenen Eingabeaufforderungen, Werkzeugzugriff und Berechtigungen laufen. Hooks können benutzerdefinierte Shell-Befehle, HTTP-Endpunkte oder LLM-Eingabeaufforderungen zu bestimmten Lebenszykluspunkten ausführen. Skills erweitern das Verhalten durch Markdown-Anleitungspakete. MCP ist nach Anthropic ein offener Standard für die Verbindung von KI-Anwendungen mit externen Systemen und Tools. Wenn man diese Teile zusammenfügt, erhält man etwas Mächtiges: kein festes Pentest-Produkt, sondern eine tiefgreifend erweiterbare Werkbank für den Aufbau einmaliger oder teilweise wiederverwendbarer Sicherheits-Workflows rund um Code, Tools und Kontext. (Claude API-Dokumente)

Das ist genau der Grund, warum Claude Code sich so stark in der White-Box- und Repo-bewussten Sicherheitsarbeit fühlt. Wenn Sie bereits Zugriff auf den Quellcode, vorhandene Skripte, CI-Artefakte oder bekannte Werkzeuge haben, kann Claude Code die Schleife zwischen "Ich glaube, hier stimmt etwas nicht" und "Ich habe eine Hypothese, einen Patch-Kandidaten und einen gezielten Validierungsschritt" verkürzen. Claude Code ist gut darin, mühsame Kontexterstellung zusammenzufassen: wo wird auth erzwungen, wo werden benutzergesteuerte Felder normalisiert, welcher Codepfad regelt das Schreiben von Dateien, was hat sich zwischen zwei Commits geändert, was bedeutet diese Semgrep-Ausgabe, welche Konfigurationsabweichung ist in diesem Zweig aufgetreten, warum schlägt das Test-Harness nur im Staging fehl. Das ist nicht theoretisch. Es ist genau die Art von Multi-Datei, Multi-Tool, Multi-Ausgabe Arbeit Anthropic's eigenen docs Position Claude Code zu tun. (Claude)

Die Form dieser Stärke wird in einem praktischen Vergleich leichter erkennbar.

Die Tabelle sieht einleuchtend aus, wenn man sie laut ausspricht, aber genau hier gehen viele Vergleiche schief. Claude Code ist dort am stärksten, wo die Wahrheit bereits nahe am Repo, nahe am Terminal oder nahe an der lokalen Toolchain des Anwenders liegt. Er kann sehr gut entscheiden, was als Nächstes untersucht werden soll, welches Experiment durchgeführt und welcher Patch ausprobiert werden soll. Das ist ein echter Vorteil und kein Trostpreis. Die gleiche Tabelle zeigt aber auch die Grenzen auf: Der Output eines Kodierungsagenten ist nicht automatisch ein Artefakt der Pentestklasse. Es besteht immer noch ein Unterschied zwischen "kluger nächster Schritt" und "gültiges Ergebnis, das man ausliefern kann." (Sträflich)

Was Claude Code pentest Fähigkeiten tatsächlich hinzufügen

Das Wort "Fertigkeiten" stiftet mehr Verwirrung als es sollte, weil die Leute oft viel mehr darauf projizieren, als Anthropic es tut. Die Dokumentation von Anthropic ist einfach: Fertigkeiten erweitern das, was Claude tun kann, indem sie Anweisungen durch SKILL.mdund Claude kann sie bei Bedarf automatisch laden oder durch einen Slash-Befehl aufrufen. Das ist mächtig, aber es ist keine Magie. Eine Fähigkeit kann Methodik, Struktur, Leitplanken, Fachwissen, bevorzugte Werkzeugverwendung oder Ausgabeformatierung kodieren. Was er allein nicht kann, ist die Vertrauenswürdigkeit der zugrundeliegenden Umgebung verändern, eine Durchsetzung auf Betriebssystemebene schaffen oder spekulative Überlegungen in verifizierte Auswirkungen umwandeln. Eine Pentest-Fähigkeit kann Claude dazu bringen, sich mehr wie ein disziplinierter Sicherheitsanalytiker zu verhalten. Sie verwandelt Claude Code nicht von selbst in ein validiertes Pentest-Betriebsmodell. (Claude API-Dokumente)

Öffentliche, auf Sicherheit ausgerichtete Skill-Ökosysteme spiegeln diese Realität bereits wider. Der öffentliche Skills Marketplace von Trail of Bits für Claude Code enthält Plugins für die statische Analyse, das Parsen von Burp-Suite-Projekten, die Prüfung von Risiken in der Lieferkette, die Erstellung von Semgrep-Regeln, die Erstellung von YARA, die Verifizierung von False Positives und andere Sicherheits-Workflows. Dies ist ein deutlicher Beweis dafür, dass das Ökosystem Fähigkeiten als wiederverwendbare Workflow- und Analysekomponenten und nicht als selbstauthentifizierende Exploit-Engines sieht. Das Trail of Bits-Repository selbst beschreibt den Marktplatz als eine Sammlung von Fähigkeiten für KI-gestützte Sicherheitsanalysen, Tests und Entwicklungs-Workflows. Diese Formulierung ist wichtig. "KI-gestützte Sicherheitsanalyse" ist ein viel präziseres Versprechen als "autonome Pentest-Plattform", und es entspricht dem, wie starke Teams über Fähigkeiten denken sollten. (GitHub)

Ein guter Pentest-Skill sieht daher weniger wie ein Exploit-Pack aus, sondern eher wie ein disziplinierter Methoden-Wrapper. Die wertvollsten Fähigkeiten teilen dem Agenten nicht nur mit, welche Werkzeuge existieren. Sie zwingen ihn, bessere Fragen zu stellen, bevor er handelt, und sie zwingen ihn, bessere Beweise aufzuzeichnen, bevor er abschließt.

---
Name: pentest-evidence-check
beschreibung: Erfordert einen Beweis, bevor ein Befund als ausnutzbar bezeichnet wird.
---

Bei der Analyse eines Sicherheitsproblems sollte man es nicht als verifiziert bezeichnen, wenn nicht alle der folgenden Punkte erfüllt sind:

1. Eine Kontrollanforderung oder ein Basisverhalten
2. Eine Testanforderung oder eine geänderte Eingabe
3. Eine beobachtbare Auswirkung in Verbindung mit der Anforderung
4. Vorbedingungen wie Rolle, Sitzung, Merkmalskennzeichen oder Konfiguration
5. Hinweise zum erneuten Test, die erklären, wie die Behauptung nach einer Korrektur erneut validiert werden sollte

Wenn ein Element fehlt, beschreiben Sie das Ergebnis als Hypothese, nicht als bestätigtes Ergebnis.

Diese Art von Kompetenz ist nützlich, weil sie den Qualitätsmaßstab des Gesprächs verändert. Sie verringert die Kluft zwischen "das Modell hält dies für wahrscheinlich" und "ein Prüfer kann beurteilen, ob die Behauptung Vertrauen verdient". Es macht auch etwas deutlich, was Sicherheitsteams in KI-Diskussionen oft vergessen: Der wichtigste Wert einer Fähigkeit ist häufig nicht mehr Autonomie, sondern eine bessere Beherrschung. Die Anthropic-Dokumente unterstützen diese Interpretation indirekt durch den Rest des Claude-Code-Modells. Fertigkeiten sind nur eine Ebene. Berechtigungen, Sandboxing und Operator-Reviews befinden sich noch darunter. Wenn Sie eine leistungsstarke Pentest-Fähigkeit mit einer schlampigen Genehmigungspolitik verbinden, erhalten Sie kein sichereres Pentest-System. Sie erhalten einen leistungsfähigeren Agenten in einer schwach regulierten Umgebung. (Claude API-Dokumente)

Das gleiche Prinzip gilt, wenn Skills mit Hooks, MCP-Servern oder lokalen Sicherheitstools gepaart werden. Ein Pentest-Skill kann sagen: "Verwende zuerst Burp-Daten", "Triage von Semgrep-Ergebnissen vor der Ausführung von Tests" oder "Lehne Behauptungen ohne unabhängige Beweise ab", aber das Verhalten in der realen Welt hängt immer noch davon ab, welche Tools Claude aufrufen kann, welche Domänen sie erreichen kann, welche Dateien sie schreiben kann und welche Lebenszyklusaktionen Ihre Hooks auslösen. Das Hooks-Modell von Anthropic ist gerade deshalb so leistungsfähig, weil es Shell-Befehle, HTTP-Endpunkte und sogar LLM-Prompts bei verschiedenen Lebenszyklusereignissen automatisieren kann. Das eröffnet eine Menge Raum für gute Sicherheitstechnik. Es bedeutet auch, dass ein reiner Vergleich der Fähigkeiten zu oberflächlich ist. Wenn die Leute sagen "Claude Code plus Pentest-Fähigkeiten", lautet die ernsthafte Version dieses Satzes eigentlich "Claude Code plus Fähigkeiten plus Berechtigungen plus Sandboxing plus Hooks plus Toolchain-Hygiene plus Validierungsdisziplin." (Claude API-Dokumente)

Warum Claude Code in der White-Box-Sicherheitsarbeit wirklich stark ist

Wenn das mentale Modell stimmt, lassen sich die stärksten Sicherheitsanwendungen von Claude Code viel leichter beschreiben. Es zeichnet sich aus, wenn das Zielproblem tief mit der Codebasis selbst verwoben ist. Stellen Sie sich ein Repo vor, bei dem das schwierige Problem nicht nur darin besteht, ein verdächtiges Muster zu finden, sondern zu verstehen, was Rollenprüfungen tun sollen, wie ein Deserialisierer drei Schichten tiefer verwendet wird, ob diese Protokollierungssenke jemals von Angreifern kontrollierte Inhalte erhält oder wie ein Pipelineschritt Geheimnisse preisgeben könnte, wenn er unter einem falsch zugewiesenen Token ausgeführt wird. Das sind keine Brute-Force-Erkennungsprobleme. Es sind Interpretationsprobleme, die Code, Konfiguration, Verlauf und Ausführungskontext betreffen. Claude Code eignet sich sehr gut für diese Art von Arbeit, da seine ursprüngliche Oberfläche die Codebasis und die ihr nahestehenden Artefakte sind. (Claude)

Subagenten machen das für die Sicherheitsüberprüfung besonders interessant. Anthropic dokumentiert, dass jeder Subagent sein eigenes Kontextfenster, seine eigene Eingabeaufforderung und seinen eigenen Werkzeugzugriff und seine eigenen Berechtigungen erhält. Das bedeutet, dass Sie lärmende Erkundungsarbeiten von der entscheidenden Implementierungsarbeit trennen können. Ein Code-Reviewing-Subagent kann schreibgeschützt bleiben. Einem reproduktionsorientierten Subagenten kann erlaubt werden, begrenzte Befehle auszuführen. Ein Forschungs-Subagent kann einen unbekannten Auth-Flow zusammenfassen, ohne die Hauptsitzung mit jeder dazwischenliegenden Sackgasse zu überfluten. Das hört sich nach einer Produktivitätsfunktion an, aber in der Sicherheitsarbeit ist es auch eine Zuverlässigkeitsfunktion. Eine der häufigsten Fehlerarten bei KI-lastigen Überprüfungen ist die Kontamination des Kontexts: Ein Agent trägt zu viele veraltete Details, zu viele unvollständige Vermutungen oder zu viele irrelevante Toolausgaben in spätere Schritte. Unteragenten sind kein Allheilmittel, aber sie sind eine sinnvolle Kontrolle für dieses Problem. (Claude API-Dokumente)

Das Gedächtnis ist aus demselben Grund wichtig. Die Dokumentation von Anthropic über CLAUDE.md und Auto-Memory macht deutlich, dass Claude Code Projektanweisungen und entdeckte Muster sitzungsübergreifend übernehmen kann, auch wenn diese Erinnerungen eher kontextbezogen als nach festen Richtlinien erfolgen. Für die Sicherheitsarbeit kann das nützlicher sein, als es klingt. Eine ausgereifte Codebasis hat oft wiederkehrende Fakten, die für die Modellierung von Bedrohungen von Bedeutung sind: wo sich privilegierte Middleware befindet, welche Pfade den öffentlichen Router umgehen, welcher Build-Schritt Artefakte signiert, welche Verzeichnisse generierten Code enthalten oder welche Skripte sicher in einem Staging-Klon, aber niemals auf produktionsnahen Daten ausgeführt werden können. Wenn diese Fakten über mehrere Sitzungen hinweg sichtbar bleiben, verschwendet der Agent weniger Mühe damit, dieselbe Umgebung neu zu erlernen. Das macht die Analyse nicht automatisch richtig, aber es macht den Arbeitsablauf realistischer für eine dauerhafte Überprüfung. (Claude API-Dokumente)

Hooks vertiefen die Geschichte. Anthropic dokumentiert Hooks als durch den Lebenszyklus ausgelöste Shell-Befehle, HTTP-Endpunkte oder LLM-Prompts. In einem Sicherheitskontext bedeutet dies, dass Sie Preflight- und Postflight-Prüfungen automatisieren können, die ein normaler Coding Agent andernfalls überspringen oder inkonsistent erinnern würde. Sie können Sitzungen automatisch mit Scope-Metadaten kennzeichnen. Sie können die Erfassung von Artefakten nach bestimmten Klassen der Toolverwendung erzwingen. Sie können warnen oder anhalten, wenn ein Befehl einen verbotenen Bereich erreicht. Sie können nach der Aufnahme des Burp-Exports einen schreibgeschützten Parsing-Schritt durchführen oder auf einer lokalen Diff-Überprüfung bestehen, bevor Sie einen Patch akzeptieren, der die Autorisierungslogik berührt. Das sind keine glamourösen Funktionen, aber sie sind genau die Art und Weise, wie ernsthafte Entwicklungsteams einen intelligenten Agenten in eine vertrauenswürdige Workflow-Komponente verwandeln. (Claude API-Dokumente)

Die kommerzielle Datenpolitik von Anthropic ist auch für Käufer von Bedeutung, die repozentrische Sicherheits-Workflows bewerten. Anthropic erklärt, dass es unter kommerziellen Bedingungen keine generativen Modelle mit Code oder Prompts trainiert, die an Claude Code gesendet werden, es sei denn, der Kunde hat sich ausdrücklich für die Bereitstellung von Daten zur Modellverbesserung entschieden. Das beantwortet nicht alle Beschaffungsfragen und macht eine Überprüfung der Bereitstellung, Aufbewahrung oder Auswahl des Anbieters nicht überflüssig. Aber es ist immer noch ein konkreter Unterschied zwischen "wir müssen die Position des Anbieters aus der Marketingsprache ableiten" und "der Anbieter hat eine spezifische Erklärung zur Verwendung von Schulungen veröffentlicht". Für Sicherheitstechnikerteams, die sich mit Quellcode, internen Erkenntnissen und Diskussionen über Abhilfemaßnahmen befassen, ist dies kein Nebenaspekt. Es ist Teil der Frage, ob ein Tool überhaupt verwendet werden kann. (Claude API-Dokumente)

Die Kehrseite der Medaille ist, dass White-Box-Stärke nicht dasselbe ist wie Black-Box-Beweis. Claude Code kann hervorragend darin sein, einen wahrscheinlichen Exploit-Pfad aus dem Quellcode oder der Konfiguration abzuleiten. Er kann einen Test entwerfen. Er kann mehrere lokale Anhaltspunkte zu einer starken Hypothese verbinden. Aber die letzte Frage in einem Pentest ist normalerweise nicht "sieht der Code riskant aus". Sie lautet: "Was ist auf dem Zielsystem passiert, unter welchen Bedingungen, und kann eine andere Person es reproduzieren." Aus diesem Grund benötigt ein guter Claude-zentrierter Sicherheits-Workflow fast immer eine explizite, von einem Verifier unterstützte Schicht. Einer der öffentlichen, auf Claude fokussierten Artikel von Penligent bringt diesen Punkt gut auf den Punkt: Ein nützlicher Pentest-Copilot ist instrumentiert, eingeschränkt und von einem Verifizierer unterstützt. Diese Formulierung ist genau deshalb nützlich, weil sie das Modell nicht überbewertet. Es behandelt das Modell als Argumentationsebene, nicht als endgültigen Richter über die Realität. (Sträflich)

Warum Penligent für einen anderen Teil der Arbeit optimiert

Das öffentliche Material von Penligent weist auf einen anderen Schwerpunkt der Optimierung hin. Auf der Homepage werden mehr als 200 unterstützte Tools, neueste CVE-Scans, PoC-Exploit-Skripte mit nur einem Klick, Signal-to-Proof-Ausführung, Artefakte mit rückverfolgbarem Nachweis, prompte Bearbeitung, Umfangssperrung, Aktionsanpassung und bearbeitbare Berichte im Einklang mit SOC 2 und ISO 27001 betont. Selbst wenn Sie die gesamte Branding-Sprache ignorieren und nur die konkreten Teile nehmen, ist die Absicht des Designs offensichtlich. Es handelt sich nicht in erster Linie um einen repo-nativen Kodierungsassistenten. Es handelt sich um ein Workflow-Produkt, das versucht, den Abstand zwischen Suche, Validierung, Nachweis und Bericht zu verkürzen. Das ist ein anderes Problem als "Hilf mir, innerhalb einer Codebasis zu denken", und es führt zu anderen Produktentscheidungen. (Sträflich)

Dieser Unterschied wird in Penligents eigenen technischen Texten deutlicher. Der öffentliche Artikel über den Übergang von einem schnellen PoC zu einem reproduzierbaren Beweis macht deutlich, dass Sicherheitsteams keine abstrakten PoCs erstellen. Sie beheben reproduzierbare Beweise, die mit einem realen System, einer Version, einer Vertrauensgrenze und einem beobachteten Verhalten verbunden sind. Ein anderer Penligent-Artikel über die Orchestrierung natürlicher Sprache beschreibt das Ziel, natürliche Sprache zu verwenden und eine Multi-Tool-Angriffskette zu erstellen, deren Artefakte von Technikern, Compliance-Mitarbeitern und Führungskräften verwendet werden können. Das sind gute Beschreibungen eines workflow-nativen Angriffsprodukts, weil sie die Artefaktkette in den Mittelpunkt stellen, nicht den Dialog. Selbst wenn ein Leser Penligent nie benutzt, ist dieser Design-Schwerpunkt immer noch der richtige Blickwinkel, um ein ernsthaftes KI-Pentestsystem zu bewerten. (Sträflich)

Das ist auch der Grund, warum sich ein vertikales Workflow-Produkt weniger "allgemein" anfühlen kann als Claude Code und dennoch näher an dem ist, was viele Sicherheitsteams tatsächlich brauchen. Die harte Mitte des Pentestings ist chaotisch. Die Ergebnisse sind unvollständig. Autorisierungskontexte weichen ab. Geschäftslogik erfordert Wiederholung. Header lügen. Sitzungen laufen ab. Eine Anfrage, die in einem Scratchpad schlüssig aussah, stellt sich als abhängig von einer versteckten Rolle oder einem veralteten Cache heraus. Ein scharfsinniger Coding Agent hilft bei der Argumentation in diesem Chaos. Ein Workflow-System hilft, indem es das Durcheinander in einen wiederholbaren Zustand zwingt: Artefakterfassung, Sequenzaufbewahrung, Berichtsstruktur und Re-Testbarkeit. Das sind verschiedene Arten von Wert. Ein ernsthafter Käufer sollte nicht so tun, als seien sie austauschbar. (Sträflich)

Die Divergenz wird noch deutlicher, wenn man vergleicht, was jedes Produkt öffentlich als primäre Ausgabe behandelt. Die öffentliche Claude-Code-Oberfläche von Anthropic konzentriert sich auf das Lesen, Bearbeiten, Befehle, Eingabeaufforderungen, Speicher und Entwicklungsintegrationen. Die öffentliche Oberfläche von Penligent konzentriert sich auf verifizierte Ergebnisse, Beweisartefakte, kontrollierte agenturische Arbeitsabläufe und Berichtspakete. Das macht einen nicht abstrakt gesehen besser. Es bedeutet, dass die Produkte benachbarte, aber nicht identische Probleme lösen. Wenn Ihr Engpass darin besteht, dass ich schnellere und bessere Argumente gegen Code und lokale Tools brauche, kann Claude Code eine gute Lösung sein. Wenn Ihr Engpass darin besteht, dass ich eine validierte, zielgerichtete Ausgabe benötige, die ich erneut ausführen und ausliefern kann, löst ein workflowbasiertes Produkt ein anderes und oft umfassenderes Problem. (Claude)

Claude Code vs. Penligent auf fünf Systemebenen

Die sauberste Art, diese Systeme zu vergleichen, ist nicht der Vergleich von Modellnamen, UI-Politur oder Bildschirmabbildungen. Es geht darum, die Ebenen zu vergleichen, auf denen offensive Workflows tatsächlich erfolgreich sind oder scheitern.

Die erste Ebene ist der Ausführungsschwerpunkt. Claude Code wurde entwickelt, um dort zu leben, wo Ingenieure und Forscher bereits arbeiten. Das gibt ihm eine enorme Hebelwirkung für White-Box-Aufgaben, aber es bedeutet auch, dass die "wahre Quelle" der Sitzung oft das ist, was das Repo, die Shell oder die angeschlossenen Tools lokal offenbaren. Das öffentliche Material von Penligent weist in die entgegengesetzte Richtung. In der Ausführungsgeschichte geht es um die Verkettung von Werkzeugen zur zielgerichteten Validierung und um die Kohärenz des resultierenden Beweismaterials. Deshalb sind Vergleiche, die nur auf der Frage basieren, wer mehr Werkzeuge aufrufen kann, so schwach. Die Anzahl der Werkzeuge ist weit weniger wichtig als die Frage, wo das System die Aufgabe wirklich sieht. (Claude)

Die zweite Schicht ist der Zustand. Claude Code verfügt über ernstzunehmende Zustandsprimitive. Anthropische Dokumente CLAUDE.md, automatischer Speicher, Unteragenten und sitzungsorientierte Kontextverwaltung. Das reicht aus, um erstaunlich ausgeklügelte Sicherheitsabläufe zu entwickeln. Aber der Zustand ist immer noch grundlegend konversationell und umgebungsabhängig. Die öffentlichen Materialien von Penligent betonen stattdessen Artefakte, Schritte, nachvollziehbare Beweise und die Verpackung von Berichten. Das ist eine andere Art, den Fortschritt zu speichern. Die eine ist für die Fortsetzung der Arbeit optimiert. Die andere ist dafür optimiert, die Arbeit zu bewahren, so dass andere Leute sie prüfen, reproduzieren und darauf reagieren können. Beim Pentest ist beides wichtig, aber es ist nicht dasselbe. (Claude API-Dokumente)

Die dritte Ebene ist die Validierung. Hier werden viele KI-Produktvergleiche irreführend. Claude Code kann extrem gut darin sein, eine überzeugende Exploit-Hypothese aufzustellen, das richtige Test-Kabinett zu entwerfen oder einen Schwachstellen-Kandidaten zu Code und Konfiguration zurückzuverfolgen. Aber es handelt sich nicht um einen Arbeitsablauf, der standardmäßig jede Behauptung als nicht vertrauenswürdig behandelt, bis sie unabhängig gegen ein Ziel oder eine Umgebung geprüft wurde. Die besten Claude-zentrierten Offensiv-Workflows berücksichtigen dies durch Hinzufügen von Evidence Gates, eingeschränkten Tools und externer Validierung. Die öffentliche Positionierung von Penligent ist hier viel direkter. Sie konzentriert sich wiederholt auf verifizierte Auswirkungen, reproduzierbare Beweise und Ergebnisse, die auf Beweisen basieren. Der Unterschied besteht nicht darin, dass die eine Seite "KI" einsetzt und die andere nicht. Der Unterschied besteht darin, was jede Seite als fertige Arbeit betrachtet. (Sträflich)

Die vierte Ebene ist die Governance. Das öffentliche Sicherheitsmodell von Anthropic für Claude Code ist detailliert und techniklastig: explizite Genehmigungen, Schreibbeschränkungen, Sandboxing, Verweigerungsregeln, Erlaubnislisten und Lebenszyklus-Hooks. Das ist eine echte Stärke für Unternehmen, die ihre eigenen geregelten Arbeitsabläufe aufbauen wollen. Die öffentliche Produktsprache von Penligent ist einfacher und eher workflow-spezifisch: Eingabeaufforderungen bearbeiten, Bereich sperren, Aktionen anpassen, Berichte erstellen. Es handelt sich um unterschiedliche Governance-Sprachen, da die Systeme auf unterschiedlichen Abstraktionsebenen verwaltet werden. Die Governance von Claude Code fragt danach, "was der Agent in dieser Umgebung tun darf". Die Governance von Penligent, zumindest in den öffentlichen Materialien, fragt häufiger: "Wie halten wir diesen offensiven Workflow innerhalb der Ziel-, Nachweis- und Berichtsgrenzen, die wir tatsächlich brauchen." (Claude)

Die fünfte Schicht ist die Ausgabe. Claude Code gibt auf natürliche Weise Arbeitsspeicher aus: Notizen, Diffs, Shell-Historien, Code-Edits, vorgeschlagene Tests, zusammengefasste Ergebnisse und manchmal hochwertige lokale Automatisierung. Penligent vermarktet natürlich fertige Beweise: Artefakte, nachvollziehbare Beweise, reproduzierbare Schritte und saubere Berichte. Dies ist die Schicht, die sich am direktesten darauf auswirkt, ob ein Team ein solches System kaufen, um ein solches herum bauen oder beides kombinieren sollte. Wenn Ihr Endverbraucher ein leitender Ingenieur ist, der den schnellsten Weg zum Patch sucht, ist Claude Code vielleicht die bessere erste Oberfläche. Wenn es sich bei dem Endverbraucher um einen Sicherheitsverantwortlichen, einen Kunden oder einen Verantwortlichen für Abhilfemaßnahmen handelt, der ein reproduzierbares Proof-Paket benötigt, ist das workflow-native Design viel näher am Ziel. (Claude)

Die CVEs, die die tatsächliche Sicherheitsgrenze erklären

Der schnellste Weg, den Unterschied zwischen einem erweiterbaren Kodierungsagenten und einem Pentest-Workflow-System zu verstehen, besteht nicht darin, Produkttexte zu lesen. Vielmehr muss man sich ansehen, wo echte Schwachstellen auftreten, wenn Agenten, Tools, Protokolle und Zustandsschichten zusammengefügt werden. Diese Vorfälle zeigen die wahren Ausführungsgrenzen auf.

Ein guter Ausgangspunkt ist der von Invariant dokumentierte und von Red Hat zusammengefasste GitHub MCP Prompt-Injection-Fall. Die Angriffskette beruhte nicht auf einem mystischen "KI-Bug". Sie beruhte auf der Tatsache, dass ein Agent, der eine GitHub MCP-Integration verwendet, vom Angreifer kontrollierte Probleminhalte konsumieren und zu einem unbeabsichtigten Verhalten gelenkt werden konnte, das private Repository-Daten offenlegte. Die Zusammenfassung von Red Hat ist besonders nützlich, weil sie die Protokollhysterie vermeidet und sich auf den eigentlichen Mechanismus konzentriert: Ein manipuliertes bösartiges Problem in einem öffentlichen Repository wird zu einem nicht vertrauenswürdigen Inhalt innerhalb eines Agenten-Workflows, der ein Tool verwendet. Das ist die Art von Fehler, die für Claude Code plus Skills plus MCP von Bedeutung ist, denn der Wert des Stacks ergibt sich aus der Verbindung des Agenten mit echten Systemen. In dem Moment, in dem man das tut, hört der nicht vertrauenswürdige Tool-Kontext auf, ein abstraktes Sicherheitsthema zu sein, und wird zu einem operativen Sicherheitsproblem. (invariantlabs.ai)

Die nächst tiefere Ebene ist das Tooling rund um MCP selbst. Das GitHub-Advisory zu CVE-2025-49596 besagt, dass Versionen von MCP Inspector unter 0.14.1 anfällig für Remotecodeausführung sind, da dem Inspector-Client und -Proxy die Authentifizierung fehlt, wodurch nicht authentifizierte Anfragen MCP-Befehle über stdio starten können. Dieses Advisory ist hier aus einem einfachen Grund von Bedeutung: Viele Teams, die mit Agent-Erweiterungen experimentieren, gehen davon aus, dass ihre Debugging- und Inspektions-Tools "sicher sind, weil sie Entwickler-Tools sind". Diese CVE zeigt das Gegenteil. In Agenten-Ökosystemen ist die Debugging-Infrastruktur Teil der Angriffsfläche. Wenn man eine verallgemeinerte Pentest-Workbench aus lokalen Werkzeugen, Fähigkeiten und Protokollkomponenten aufbaut, dann müssen auch die Diagnosewerkzeuge der Workbench bedrohungsmodelliert sein. Ein Upgrade auf 0.14.1 oder höher ist die unmittelbare Abhilfemaßnahme, aber die umfassendere Lektion ist wichtiger: Ein flexibler Agentenstapel birgt Risiken von jeder Schicht, die Tool-Aufrufe auslösen oder weiterleiten kann. (GitHub)

CVE-2025-6515, der oatpp-mcp Prompt-Hijacking-Fall, vertieft die Lektion. JFrog und NVD beschreiben das Problem als eine Schwachstelle im Design der Sitzungskennung im MCP-SSE-Endpunkt, bei dem ein Instanzzeiger als nicht kryptografisch sichere Sitzungskennung wiederverwendet wurde. Ein Angreifer mit Netzwerkzugriff auf den entsprechenden HTTP-Server könnte künftige Sitzungs-IDs erraten und legitime MCP-Sitzungen von Clients entführen, um böswillige Antworten vom MCP-Server zurückzugeben. Die Exploit-Bedingung ist wichtig: Dies ist keine allgemeine Anklage gegen alle Agenten-Tools und kein Beweis dafür, dass jeder Einsatz von Claude Code anfällig ist. Es ist eine Erinnerung daran, dass das Sitzungsdesign Teil des Bedrohungsmodells wird, sobald Agentenerweiterungen die rein lokale Grenze verlassen und auf Netzwerktransporte angewiesen sind. Für Teams, die einen Allzweck-Codierungsagenten in eine mit dem Netzwerk verbundene offensive Werkbank umwandeln, können Transportsicherheit und Sitzungsintegrität keine nachträglichen Überlegungen sein. (forschung.jfrog.de)

CVE-2025-68143 in mcp-server-git ist besonders relevant, da es sich um eine offizielle MCP-Server-Implementierung und nicht um ein Randexperiment handelt. Das von GitHub überprüfte Advisory besagt, dass Versionen vor 2025.9.25 beliebige Dateisystempfade in der git_init Tool und erstellte Repositorys, ohne den Zielspeicherort zu überprüfen, wodurch diese Verzeichnisse für nachfolgende Git-Operationen freigegeben wurden. Die Behebung des Problems war entscheidend: Das anfällige Tool wurde vollständig entfernt, da der Server nur mit bestehenden Repositorys arbeiten sollte. Die Relevanz für diesen Artikel ist einfach. Wenn man von "Claude Code plus Pentest-Skills" spricht, stellt man sich oft vor, dass das interessante Risiko nur in den Skill-Anweisungen oder der Modellausgabe liegt. Dieser Ratschlag zeigt, dass die serverseitige Tool-Grenze genauso wichtig sein kann. Wenn der Tool-Wrapper das zugängliche Dateisystem in einer unbeabsichtigten Weise erweitert, erweitert sich damit auch die praktische Fähigkeit des Agenten. Dies ist kein theoretisches Problem. Es handelt sich um eine überprüfte Empfehlung mit einem konkreten Patch-Pfad. (GitHub)

CVE-2026-0621 im MCP TypeScript SDK veranschaulicht eine andere Art der Gefährdung. Das Advisory von GitHub beschreibt einen ReDoS-Fehler in der UriTemplate Klasse, die es ermöglichen könnte, handgefertigte ressourcen/lesen Anfragen zu einer 100-prozentigen CPU-Auslastung führen, den Server zum Absturz bringen und den Dienst für alle Clients verweigern. Die Exploit-Bedingung ist enger gefasst als bei den vorherigen Beispielen: Sie betrifft MCP-Server, die Ressourcenvorlagen mit explodierten Array-Mustern registrieren und nicht vertrauenswürdige Client-Anfragen akzeptieren. Aber genau deshalb ist sie für diesen Vergleich nützlich. Bei Agenten-Ökosystemen geht es nicht nur um Vertraulichkeit und Codeausführung. Auch die Verfügbarkeit ist wichtig. Eine verallgemeinerte Agentenwerkbank mit vielen Protokollkomponenten kann auf eine Art und Weise ausfallen, die wenig mit "Hacking" und alles mit der Ausfallsicherheit während der Laufzeit zu tun hat. Auch das ist ein Grund, warum Plattformen, die auf Arbeitsabläufen basieren, attraktiv sein können: Sie können die Anzahl der beweglichen Teile reduzieren, die ein Käufer direkt absichern muss, auch wenn die Plattform selbst immer noch einer eigenen Prüfung unterzogen werden muss. (GitHub)

Die CVEs für LangChain und LangGraph von Ende 2025 beziehen sich auf denselben Punkt auf der Rahmenschicht und nicht auf der Protokollschicht. NVD beschreibt CVE-2025-68664 als einen Serialisierungsinjektionsfehler in LangChains dumps() und dumpd() Funktionen, wobei Wörterbücher mit der internen lc Schlüsselstruktur während der Deserialisierung als legitime serialisierte Objekte behandelt werden könnten. NVD beschreibt CVE-2025-67644 als einen SQL-Injection-Fehler in LangGraph SQLite Checkpoint-Implementierungen, bei dem nicht vertrauenswürdige Metadaten-Filterschlüssel SQL-Abfragen in Checkpoint-Suchvorgängen manipulieren könnten. Diese Schwachstellen beziehen sich nicht speziell auf Claude Code, und genau deshalb sind sie von Bedeutung. Sie zeigen, dass moderne Agentensysteme nicht nur an den sichtbaren Rändern wie Prompts und Plugins versagen, sondern auch in ihren verborgenen Zustands- und Persistenzschichten: Serialisierung, Checkpoints, Metadatenfilter und Framework-Annahmen. Jedes Team, das sein eigenes Pentest-Produkt um einen allgemeinen Programmieragenten herum aufbaut, muss sich diese Risikooberfläche zu eigen machen. (nvd.nist.gov)

Alle diese Beispiele sind auf einen Blick leichter zu erfassen.

Die richtige Schlussfolgerung aus diesem Abschnitt ist nicht, dass Allzweck-Agentenstapel dem Untergang geweiht sind. Die faire Schlussfolgerung ist, dass Erweiterbarkeit Verantwortung für die Sicherheit schafft. Anthropics eigenes Sicherheitsmodell für Claude Code erkennt dies durch explizite Berechtigungen, Schreibbeschränkungen, Sandboxing, Prompt-Injection-Anleitung und Defense-in-Depth an. Das Protokoll-Ökosystem rund um MCP erkennt dies ebenfalls an, weshalb sich jetzt so viele Hinweise auf Toolserver, Inspektoren, SDKs und verbundene Komponenten konzentrieren. In der Praxis gilt: Je mehr Sie Claude Code in eine benutzerdefinierte Pentest-Betriebsumgebung verwandeln, desto mehr müssen Sie wie ein Plattform-Ingenieur und nicht nur wie ein Prompt-Ingenieur denken. (Claude)

Was die Forschung über KI-Pentest-Agenten sagt und was noch nicht stimmt

Das hilfreichste Forschungsergebnis in diesem Bereich ist kein einziges Benchmark-Ergebnis. Es ist die wiederholte Feststellung, dass die Leistung ebenso sehr vom Systemdesign wie von der Modellqualität abhängt. Das Papier "What Makes a Good LLM Agent for Real-world Penetration Testing?" aus dem Jahr 2026 ist nützlich, weil es sich nicht damit begnügt, höhere Punktzahlen zu bejubeln. Es unterscheidet ausdrücklich zwischen Fehlern des Typs A, die auf fehlende Werkzeuge oder unzureichende Aufforderungen zurückzuführen sind, und Fehlern des Typs B, die aufgrund von Planungs- und Zustandsverwaltungsproblemen auftreten. In dem Papier wird argumentiert, dass Agenten ihren Aufwand falsch zuordnen, in Verzweigungen mit geringem Wert stecken bleiben und den Kontext erschöpfen, bevor sie Angriffsketten beenden. Diese Diagnose ist wichtiger als die Schlagzeile, denn sie sagt den Käufern, worauf sie achten müssen. Eine Demo, die sich bei dreistufigen Aufgaben als brillant erweist, kann dennoch bei Aufgaben mit langem Zeithorizont zusammenbrechen, wenn das System keine disziplinierte Methode zur Verwaltung von Schwierigkeit, Vertrauen und Kontext hat. (arXiv)

Der Live-Unternehmensvergleich von Anfang 2026 unterstreicht diesen Punkt. In einer realen Universitätsumgebung mit etwa 8.000 Hosts in 12 Subnetzen belegte das ARTEMIS-Gerüst den zweiten Platz, fand neun gültige Schwachstellen und übertraf neun von zehn menschlichen Teilnehmern. Dieses Ergebnis ist kein Spielzeug. In demselben Dokument heißt es jedoch auch, dass die KI-Agenten eine höhere Falsch-positiv-Rate aufwiesen und sich mit GUI-basierten Aufgaben schwer taten. Diese Kombination ist genau das, was ein nüchterner technischer Käufer erwarten sollte. KI-Agenten können schnell, systematisch und billig bei der Aufzählung und parallelen Arbeit sein. Sie können aber auch die Realität falsch interpretieren, wenn die Umgebung von schwierigen Interaktionsmustern, mehrdeutigen Zuständen oder Beweisen abhängt, die sich einer Vereinfachung widersetzen. Die richtige Schlussfolgerung ist nicht: "Agenten schlagen bereits Menschen" oder "Agenten sind überbewertet". Vielmehr ist die Leistung von Agenten stark aufgabenabhängig. Jeder Vergleich zwischen Claude Code und Penligent, der die Form der Aufgabe außer Acht lässt, ist bereits zu oberflächlich. (openreview.net)

Die MAPTA-Ergebnisse beim XBOW-Benchmark sind aus demselben Grund ebenfalls aufschlussreich. Das Papier berichtet über einen Gesamterfolg von 76,9 Prozent bei 104 Web-Herausforderungen, mit starken Ergebnissen bei SSRF, Fehlkonfiguration, serverseitiger Vorlageninjektion, SQL-Injektion und gebrochener Autorisierung, aber schwächerer Leistung bei XSS und null Erfolg bei blinder SQL-Injektion. Das XBOW-Benchmark-Repository selbst beschreibt diese 104 Benchmarks als absichtlich kuratiert, um die Leistungsfähigkeit webbasierter Angriffstools zu bewerten, und merkt an, dass der Satz bis zur Veröffentlichung vertraulich behandelt wurde, um die Neuartigkeit zu bewahren. Zusammengenommen machen diese Quellen deutlich, dass moderne Multi-Agenten-Angriffssysteme durchaus sinnvolle Arbeit leisten können, ihre Stärken und Schwächen sind jedoch stark ausgeprägt. Das System kann bei sichtbaren, werkzeuggestützten, rückmeldungsreichen Schwachstellenklassen sehr leistungsfähig aussehen und dennoch Schwierigkeiten haben, wenn das Signal verzögert, indirekt oder interaktionslastig ist. (arXiv)

Dieses Muster sollte die Art und Weise ändern, wie Menschen Behauptungen über "Claude Code pentest skills" lesen. Fertigkeiten können die erste Kategorie von Fehlern durchaus verbessern. Sie können Methoden kodieren, den Weg zu besseren Werkzeugen weisen, auf Beweisen bestehen und den Arbeitsablauf standardisieren. Die zweite Kategorie von Fehlern lässt sich mit ihnen weit weniger gut lösen, wenn das zugrundeliegende Problem die Verwaltung von Horizonten, eine schwache Zustandskontrolle oder eine mehrdeutige externe Wahrheit ist. Eine Fähigkeit kann einem Agenten sagen, dass er mit blinder SQL-Injektion vorsichtig sein soll. Er kann jedoch kein sauberes Beweissignal erzeugen, wenn das System um ihn herum eine schlechte Zustandsüberwachung, eine unzureichende Instrumentierung oder eine schwache zielgerichtete Validierung aufweist. Aus diesem Grund ist das stärkste Produktargument für ein workflowbasiertes System nicht "bessere Prompts". Es ist "besseres Systemdesign rund um Beweise und Status". (arXiv)

Dies ist auch der Punkt, an dem die öffentliche Positionierung von Penligent technisch interessant und nicht nur kommerziell wird. Auf der Homepage und in den zugehörigen Beiträgen werden immer wieder dieselben Themen genannt: Signal to Proof, Artefakte, nachvollziehbare Beweise, Berichtsbearbeitung, Umfangskontrolle und reproduzierbares PoC-Material. Diese Schwerpunkte stimmen mit dem überein, was in der Forschungsliteratur immer wieder als die wahren Engpässe identifiziert wird. Das beweist aber nicht, dass Penligent jeden Benchmark gewinnt. Öffentliches Material ist keine unabhängige Bewertung. Aber es zeigt, dass das Produkt auf die richtigen Engpässe abzielt. In einem Bereich, in dem das Modell nicht mehr der einzige schwierige Teil ist, ist das wichtig. (Sträflich)

Wie man einen KI-Pentestkopiloten bewertet, ohne sich von einer Demo täuschen zu lassen

Eine seriöse Bewertung beginnt damit, dass man sich weigert, Systeme auf der Grundlage eines einzigen undifferenzierten Begriffs von "Sicherheitstests" zu vergleichen. Die Überprüfung von White-Box-Repos unterscheidet sich von der Black-Box-Validierung der Zielvorgaben. Authentifiziertes Testen der Geschäftslogik ist etwas anderes als CVE-Replay. Patch-Direction-Arbeit ist etwas anderes als Stakeholder-Reporting. Ein Coding Agent kann eine Klasse gewinnen und eine andere verlieren. Ein Workflow-natives System kann in einer Coding-Demo enger aussehen und bei der Übergabe von Abhilfemaßnahmen viel stärker sein. Wenn Sie einen fairen Test durchführen wollen, sollten Sie die Szenarien zunächst aufteilen. Dann bewerten Sie sie mit den Metriken, die tatsächlich den operativen Wert widerspiegeln. Die Forschungsliteratur gibt bereits die richtigen Hinweise: Falschmeldungen, Kontextfehler, Reibung auf der Benutzeroberfläche, Empfindlichkeit der Exploit-Klassen und die Belastung des Bedieners spielen alle eine Rolle. (arXiv)

Die nützlichste primäre Kennzahl ist nicht die "Anzahl der aufgedeckten möglichen Probleme". Es ist die Zeit bis zum ersten validierten Befund. Die zweite ist die Rate der validierten Befunde, nicht die Anzahl der Rohbefunde. Danach folgen die Belastung durch falsch-positive Ergebnisse, die Anzahl der Bedienereingriffe, die Vollständigkeit der Nachweise, die Wiederholbarkeit der Tests und die Bereitschaft zur Berichterstellung. Diese Metriken machen es für ein Produkt viel schwieriger, zu gewinnen, indem es plausibel aussehendes Rauschen produziert. Sie machen es auch viel einfacher zu erkennen, welche Kategorie Sie wirklich kaufen. Ein Coding Agent mit Pentest-Fähigkeiten könnte bei der Patch-Anleitung, der lokalen Reproduktion und dem operator-augmented Code Understanding extrem gut abschneiden. Ein workflowbasiertes System könnte bei der Vollständigkeit von Beweisen, der Wiederholbarkeit von Tests und der Bereitschaft für Berichte dominieren. Das ist kein Makel der beiden Systeme. Es ist der Sinn des Vergleichs. (openreview.net)

Ein echtes Beweisbündel sollte auch so konkret sein, dass eine andere Person es wiederholen kann, ohne zu raten, was passiert ist.

{
  "asset": "staging.example.internal",
  "finding_id": "idor-authz-01",
  "preconditions": [
    "authentifiziert als basic_user",
    "feature_flag=beta_exports enabled"
  ],
  "control_request": "GET /api/exports/12345 gibt 403 für nicht verwandte Ressource zurück",
  "test_request": "GET /api/exports/67890 gibt 200 für einen anderen Mandanten zurück",
  "observable_effect": "Mandantenübergreifende Export-Metadaten offengelegt",
  "supporting_artifacts": [
    "request.txt",
    "antwort.txt",
    "session-notes.md",
    "screenshot.png"
  ],
  "retest_after_fix": "wiederhole sowohl Kontroll- als auch Testanfragen nach dem Autorisierungspatch"
}

Nichts an dieser Struktur ist glamourös, aber genau deshalb ist sie so wichtig. Sie zwingt das System, das Minimum an Informationen zu erhalten, das ein Ingenieur, Triager oder Retester benötigt. Es zeigt auch auf, wo ein Coding-Agent-Workflow und ein Pentest-Workflow-Produkt oft voneinander abweichen. Ein Coding Agent kann Sie bei der Erstellung dieses Artefakts unterstützen. Ein Workflow-natives System kann die Artefakterzeugung zum Standardpfad machen, statt zu einer zusätzlichen Disziplin, an die Sie sich erinnern müssen, um sie durchzusetzen. Die öffentlichen Materialien und technischen Beiträge von Penligent zielen ganz klar auf dieses zweite Muster ab. Die offiziellen Materialien von Claude Code zielen viel deutlicher darauf ab, die Workbench selbst leistungsfähig und kontrollierbar zu machen. (Sträflich)

Eine praktische Bewertungsmatrix sollte eher wie folgt aussehen.

Der Sinn dieser Tabelle ist einfach. Beim Kauf oder Aufbau eines KI-Pentest-Stacks geht es nicht mehr hauptsächlich um die Modellauswahl. Es geht darum zu entscheiden, welche Fehlermodi Sie tolerieren können und welche Ihr Arbeitsablauf von vornherein ausschließen muss. Wenn Ihr Unternehmen bereits über Elite-Operatoren verfügt, die Disziplin durchsetzen können, ist Claude Code zusammen mit sorgfältig entwickelten Fähigkeiten, Berechtigungen, Sandboxing und externen Validierern vielleicht genau das Richtige. Wenn Ihr Unternehmen das System benötigt, um diese Disziplin zu institutionalisieren und konsistente Artefakte für andere Verbraucher zu produzieren, wird ein spezielles Workflow-System viel attraktiver. (Claude)

Ein Arbeitsablauf, der Claude Code und Penligent zusammen verwendet

Die realistischste Antwort für reife Teams ist oft "beides", aber nur, wenn die Arbeitsteilung explizit ist. Claude Code eignet sich hervorragend für White-Box Discovery, Patch Direction, Repo-Local Reasoning und den Aufbau von Bounded Local Experiments. Das öffentliche Material von Penligent deutet darauf hin, dass es auf zielgerichtete Validierung, nachvollziehbare Beweise und Berichtspaketierung abzielt. Dies sind komplementäre Schwerpunkte. Ein Team, das versucht, Claude Code zu einer vollständigen Pentest-Plattform zu machen, wird am Ende möglicherweise einen Großteil der Workflow-Infrastruktur rund um Beweise, Wiederholungstests und Artefakterfassung neu aufbauen müssen. Ein Team, das die repo-nativen Stärken von Claude Code ignoriert, verpasst möglicherweise den schnellsten Weg vom Code-Verdacht zur präzisen Hypothese. Der ausgereifte Schritt besteht nicht darin, diese Unterschiede zu verwässern. Er besteht darin, sie zu operationalisieren. (Claude)

Eine sinnvolle Schleife beginnt mit Claude Code in der Nähe des Codes und der geklonten Umgebung. Verwenden Sie ihn, um riskante Abläufe abzubilden, Autorisierungs- und Vertrauensgrenzen zu untersuchen, Hypothesen aus der Konfiguration und dem Verlauf abzuleiten, minimale Tests vorzuschlagen und Abhilfemaßnahmen zu entwerfen. Halten Sie den Agenten mit Berechtigungen, Sandboxing und Fähigkeiten zur Durchsetzung von Methoden in Schach, damit er ein disziplinierter Forschungsassistent und kein übervertrauter Richter bleibt. Dann verlagern Sie die Arbeit in eine zielgerichtete Validierungsschicht, wo das Ziel nicht weitere Spekulationen, sondern Beweise sind: exakte Bedingungen, exakte Artefakte, exakter beobachtbarer Effekt, exakter Testpfad. Penligents eigenes öffentliches Schreiben über den Übergang von White-Box-Ergebnissen zu Black-Box-Beweisen beschreibt fast genau diese Aufteilung und betont die Validierung gegen reale Ziele, reproduzierbare Beweise und wiederholte Überprüfung nach Korrekturen. Das ist ein starkes praktisches Modell, selbst wenn Sie verschiedene Produkte austauschen. (Sträflich)

Dieses kombinierte Modell hat auch eine nützliche Governance-Eigenschaft. Es behält das Werkzeug mit der höchsten Flexibilität dort bei, wo Flexibilität am wertvollsten ist, d.h. beim frühen Abgleich mit dem lokalen Kontext. Es behält den Artefaktpfad mit der höchsten Disziplin dort bei, wo Disziplin am wichtigsten ist, d. h. wenn Behauptungen die Überprüfung, Korrektur und erneute Prüfung überstehen müssen. Mit anderen Worten: Die Freiheit der Werkzeuge wird mit der Forschung in Einklang gebracht und die Struktur des Arbeitsablaufs mit dem Nachweis. Das ist ein viel gesünderes Design, als von einem Produkt zu verlangen, dass es gleichzeitig der Freiform-Ermittler, der Validierer, der Historiker, die Policy-Engine und der Berichtschreiber ist, es sei denn, es wurde absichtlich so entwickelt, dass es all das kann. (Sträflich)

Die endgültige Verantwortung verschiebt sich jedoch nicht. Der PoC-Artikel von Penligent bringt es auf den Punkt: Der Mensch bleibt verantwortlich. Das ist der richtige Schluss für jede Diskussion über agenturbedingte Straftaten. Umfang, Autorisierung, Stopp-Bedingungen, rechtliche Grenzen, Vertrauensmarken und Eskalationsentscheidungen gehören immer noch zu den Menschen. Gute Systeme machen diese Verantwortung leichter ausübbar. Schlechte Systeme verstecken sie hinter glatten Demos. (Sträflich)

Claude Code vs. Penligent, die wahre Antwort

Claude Code mit Pentest-Fähigkeiten ist keine Spielerei. Er kann eine der leistungsstärksten Sicherheitswerkbänke sein, die einem technischen Operator zur Verfügung stehen, weil er Repo-Awareness, Befehlsausführung, Speicher, Spezialisierung und Erweiterbarkeit innerhalb derselben Oberfläche kombiniert, auf der die eigentliche technische Arbeit stattfindet. Die öffentliche Dokumentation von Anthropic untermauert dies im Detail. Aber dieselbe Dokumentation macht auch deutlich, dass Claude Code eine geregelte Programmierumgebung ist und kein vorgelöster Pentest-Workflow. Fertigkeiten erweitern das Verhalten. Sie machen die Notwendigkeit von Berechtigungen, Sandboxing, Validierungsdisziplin oder Evidence Engineering nicht überflüssig. (Claude)

Penligent löst, zumindest in seinen öffentlichen Unterlagen, ein spezifischeres und operationelleres Problem. Der Schwerpunkt liegt auf zielgerichteter Ausführung, Proof-Artefakten, Umfangskontrolle und Berichtspaketierung. Das macht es nicht zu "mehr KI" oder "weniger KI". Es macht es für den Teil des Pentestings, bei dem viele Agenten-Demos immer noch versagen, arbeitsplatznaher: den Abschluss der Kette vom Signal zum Nachweis. Die Forschung zu LLM-Pentestsystemen weist immer wieder auf die gleichen Engpässe bei Planung, Kontext, Zustand und Validierung hin. Deshalb ist der richtige Vergleich nicht Modell gegen Modell. Es ist Werkbank gegen Workflow-System. (Sträflich)

Die sauberste Schlussfolgerung ist auch die am wenigsten dramatische. Verwenden Sie Claude Code, wenn Ihre Vorteile im Code-Zugriff, in der Anpassung, in lokalen Werkzeugen und in der flexiblen Forschung liegen. Verwenden Sie ein Workflow-natives System, wenn Ihr Vorteil in validiertem Zielverhalten, wiederholbaren Beweisen und berichtspflichtigen Artefakten liegt. Verwenden Sie beides, wenn Ihr Team reif genug ist, um die Erstellung von Hypothesen von der Erstellung von Beweisen zu trennen. Das Modell ist nicht der Pentest-Workflow. In der realen offensiven Sicherheit besteht der schwierige Teil nicht darin, den nächsten Befehl zu produzieren. Es geht darum, die Kette vom Signal bis zum Beweis aufrechtzuerhalten. (Sträflich)

Weiterführende Literatur und Referenzen

Für die primäre Dokumentation über Claude Code selbst sind die nützlichsten Ausgangspunkte Anthropics Überblick über Claude Code, die offiziellen Dokumente über Fähigkeiten, Subagenten, Berechtigungen, Sandboxing, Hooks, Speicher, Datennutzung und die MCP-Einführung. Diese Dokumente definieren die tatsächlichen Verhaltensgrenzen des Systems viel besser als jeder Social Post oder Produktkommentar. (Claude)

Für die Sicherheitsgrenzen rund um Agenten-Ökosysteme sind die nützlichsten Quellen die MCP-Sicherheitsanalyse von Red Hat, die GitHub-MCP-Fallstudie von Invariant, die auf GitHub überprüften Advisories für CVE-2025-49596, CVE-2025-68143 und CVE-2026-0621, die Aufzeichnungen von JFrog und NVD für CVE-2025-6515 und die Aufzeichnungen von NVD für die Probleme mit LangChain und LangGraph. Diese Quellen sind viel wertvoller als allgemeine Hot Takes, da sie zeigen, wo echte Fehler aufgetreten sind und welche genauen Annahmen nicht eingehalten wurden. (redhat.de)

Für die Erforschung dessen, was KI-Pentest-Agenten heute leisten können und was nicht, sind die wichtigsten Referenzen, die hier verwendet werden, das 2026-Papier über reale Penetrationstest-Agenten, die Live-Vergleichsstudie für Unternehmen auf OpenReview, das MAPTA-Papier und das XBOW-Benchmark-Repository. Zusammen bilden sie eine viel bessere Grundlage für die Systembewertung als isolierte Hersteller-Benchmarks. (arXiv)

Für Penligent-Seiten, die direkt mit diesem Thema zu tun haben, sind die natürlichsten internen Weiterleitungen die Penligent-Homepage, der Artikel über den Aufbau eines evidenzbasierten Workflows mit Claude Code, der Artikel über den Übergang von White-Box-Befunden zu Black-Box-Beweisen und der Artikel über den Aufbau reproduzierbarer Beweise aus einem schnellen PoC. Diese Links stehen in direktem Zusammenhang mit dem Vergleich in diesem Artikel und müssen nicht in ein separates Verkaufsargument gezwängt werden, um nützlich zu sein. (Sträflich)