Die Phrase Pentest gpt bedeutet jetzt zwei verschiedene Dinge auf einmal, und diese Trennung ist das Erste, was Sicherheitsingenieure richtig machen müssen. In gewisser Weise deutet sie auf PentestGPT, das Forschungsprojekt, das von USENIX Security 2024 veröffentlicht und auf GitHub gepflegt wird. Im weiteren Sinne ist der Begriff zu einem Kürzel für eine ganze Klasse von Systemen geworden, die umfangreiche Sprachmodelle, Scanner-Ausgaben, Tool-Aufrufe, Ausführungslogik, Zustandsverfolgung und Berichterstattung zu etwas kombinieren, das wie ein KI-gestützter Penetrationstester aussieht. Diese Unterscheidung ist wichtig, da das ursprüngliche Papier ein Meilenstein in der Forschung war, während der breitere Marktbegriff nun alles von leichtgewichtigen ChatGPT-Wrappern bis hin zu vollständigen agentenbasierten Pentesting-Plattformen umfasst. (arXiv)
Diese breitere Verwendung des Begriffs ist nicht nur ein Marketing-Gag. Sie spiegelt eine echte Veränderung in der zugrunde liegenden Technologie wider. Der Aufruf von Tools ist heute ein Standardentwurfsmuster für moderne LLM-Systeme, und die aktuelle Agentenanleitung von OpenAI behandelt Prompt Injection, Datenlecks und riskante Tool-Aufrufe als erstklassige technische Probleme und nicht als Randfälle. Gleichzeitig hat die Forschung Dritter gezeigt, dass KI-Agenten bereits eine erstaunliche Menge an offensiver Arbeit in eng begrenzten Umgebungen automatisieren können, obwohl sie immer noch unter der Leistung qualifizierter Menschen liegen, wenn es um Priorisierung, strategische Weichenstellungen und umfassendere operative Entscheidungen geht. (OpenAI-Entwickler)
Die eigentliche Frage ist also nicht mehr, ob GPT-ähnliche Modelle zu Penetrationstests beitragen können. Das können sie eindeutig. Die schwierigere Frage ist, welchen Teil des Pentesting-Lebenszyklus sie gut abdecken können, wo sie noch versagen und was ein verantwortungsbewusstes Entwicklungsteam von einem Produkt oder Arbeitsablauf verlangen sollte, der als "PentestGPT" vermarktet wird. An dieser Stelle ist das ursprüngliche PentestGPT-Papier immer noch nützlich, weil es sowohl die Versprechen als auch die Grenzen mit ungewöhnlicher Klarheit erklärt. Die Autoren erstellten einen Benchmark auf der Grundlage realer Penetrationstests und stellten fest, dass LLMs häufig in der Lage waren, lokale Aufgaben wie die Verwendung von Tools und die Interpretation von Ergebnissen zu bewältigen. Ihre Antwort war ein modulares Design, das den Verlust von Kontext reduzieren sollte. In ihrer Bewertung verbesserte PentestGPT die Aufgabenerfüllung bei den Vergleichszielen um 228,6 Prozent gegenüber GPT-3.5. (arXiv)
Dieses Ergebnis ist einer der Gründe, warum das Projekt so viel Anklang fand. In dem Papier wurde nicht behauptet, dass KI die offensive Sicherheit bereits gelöst habe. Es behauptete etwas Glaubwürdigeres und, im Nachhinein betrachtet, Wichtigeres: LLMs waren bereits stark genug, um bei der Verknüpfung traditioneller Tools zu helfen, aber schwach genug, dass die Architektur und die Gestaltung der Arbeitsabläufe darüber entscheiden würden, ob das System nützlich bleibt oder in die Bedeutungslosigkeit abdriftet. Die Autoren haben Penetrationstests auch in den bekannten Fünf-Phasen-Lebenszyklus von Erkundung, Scannen, Schwachstellenbewertung, Ausbeutung und Berichterstattung nach der Ausbeutung eingeordnet, was nach wie vor eine nützliche Methode ist, um moderne KI-Pentesting-Systeme zu beurteilen. Ein Modell, das in einer Demo gut aussieht, aber den Zustand über diese Phasen hinweg nicht beibehalten kann, ist keine Lösung für Pentesting. Es automatisiert nur isolierte Fragmente. (arXiv)
Was pentest gpt eigentlich ist
Eine gute Arbeitsdefinition ist die folgende: Pentest GPT ist ein KI-gestütztes Penetrationstestsystem, das ein Sprachmodell als Argumentations- und Orchestrierungsschicht zwischen Zieldaten, Sicherheitstools, Ausführungsumgebungen, Beweiserfassung und Berichterstattung verwendet. Das ist etwas ganz anderes, als einen allgemeinen Chatbot zu bitten, Nutzdaten vorzuschlagen oder ein CVE zu erklären. Die hochrangigen Erklärer des Begriffs sind sich in diesem Punkt weitgehend einig. Sie beschreiben "Pentest GPT" nicht als magischen One-Prompt-Hacker, sondern als ein System, das sich in Tools wie Scanner und Frameworks einklinkt, deren Ergebnisse interpretiert, die nächsten Schritte vorschlägt und versucht, den Überblick darüber zu behalten, was bereits versucht wurde. (Aikido)
Aus diesem Grund wird der Begriff immer weiter über das ursprüngliche Projekt hinaus ausgedehnt. Sobald man akzeptiert, dass das Modell nicht das Produkt an sich ist, erweitert sich der Begriff natürlich um den Rest des Stacks: das Terminal oder die Laufzeit, die Tool-Adapter, die Browser- oder API-Konnektoren, die Ausführungsrichtlinie, den Zustandsspeicher, den Findungsnormalisierer und den Berichtsgenerator. Die aktuelle Dokumentation von OpenAI über Funktionsaufrufe und Agenten passt direkt in diese Architektur. Modelle können mit externen Funktionen verbunden, durch Schemata eingeschränkt und in Agenten-Workflows mit expliziten Sicherheitsvorkehrungen für Aktionen mit höherem Risiko verpackt werden. Das ist keine eigenständige Pentesting-Plattform, aber es ist genau das Substrat, das moderne pentest-gpt-ähnliche Systeme möglich macht. (OpenAI-Entwickler)
Die sinnvollste Art, über diese Kategorie nachzudenken, ist nicht "Kann das Modell hacken?", sondern "Kann das System sicher von der Beobachtung zum verifizierten Ergebnis übergehen?" In der Praxis bedeutet das, dass ein glaubwürdiges Pentest-GPT mindestens sechs Dinge gut machen muss. Es muss den Zielkontext aufnehmen, ohne unter dem Rauschen zusammenzubrechen. Es muss die Werkzeuge und Maßnahmen entsprechend der Phase des Einsatzes auswählen. Es muss eine überprüfbare Aufzeichnung von Aktionen und Ergebnissen führen. Sie muss Hypothesen von verifizierten Ergebnissen trennen. Es muss wissen, wann es eine Pause für eine Genehmigung oder eine menschliche Überprüfung einlegen muss. Und es muss Rohaktivitäten in Nachweise übersetzen, die ein anderer Ingenieur reproduzieren kann. Diese Anforderungen sind keine optionalen Feinheiten. Sie sind die Trennlinie zwischen einem Forschungsinteresse und einem operationell nützlichen System. (arXiv)
Wo Pentest GPT bereits nützlich ist
Die stärksten aktuellen Anwendungsfälle sind nicht mysteriös. KI-Systeme sind bereits gut darin, verrauschte Scannerausgaben zu komprimieren, verstreute Artefakte in eine plausible Angriffsgeschichte zu verwandeln, Folgebefehle oder Skripte zu entwerfen, Rohprotokolle in strukturierte Ergebnisse zu übersetzen und die Berichterstattungsschleife zu beschleunigen. In der ursprünglichen PentestGPT-Arbeit wurde festgestellt, dass LLMs häufig Teilaufgaben wie die Interpretation von Tool-Ausgaben und das Vorschlagen von Folgemaßnahmen beherrschen. Eine neuere Auswertung von Wiz ergab, dass KI-Agenten 9 von 10 offensiven Sicherheitsherausforderungen lösten, wenn die Ziele spezifisch und klar umrissen waren, was genau die Art von Umgebung ist, in der lokales Denken und wiederholte Iteration am wertvollsten sind. (arXiv)
Dies deckt sich mit den Aufgaben, bei denen erfahrene Tester tatsächlich Hilfe benötigen. Der zeitaufwändigste Teil vieler Einsätze sind nicht die schlagzeilenträchtigen Exploit-Momente. Es sind die Stunden, die damit verbracht werden, widersprüchliche Hinweise in Einklang zu bringen, Protokolle zu durchforsten, spröde Shell-Befehle umzuschreiben, denselben Pfad nach einer kleinen Kontextänderung erneut zu testen und einen halbfertigen Verdacht in eine prägnante technische Erklärung mit Beweisen umzuwandeln. LLMs sind für diese Übersetzungsebene gut geeignet. Sie können die Ausgabe zusammenfassen, die Konsistenz der Benennung wahren, alternative Hypothesen vorschlagen und einen kohärenten ersten Durchgang eines Berichts erstellen, während sich der menschliche Bediener auf die Beurteilung des Ziels und die Grenzentscheidungen konzentriert. Das ist eine Ergänzung, kein Ersatz, und es ist auch heute noch der realistischste Weg zur Wertschöpfung. (Aikido)
Ein weiterer Bereich, in dem Pentest GPT hilfreich ist, ist das Stitching von Angriffspfaden. Herkömmliche Scanner sind gut im Aufdecken von Symptomen. Sie sind jedoch weit weniger gut darin, den Weg von einer "merkwürdigen Reaktion hier" zu einer "ausnutzbaren Auswirkung dort" zu beschreiben. Ein Modell mit Zugriff auf Zielnotizen, frühere Befehle und Tool-Ergebnisse kann diesen Weg oft schneller beschreiben als ein Mensch, der von Grund auf neu schreibt. Das bedeutet nicht, dass der Weg immer richtig ist. Es bedeutet nur, dass das Modell die Liste der plausiblen Ketten schneller erstellen kann. In starken Arbeitsabläufen ist diese Geschwindigkeit wertvoll, weil der menschliche Tester mehr Zeit mit der Validierung der interessanten Ketten und weniger Zeit mit der Rekonstruktion des Kontexts verbringen kann. (arXiv)

