AI-unterstützte Pentests realistisch bewerten

AI kann einen Penetrationstest beschleunigen, aber sie macht aus einem unkontrollierten Scan keinen belastbaren Sicherheitsnachweis. Der sinnvolle Einsatz liegt in klar begrenzten Aufgaben: Informationen strukturieren, Hypothesen bilden, bekannte Werkzeuge bedienen und Evidenz für eine menschliche Bewertung vorbereiten.

Wo AI heute praktisch hilft

In einem autorisierten Test fallen viele Informationen an: Hosts, Technologien, Endpunkte, Rollen, Requests, Antworten und Fehlermeldungen. Ein Modell kann diese Daten gruppieren und auffällige Beziehungen sichtbar machen. Es kann Testideen aus einer API-Beschreibung ableiten oder Unterschiede zwischen Rollen zusammenfassen.

Weitere geeignete Aufgaben sind:

Recon-Ergebnisse normalisieren und priorisieren,
Parameter und Datenflüsse aus Requests extrahieren,
Hypothesen für Zugriffskontrolle und Zustandswechsel formulieren,
Quellcodebereiche für eine manuelle Prüfung eingrenzen,
reproduzierbare Schritte aus bestätigter Evidenz dokumentieren,
ähnliche Befunde nach einer Korrektur erneut prüfen.

Diese Unterstützung spart Zeit, solange das System seine Unsicherheit nicht als bestätigte Schwachstelle ausgibt.

Warum Modellwissen keinen Pentest ersetzt

Ein realer Angriffspfad hängt vom fachlichen Kontext ab. Dass Nutzer A eine fremde ID abrufen kann, ist nur dann relevant, wenn Objekt, Rolle und Auswirkung verstanden sind. Mehrstufige Fehler entstehen häufig durch die Kombination legitimer Funktionen, nicht durch ein einzelnes verdächtiges Muster.

Modelle neigen außerdem zu plausiblen, aber nicht belegten Behauptungen. Sie können einen Statuscode falsch deuten, Schutzmaßnahmen übersehen oder eine bekannte Payload ohne passende Voraussetzung vorschlagen. Ein Finding benötigt deshalb mindestens:

einen erlaubten Scope,
reproduzierbare Schritte,
konkrete technische Evidenz,
realistische Auswirkung,
eine priorisierbare Ursache und Korrektur.

Ohne diese Bestandteile bleibt das Ergebnis eine Hypothese.

Werkzeuge nur in einem autorisierten Rahmen

Ein Pentest-Agent darf Ziele nicht frei aus Text übernehmen. Domains, IP-Bereiche, Nutzerkonten, erlaubte Testarten und Zeitfenster werden außerhalb des Modells als feste Regeln hinterlegt. Aktive Werkzeuge laufen isoliert und mit Limits für Anfragen, Laufzeit und Parallelität.

Grenze	Beispiel
Ziel	nur vereinbarte Hosts und APIs
Methode	keine Denial-of-Service-Tests ohne Freigabe
Identität	getrennte Testkonten je Rolle
Daten	keine unnötige Sammlung produktiver Inhalte
Laufzeit	Rate Limits und kontrollierter Abbruch
Ausgabe	Findings erst nach menschlicher Bestätigung

Das Modell kann diese Regeln nicht überschreiben. Auch Text aus einer Zielanwendung ist untrusted content und darf keine neue Aktion autorisieren.

Lokale Modelle für sensible Testdaten

Requests, Quellcode und Schwachstellendetails gehören zu den sensibelsten Projektdaten. Lokale Inferenz verhindert, dass sie zur Verarbeitung an einen externen Modellanbieter gesendet werden. Dafür müssen Modellserver, Logs, Dateispeicher und Werkzeugumgebung selbst geschützt sein.

Nicht jede Aufgabe benötigt das größte Modell. Ein kleineres lokales Modell kann Klassifikation, Extraktion und strukturierte Dokumentation zuverlässig übernehmen. Für komplexe Hypothesen werden verschiedene Modelle anhand autorisierter realer Fälle evaluiert. Ein öffentlicher Benchmark ersetzt diesen Vergleich nicht.

Qualität mit bekannten Fällen prüfen

Ein AI-gestützter Testprozess braucht einen Korpus aus legal nutzbaren, realistischen Fällen. Dabei wird nicht nur geprüft, ob eine Schwachstelle gefunden wird. Ebenso wichtig sind Fehlalarme, unnötige Aktionen, Evidenzqualität, Laufzeit und korrekter Abbruch.

Mögliche Metriken:

Anteil bestätigter Findings,
Recall auf bekannte Angriffspfade,
Zahl gefährlicher oder scope-fremder Aktionen,
Zeit bis zur verwertbaren Hypothese,
Vollständigkeit der Reproduktionsschritte,
Ergebnisunterschiede zwischen Modellversionen.

Die finale Bewertung bleibt bei einem erfahrenen Pentester. Gerade diese Verbindung aus Automatisierung und offensiver Erfahrung macht die Unterstützung nützlich.

Kommunikation gegenüber Auftraggebern

Ein Angebot sollte klar benennen, wo AI eingesetzt wird, welche Daten lokal bleiben, wer Findings bestätigt und welche Grenzen gelten. „AI-Pentest“ darf kein Etikett für einen automatisierten Scanner sein. Auftraggeber benötigen dieselben belastbaren Ergebnisse wie bei jedem guten Test: bestätigte Schwachstellen, nachvollziehbare Wirkung, umsetzbare Korrektur und Nachtest.

Das Evidenz-Gate vor einem Finding

Eine maschinell erzeugte Hypothese darf erst dann in den Bericht gelangen, wenn sie dieses Gate passiert:

Ziel, Konto, Zeitpunkt und Methode lagen innerhalb der Rules of Engagement.
Der Effekt wurde reproduziert und ist nicht nur aus Statuscode oder Fehlermeldung abgeleitet.
Request, Response und notwendiger Zustand sind minimal und nachvollziehbar dokumentiert.
Sensible Daten wurden nur so weit erhoben, wie der Beleg es erfordert.
Auswirkung und Voraussetzungen beziehen sich auf das geprüfte System, nicht auf ein allgemeines Schwachstellenmuster.
Ein erfahrener Pentester hat Fehlalarm, Duplikat und naheliegende Gegenkontrolle geprüft.
Die Korrektur adressiert die Ursache, und ein Nachtest lässt sich aus der Evidenz ableiten.

Scheitert ein Punkt, bleibt das Ergebnis eine Hypothese im Arbeitsprotokoll. Diese Trennung ist zentral: AI kann die Zahl guter Testideen erhöhen. Sie darf nicht die Zahl unbelegter Findings erhöhen.

Vor einem realen Auftrag hilft die Checkliste Penetrationstest richtig vorbereiten. Nach einem bestätigten Befund führt Security-Findings priorisieren und beheben von der Evidenz zum Regressionstest.

Quellen und Vertiefung

Fazit

AI ist im Pentest ein Verstärker für klar definierte Arbeit, kein Ersatz für Scope, Erfahrung und Beweise. Lokale Modelle schützen sensible Daten, kontrollierte Werkzeuge begrenzen Aktionen und menschliche Verifikation macht aus einer Hypothese ein belastbares Finding.