Wo Pentest GPT immer noch versagt
Die Grenzen sind inzwischen besser dokumentiert als der Hype. In der PentestGPT-Veröffentlichung selbst wurde festgestellt, dass LLMs Schwierigkeiten haben, einen Gesamtüberblick über das Prüfszenario zu behalten, weshalb das System auf mehrere interagierende Module statt auf eine einzige riesige Eingabeaufforderung ausgelegt wurde. Die 2026-Bewertung von Wiz kam aus einem anderen Blickwinkel zu einem ähnlichen Ergebnis: KI-Agenten schnitten bei fokussierten Aufgaben gut ab, zeigten aber deutliche Schwächen in umfassenderen, realistischeren Umgebungen, in denen sie Ziele priorisieren, Strategien unter Unsicherheit wählen und fehlgeschlagene Angriffslinien aufgeben mussten. Menschen schwenkten um. KI-Agenten wiederholten oft Variationen desselben Ansatzes. (arXiv)
Dieser Fehlermodus ist leicht zu unterschätzen, da er in der Niederschrift nicht immer wie ein Fehler aussieht. Das Modell bleibt flüssig. Die Befehle sehen immer noch plausibel aus. Der Berichtsentwurf klingt immer noch zuversichtlich. Aber das System könnte sich in einer Sackgasse befinden, während es den Anschein von Fortschritt erweckt. Bei Penetrationstests ist das gefährlich. Ein falsches positives Ergebnis ist ärgerlich. Ein falsches Gefühl der Abdeckung ist schlimmer. Ingenieure, die Pentest GPT-Produkte bewerten, sollten jedem Arbeitsablauf gegenüber ungewöhnlich skeptisch sein, der keine expliziten Zustandsübergänge, Aktionsbegründungen und Beweisschwellen für die Eskalation von "interessant" zu "verifiziert" aufzeigt. (arXiv)
Es gibt auch eine zweite Klasse von Fehlern, die nichts mit offensiven Techniken und alles mit der Sicherheit von Agenten zu tun hat. Das NIST beschreibt Agent-Hijacking als eine Form der indirekten Prompt-Injektion, bei der bösartige Anweisungen in Daten eingefügt werden, die ein KI-Agent aufnimmt, und ihn zu unbeabsichtigten schädlichen Aktionen veranlassen. Der Leitfaden von OpenAI ist ähnlich unverblümt: Prompt Injections sind weit verbreitet und gefährlich und können zur Exfiltration privater Daten oder zu falsch ausgerichteten Aktionen durch Tool-Aufrufe führen. Dies ist für Pentest-GPT-Systeme von enormer Bedeutung, denn in dem Moment, in dem das Modell nicht vertrauenswürdige Inhalte lesen und auch Werkzeuge bedienen kann, ist Prompt-Injection kein seltsamer Sprachmodell-Trick mehr, sondern wird zu einem Problem der Ausführungsoberfläche. (NIST)
Dieser Wandel ist der wichtigste Grund dafür, dass die Kategorie gereift ist. Die frühen Diskussionen über pentest gpt konzentrierten sich darauf, ob das Modell eine Web-Challenge durchschauen oder nützliche Befehle generieren kann. Heute geht es unter anderem darum, ob die Laufzeitumgebung böswillige Eingaben überleben kann, ob der Aufruf von Werkzeugen skaliert ist, ob Protokolle manipulationssicher sind, ob Schreibvorgänge eingeschränkt sind und ob das System Beobachtung von Autorisierung unterscheiden kann. Sobald KI echte Dateien, Shells, APIs und Browsersitzungen berührt, lautet das Problem nicht mehr: "Kann das Modell hilfreich sein?" Es lautet vielmehr: "Kann der Arbeitsablauf unter widrigen Bedingungen vertrauenswürdig bleiben?" (OpenAI-Entwickler)
Der Architekturunterschied zwischen einem Chatbot und einem echten Pentestsystem
In diesem Bereich ist der Markt noch sehr unübersichtlich. Ein Chatbot kann eine Schwachstellenklasse erklären und einen Befehl generieren. Ein echtes Pentest-System benötigt zusätzliche Schichten, die für den Bediener sichtbar und im Nachhinein überprüfbar sind. Es braucht Toolschemata oder Adapter, explizite Berechtigungsgrenzen, einen dauerhaften Zustand, strukturierte Ergebnisse, Genehmigungshaken für riskante Aktionen und einen reproduzierbaren Artefaktpfad. Die aktuellen Agentenrichtlinien von OpenAI spiegeln genau diesen mehrschichtigen Ansatz wider, einschließlich Sicherheitsvorkehrungen für risikoreiche Tools auf der Grundlage von Reversibilität, Berechtigungsstufe und potenziellen finanziellen oder betrieblichen Auswirkungen. (OpenAI-Entwickler)
Eine praktische Pentest-GPT-Architektur sieht in der Regel etwa so aus:
- Planungsebene - interpretiert Umfang und Zielkontext und zerlegt dann die Arbeit in Aufgaben.
- Ausführungsebene - ruft Scanner, HTTP-Clients, Browser, Skripte oder andere Tools auf.
- Staatliche Ebene - hält fest, was ausprobiert wurde, was sich geändert hat und was ungewiss bleibt.
- Validierungsschicht - prüft, ob die Beweise einen Schwellenwert erfüllen, bevor eine Feststellung getroffen wird.
- Kontrollschicht - setzt Genehmigungen, Ratenbeschränkungen, Zugriffsgrenzen und Prüfprotokolle durch.
- Berichtsebene - wandelt Beweise in reproduzierbare Ergebnisse und Anleitungen zur Abhilfe um.
Wenn ein Anbieter oder ein internes Tool diese Ebenen nicht klar erklären kann, ist das System wahrscheinlich eher ein intelligenter Assistent als ein ernsthafter Pentesting-Workflow. Das bedeutet nicht, dass es unbrauchbar ist. Es bedeutet nur, dass Sie es nicht so bewerten sollten, als wäre es bereits ein vertrauenswürdiger, autonomer Tester. (OpenAI-Entwickler)

Die CVEs, die bei pentest gpt von Bedeutung sind
Es gibt kein einzelnes "PentestGPT CVE", das diesen Bereich erklärt. Die wichtigere Lehre ergibt sich aus dem umgebenden Ökosystem. Sobald KI-Pentesting-Systeme agentenbasiert werden, erben sie die Risiken der sie umgebenden Frameworks, Orchestrierungsschichten, Webschnittstellen, Direktverbindungsfunktionen und Tool-Integrationslogik. Der jüngste CVE-Strom im Bereich LLM und Agenten-Tools macht dies sehr deutlich. (NVD)
| CVE | Betroffene Komponente | Warum dies für Pentest-GPT-Systeme wichtig ist |
|---|---|---|
| CVE-2025-68664 | LangChain | Ein Problem der Serialisierungsinjektion in dumps() und dumpd() gemeint sind benutzergesteuerte Daten mit lc Schlüssel bei der Deserialisierung als legitime Objekte behandelt werden könnten, was zeigt, wie Agenten-Frameworks Fehler beim Parsen von Daten in gefährliches Verhalten umwandeln können. (NVD) |
| CVE-2025-46059 | LangChain GmailToolkit | NVD beschreibt ein indirektes Prompt-Injection-Problem über manipulierte E-Mail-Inhalte, obwohl der Anbieter diese Charakterisierung bestreitet, weil die Codeausführung von unsicherem, vom Benutzer geschriebenem Code abhing. Selbst mit diesem Vorbehalt ist dies ein gutes Beispiel dafür, wie nicht vertrauenswürdige Inhalte den Arbeitsablauf eines Agenten steuern können. (NVD) |
| CVE-2025-3248 | Langflow | Ein entfernter, nicht authentifizierter Angreifer könnte die Schwachstelle ausnutzen. /api/v1/validate/code Endpunkt für die Ausführung von beliebigem Code in Versionen vor 1.3.0, was zeigt, wie Workflow-Funktionen auf niedriger Ebene zu direkten RCE-Oberflächen werden können. (NVD) |
| CVE-2025-34291 | Langflow | NVD beschreibt eine Schwachstellenkette, die die Übernahme von Konten und die Ausführung von Remotecode durch permissive CORS- und Refresh-Token-Behandlung ermöglicht, was insbesondere für browserbasierte Agent-Plattformen relevant ist. (NVD) |
| CVE-2025-64496 | WebUI öffnen | Böswillige externe Modellserver könnten in den Browsern der Opfer beliebiges JavaScript auslösen, was zu Token-Diebstahl, Kontoübernahme und Backend-RCE führt, wenn sie mit der Funktions-API verkettet sind. Dies ist genau die Art von Risiko, die Teams übersehen, wenn sie sich nur auf das Modell konzentrieren. (NVD) |
Diese CVEs sind nicht deshalb wichtig, weil sie alle zu Produkten gehören, die ausdrücklich als Pentest-Tools vermarktet werden. Sie sind wichtig, weil sie die tatsächliche Angriffsfläche jedes modernen Pentest-GPT-Stacks aufzeigen. Das Risiko ist nicht auf das Modellverhalten beschränkt. Es umfasst den Parser, die Web-UI, die Browsersitzung, den Direktverbindungsmechanismus, die Tool-Bridge und die Art und Weise, wie Anmeldeinformationen durch das System geleitet werden. Die Sicherheitsfrage lautet niemals nur "Wie intelligent ist das Modell?". Die Frage lautet vielmehr: "Was können feindliche Eingaben beeinflussen, welche Tools kann der Agent erreichen, und welche Beweise sind erforderlich, bevor das System handelt?" (OpenAI-Entwickler)
Ein realer Vorfall aus dem Jahr 2026 unterstreicht denselben Punkt, auch wenn es sich nicht um eine CVE handelt. Cline enthüllte, dass eine nicht autorisierte Partei ein kompromittiertes npm-Token verwendete, um cline@2.3.0Die Nachuntersuchung führte die Ursache auf einen KI-gesteuerten Problemtriage-Workflow zurück, der den Shell-Zugang in GitHub-Aktionen aufdeckte und so eine Prompt-Injection-to-Cache-Poisoning-Kette ermöglichte. Letztendlich wurde in dem veröffentlichten Paket kein bösartiger Code ausgeliefert, aber der Vorfall ist dennoch eine wertvolle Lektion darüber, wie agentengestützte Workflows bekannte Fehler in der Lieferkette verstärken können. (Cline)

Wie ein zuverlässiger Pentest-GPT-Arbeitsablauf aussehen sollte
Das erste Gestaltungsprinzip ist einfach: Beweise müssen wichtiger sein als Beredsamkeit. Ein Sprachmodell kann immer eine plausible Erklärung liefern. Es kann nur dann einen Befund fördern, wenn der Arbeitsablauf genügend Artefakte erfasst hat, um die Reproduzierbarkeit zu unterstützen. In der Praxis bedeutet dies, dass jeder Problemkandidat in ein strukturiertes Objekt mit Umfang, Angriffspfad, Beweisquelle, betroffenem Asset, Konfidenzniveau und Abhilfehinweisen umgewandelt wird. Freiform-Prosa ist für Berichte nützlich, aber sie sollte nicht die Quelle der Wahrheit sein. (OpenAI-Entwickler)
{
"find_id": "F-2026-0142",
"title": "Möglicherweise unsicherer direkter Objektverweis",
"status": "needs_validation",
"asset": "api.example.com",
"evidence": [
"GET /v1/invoices/3812 gab das Objekt eines anderen Benutzers zurück",
"Zugriff mit Sitzung mit geringen Rechten erfolgreich",
"Antwort enthielt nicht übereinstimmende account_id"
],
"Vertrauen": "mittel",
"erfordert_menschliche_Überprüfung": true,
"recommended_next_step": "Wiederholung mit neuer Sitzung und negativer Kontrolle"
}
Der zweite Grundsatz ist die Einstufung von Maßnahmen. Der aktuelle Leitfaden der OpenAI empfiehlt die Einstufung von Tools nach Risikomerkmalen wie Lese- oder Schreibzugriff, Reversibilität, Berechtigungen und finanzielle Auswirkungen. Dies ist direkt auf Pentesting-Systeme anwendbar. Eine Aufzählung gegen ein erlaubtes Ziel könnte ein geringes Risiko darstellen. Die Wiedergabe von Anmeldeinformationen, zustandsändernde Anfragen oder alles, was in die Infrastruktur schreibt, sollte ein mittleres oder hohes Risiko darstellen und explizite Genehmigungen erfordern. Ein Pentest-GPT, das alle Tools als gleichwertig behandelt, ist für den ernsthaften Einsatz nicht ausgereift genug. (OpenAI)
Werkzeuge:
http_get:
Risiko: niedrig
auto_execute: wahr
http_post_readonly_probe:
Risiko: mittel
auto_execute: falsch
approval_required: Analyst
shell_exec:
Risiko: hoch
auto_execute: falsch
approval_required: Leitung
browser_login:
Risiko: hoch
auto_execute: falsch
approval_required: Blei
Der dritte Grundsatz ist die Zustandsdisziplin. Das ursprüngliche PentestGPT-Projekt lehnte sich an die Modularität an, weil der Kontextverlust kein kosmetischer Fehler beim Pentesting ist. Er ist der Grund dafür, dass Agenten sich selbst wiederholen, Ketten übersehen und Schlussfolgerungen überbewerten. In operativen Systemen sollte der Zustand explizit sein und abgefragt werden können. Der Agent sollte wissen, welche Assets berührt wurden, welche Hypothesen abgelehnt wurden, welche Anmeldeinformationen verwendet wurden, welche Anfragen den Status geändert haben und welche Ergebnisse ungeprüft bleiben. Wenn dieser Zustand einen Neustart nicht übersteht oder unabhängig von der Modelltranskription überprüft werden kann, wird das System unter Druck abdriften. (arXiv)
Der vierte Grundsatz ist die kontrollierte Exposition gegenüber nicht vertrauenswürdigen Eingaben. NISTs Beschreibung von Agent Hijacking ist hier nützlich, weil sie auf den Konstruktionsfehler hinter dem Symptom hinweist: Das System schafft es nicht, vertrauenswürdige Anweisungen sinnvoll von nicht vertrauenswürdigen Daten zu trennen. In Systemen im Pentest-Gpt-Stil bedeutet dies, dass Scanner-Banner, HTML, Inhalte von Ausgaben, E-Mail-Textkörper, Protokolle, abgerufene Dokumente und von Browsern gerenderter Text alle als nicht vertrauenswürdig behandelt werden sollten. Sobald ein Modell diese Eingaben interpretieren und sofort Tools mit sinnvollen Berechtigungen aufrufen kann, wird Prompt Injection zu einem Fehler im Arbeitsablauf und nicht nur zu einer Eigenart des Modells. (NIST)
def promote_finding(candidate):
required = ["reproduction_steps", "negative_control", "impact_statement", "raw_artifacts"]
missing = [k for k in required if k not in candidate or not candidate[k]]
if missing:
return {"status": "needs_more_evidence", "missing": missing}
if candidate.get("writes_target_state", False):
return {"status": "menschliche_Überprüfung_erforderlich"}
return {"status": "verifiziert"}
Das fünfte Prinzip ist die menschliche Überprüfung in genau den Bereichen, in denen das menschliche Urteilsvermögen am stärksten ausgeprägt ist: Scoping, Abgrenzung von Privilegien, Interpretation der Auswirkungen auf das Geschäft und die endgültige Entscheidung, ein Ergebnis als verifiziert einzustufen. Die Arbeit von Wiz aus dem Jahr 2026 ist eine nützliche Erinnerung daran, dass Menschen immer noch besser sind als KI-Agenten, wenn die Aufgabe eher strategische Umstellungen als lokale Iterationen erfordert. Dies ist keine Schwäche reiner KI-Systeme, die über Nacht verschwinden wird. Es handelt sich um ein strukturelles Merkmal der aktuellen Tooling-Landschaft. Gute Teams sollten diese Schwäche ausnutzen, anstatt so zu tun, als ob die Autonomie dieses Problem bereits gelöst hätte. (wiz.io)
Warum der Mensch in der Schleife immer noch wichtig ist
Der Ausdruck "Human-in-the-Loop" wird überstrapaziert, aber in dieser Kategorie ist er immer noch zutreffend. Die stärksten neueren Erkenntnisse besagen nicht, dass KI-Agenten schwach sind. Sie sagen, dass sie ungleichmäßig sind. Sie können unter eingeschränkten Bedingungen umfangreiche Offensivaufgaben automatisieren, aber für realistische Einsätze brauchen sie immer noch menschliche Unterstützung. Diese Unterscheidung geht bei Produktdemonstrationen leicht verloren, wenn dem Modell ein klares Ziel, eine enge Problemstellung und eine nachsichtige Bewertungsumgebung vorgegeben werden. Echte Pentests sind nicht so. Sie beinhalten einen unvollständigen Umfang, unklare Eigentumsverhältnisse, verrauschte Assets, instabile Ziele, eine weiche Geschäftslogik und die Notwendigkeit zu entscheiden, wann nicht um fortzufahren. (wiz.io)
Aus diesem Grund ist die beste kurzfristige Anwendung von Pentest GPT nicht "das Prüfgerät ersetzen". Es ist "den Zyklus zwischen Signal und Beweis zu komprimieren". Ein gutes System hilft dem menschlichen Tester, die richtige Gabelung im Baum schneller zu erreichen, diese Gabelung systematischer zu testen und das Ergebnis sauberer zu dokumentieren. Es ist besonders stark, wenn der Engpass eher in der Übersetzung oder Koordination als in der Intuition liegt. Sie ist schwächer, wenn der Engpass im strategischen Urteilsvermögen oder in der gegnerischen Prioritätensetzung unter Unsicherheit liegt. Diese Grenzen sollten nicht als Enttäuschung verstanden werden. Sie sollten als Hinweis darauf verstanden werden, dass die Ingenieursarbeit immer noch eine Hebelwirkung hat. (arXiv)
In diesem Sinne ist die interessanteste kommerzielle Entwicklung von "pentest gpt" nicht die Chatbot-Ebene. Es ist der Schritt in Richtung evidenzbasierte agentengestützte Arbeitsabläufe. Die öffentliche Positionierung von Penligent ist eindeutig auf diese Lücke ausgerichtet. Auf der Homepage des Unternehmens wird das Produkt als KI-gestütztes Penetrationstest-Tool beschrieben, das auf der Grundlage von Eingabeaufforderungen in natürlicher Sprache arbeitet und dabei verifizierte Ergebnisse und saubere Berichte erstellt. Das Unternehmen selbst unterscheidet zwischen dem ursprünglichen PentestGPT-Projekt und der breiteren Kategorie der LLM-basierten Pentesting-Produkte. Das ist die richtige Unterscheidung, die getroffen werden muss. Der Markt braucht nicht mehr Systeme, die nur Befehle schreiben. Er braucht Systeme, die den Kreislauf von der Argumentation zum reproduzierbaren Beweis schließen. (Sträflich)
Was diese Richtung vertretbarer macht, ist nicht einfach Autonomie. Es ist die produktbezogene Validierung. Penligents kürzlich erschienenes umfangreiches Material über KI-Pentesting und agentenbasiertes Red Teaming umrahmt die Kategorie mit Laufzeitausführung, Beweiserfassung und praktischer Verifizierung und nicht mit allgemeiner KI-Begeisterung. Unabhängig davon, ob man sich für diese Plattform entscheidet oder nicht, ist die allgemeine Erkenntnis richtig: Die zukünftigen Gewinner in diesem Bereich werden nicht die lautesten "KI-Hacker"-Demos sein. Es werden die Systeme sein, die dafür sorgen, dass sich Verifizierung, Überprüfbarkeit und Berichtsqualität wie ein fester Bestandteil des Arbeitsablaufs anfühlen und nicht wie ein nachträglich aufgesetztes Element. (Sträflich)
Der praktische Standard, den Sicherheitsteams verwenden sollten
Wenn ein Sicherheitsteam ein Pentest-GPT-Tool evaluiert oder beschließt, ein solches intern zu entwickeln, lautet die richtige Checkliste nicht "Sieht es intelligent aus?". Die bessere Checkliste ist eher operativ.
Wird ein dauerhafter Zustand über den gesamten Lebenszyklus des Engagements aufrechterhalten? Schränkt sie riskante Aktionen ein. Erfasst es rohe Beweise, bevor es Schlussfolgerungen schreibt. Widersteht es der prompten Einspeisung von nicht vertrauenswürdigen Inhalten oder hält es diese zumindest zurück? Legt es die Werkzeugebene klar genug offen, um Entscheidungen zu überprüfen? Trennt es Hypothese, Validierung und abschließende Berichterstattung. Behält der Mensch die Kontrolle, wenn es um Privilegien und geschäftliche Auswirkungen geht. Wenn die Antwort auf diese Fragen schwach ausfällt, kann das System zwar als Assistent nützlich sein, aber als Pentesting-Workflow-Engine ist es noch nicht vertrauenswürdig. (OpenAI-Entwickler)
Die stärkste Erkenntnis aus den letzten zwei Jahren ist nicht, dass Pentest GPT ein Hype ist, und auch nicht, dass es bereits Fachleute ersetzt hat. Die Kategorie ist real, der Wert ist real, und die Fehlermöglichkeiten sind jetzt konkret genug, um sie zu umgehen. Die ursprüngliche PentestGPT-Arbeit hat bewiesen, dass LLMs die Leistung von Teilaufgaben bei Penetrationstests sinnvoll verbessern können. Moderne Agenten-Tools haben bewiesen, dass Modelle in zunehmendem Maße Tools aufrufen und in nützlicher Größenordnung arbeiten können. Jüngste CVEs und Vorfälle haben bewiesen, dass die umgebende Architektur zum Hauptthema der Sicherheit wird, sobald diese Systeme echte Laufzeiten erreichen. Nimmt man diese Punkte zusammen, so ist die Schlussfolgerung klar: Pentest GPT ist nicht länger ein neuer Begriff. Es ist jetzt ein Designproblem. (arXiv)
Die Teams, die am meisten davon profitieren werden, sind nicht diejenigen, die die autonomste Demo verfolgen. Sie sind diejenigen, die den kürzesten und sichersten Weg von der Beobachtung zum verifizierten Ergebnis bauen. Das bedeutet eine bessere Handhabung von Zuständen, strengere Werkzeuggrenzen, stärkere Validierungsrichtlinien und weniger Toleranz für eine sichere Prosa ohne Artefakte. Im Jahr 2026 ist das die eigentliche Trennlinie zwischen einem Pentest-GPT, das beeindruckend aussieht, und einem, das tatsächlich in einen ernsthaften Sicherheits-Workflow gehört. (wiz.io)
Weitere Lektüre
PentestGPT, Evaluating and Harnessing Large Language Models for Automated Penetration Testing, USENIX Security 2024. (arXiv)
PentestGPT GitHub-Repository, aktuelle Projektposition und Versionskontext. (GitHub)
OpenAI, Anleitung zum Funktionsaufruf. (OpenAI-Entwickler)
OpenAI, Sicherheit bei Gebäudeagenten. (OpenAI-Entwickler)
OpenAI, Ein praktischer Leitfaden zur Erstellung von Agenten. (OpenAI)
NIST, Verstärkung von AI Agent Hijacking Evaluierungen. (NIST)
OWASP Top 10 für große Sprachmodellanwendungen. (OWASP)
Wiz, KI-Agenten gegen Menschen: Wer gewinnt beim Web-Hacking im Jahr 2026? (wiz.io)
NVD, CVE-2025-68664. (NVD)
NVD, CVE-2025-46059. (NVD)
NVD, CVE-2025-3248. (NVD)
NVD, CVE-2025-34291. (NVD)
NVD, CVE-2025-64496. (NVD)
PentestGPT vs. Penligent AI in realen Einsätzen Von LLM Writes Commands zu Verified Findings. (Sträflich)
Der ultimative Leitfaden für KI-Penetrationstests 2026, Das Zeitalter des Agentic Red Teaming. (Sträflich)
KI-Agenten, die sich im Jahr 2026 hacken, verteidigen die neue Ausführungsgrenze. (Sträflich)
Sicherung von Agentenanwendungen in der MCP-Ära. (Sträflich)

