Autonome KI-Pentester im Praxistest: Was heute funktioniert, was (noch) nicht – und wo das echte Potenzial liegt

Seit LLMs und KI-Agenten in der Lage sind, selbstständig Tools auszuführen und ihre eigenen Ergebnisse zu interpretieren, ist ein Narrativ im Markt entstanden, dem ich in Kundengesprächen und vor allem auf LinkedIn immer häufiger begegne: Autonome KI-Pentester. Systeme, die angeblich ohne menschliche Aufsicht eine vollständige Penetrationstest-Phase abbilden können: Von der Enumerierung bis zur Exploitation, autonom, konsistent, nachvollziehbar.

Genau deshalb haben wir Strix und PentAGI im Praxistest geprüft. Nicht im Labor, nicht auf einer simplen Demo-Umgebung, sondern mit dem Maßstab, den wir an jeden Pentest anlegen, der hier bei binsec läuft: Ist das Ergebnis konsistent, reproduzierbar und belastbar?

Die Antwort ist differenziert, aber eindeutig: OSINT geht gut, teilweise auch Exploitation funktionieren. Vollautonomie ist in der Praxis inkonsistent und total unzuverlässig. Das Potenzial liegt daher nicht darin, den Pentester zu ersetzen, sondern ihn zu unterstützen, und dabei einzelne, kleine Teilschritte eines Pentests zu automatisieren.

Was wir getestet haben

Für den Praxistest haben wir zwei vollautonome Systeme herangezogen, die in der Community und im Markt regelmäßig als „autonome Pentester“ genannt werden:

  • Strix
  • PentAGI

Beide Systeme basieren auf dem gleichen Grundprinzip: Ein LLM-gesteuertes Agenten-System führt selbstständig Aufgaben durch – Enumerierung, Analyse, teilweise Ausnutzung – ohne dass ein Pentester jeden Schritt steuert. Der Anspruch ist klar: Der Mensch definiert Scope und Ziel, die KI macht den Rest.

Das Gesamtbild: Teilschritte ja, Vollautonomie nein

Beide Systeme konnten in unseren Tests einzelne Teilschritte eines Penetrationstests abbilden. Enumerierung von Diensten und Endpunkten funktioniert grundsätzlich. Teilweise ist auch Exploitation möglich.

Das Problem ist nicht, dass die Systeme nichts können. Das Problem ist, dass sie nicht zuverlässig und nicht konsistent liefern. Ein autonomer Agent, der bei identischem Scope mal ein belastbares Ergebnis produziert und beim nächsten Lauf nichts davon wiederfindet, ist für die Praxis unbrauchbar. Ein Pentest ist keine Einmal-Chance. Er ist ein kontrollierter Prozess, und genau das fehlt der aktuellen Generation autonomer Agenten grundlegend.

Strix im Test: Funktionierendes Kern-Feature, reifes Interface nicht in Sicht

Strix hat in unseren Tests gezeigt, dass es unter bestimmten Bedingungen Schwachstellen in Code oder auf Webservern finden kann. Das ist kein Selbstläufer, aber die Grundfunktionalität ist da.

Allerdings war das Ergebnis nicht zuverlässig und nicht konsistent. Ob eine bekannte Schwachstelle gefunden wurde oder nicht, hing stärker vom Lauf ab, als es für einen belastbaren Testprozess tragbar ist.

Deutlich sichtbarer wurde das Problem aber auf der Interface-Seite. Die Nutzerumgebung von Strix ist nicht produktionsreif:

  • Das Interface enthält Bugs.
  • Strix stürzt teilweise ab, insbesondere bei unerwarteten Ausgaben der KI.
  • Der einzige Output ist eine Markdown-Datei ohne feste Struktur.

Für einen professionellen Pentest-Prozess ist das ein entscheidendes Kriterium. Ein Testergebnis, das als unstrukturierter Markdown-Text ohne festen Aufbau geliefert wird, lässt sich weder in einen belastbaren Bericht überführen noch ist es für Auftraggeber, Management und IT-Betrieb in gleicher Weise nutzbar. Ein guter Pentest-Bericht folgt einem klaren Aufbau, priorisiert Findings, ordnet Risiken ein und macht Maßnahmen ableitbar. Genau das liefert der Output von Strix in dieser Form nicht.

PentAGI im Test: Reifer von der Oberfläche, aber mit klaren Grenzen

PentAGI wirkt von der Oberfläche her produktionsreifer als Strix. Die Task-Organisation ist besser, die Struktur der Abläufe ist nachvollziehbarer. Wer die beiden Systeme direkt vergleicht, merkt sofort, dass PentAGI weiter ist in der Frage, wie die Arbeit organisiert wird.

Doch bei genauerem Hinsehen zeigt sich dasselbe Grundproblem wie bei Strix: Inkonsistenz.

Im Lauf haben wir mehrere konkrete Probleme beobachtet:

  • Flows pausieren teilweise, wenn sie im Hintergrund laufen sollen.
  • Agenten machen oft mehr als die aktuelle Aufgabe, wodurch viel doppelt ausgeführt wird.
  • Scope-Probleme: PentAGI scannte teilweise IPs und Ports, die nicht vorgegeben waren.

Letzteres ist der Punkt, der für uns den Ausschlag gibt. Ein autonomer Agent, der sich außerhalb des definierten Scopes bewegt, ist für einen professionellen Penetrationstest nicht einsetzbar. Ein Pentest läuft immer innerhalb eines klaren, vertraglich abgegrenzten Scopes. Wer außerhalb dieses Scopes aktiv wird, verlässt den Rahmen, in dem der Test erlaubt ist. Das ist nicht nur eine methodische Schwäche, das ist ein kritisches Problem!

Warum reale Umgebungen mehr sind als typische Test Cases

Noch wichtiger als die Frage nach der Konsistenz der Ergebnisse ist die Frage, wo autonome KI-Agenten überhaupt sinnvoll zum Einsatz kommen könnten. Denn die Realität eines Pentests ist deutlich komplexer, als es die meisten der genannten Systeme abbilden können.

Die meisten Tests für KI-Pentests laufen gegen externe Infrastrukturen oder öffentliche Web-Anwendungen. Das ist der einfachste Fall: Die Angriffsfläche ist klar abgegrenzt, die Systemgrenzen sind technisch sichtbar, und ein Ausritt des Agenten bleibt relativ beherrschbar, weil er sich ohnehin nur dort bewegen kann, wo man ihn kontrollieren kann.

Ein interner Einsatz stellt hier deutlich höhere Anforderungen. Intern gibt es keine technische Kante, die einen Agenten automatisch stoppt. Grenzen und Rahmenbedingungen müssen hier rein vertraglich und organisatorisch eingehalten werden, und genau da scheitert die aktuelle Generation autonomer Agenten, wie wir bei PentAGI gesehen haben. Je größer das interne Segment, desto größer ist auch der potenzielle Schaden, den ein Agent anrichten kann, der sich nicht an seine Grenzen hält.

Und die Umgebung selbst ist selten so einfach, wie sie in Test Cases erscheint. Das Zusammenspiel zwischen verschiedenen Systemen z.B. bestehend aus API, Web App, Mobile App, Drittsysteme kann ein Vielfaches komplexer sein als jede typische, isolierte Test Case. Ein Schwachstellenpfad, der über mehrere Systeme hinweg verläuft, erfordert ein Verständnis von Kontext, Abhängigkeiten und Berechtigungsmodellen, das autonome Agenten heute nicht zuverlässig liefern.

Hardware-nahes Testing geht aus Prinzip gar nicht. Bluetooth-Schnittstellen, medizinische Geräte, IoT-Systeme, industrielle Steuerungen. Überall dort, wo ein Pentest auf die physische Schiene geht, brauchen wir Messgeräte, Spezialwerkzeuge und ein manuelles Vorgehen, das ein Software-Agent nicht abbilden kann. Das ist kein Nachteil der aktuellen KI, das ist eine prinzipielle Grenze.

Warum Vollautonomie (noch) nicht trägt

Die beiden Systeme teilen sich ein Muster, das wir aus der Praxis gut kennen: Sie können Teilaufgaben lösen, aber sie können keinen Prozess tragen.

Ein Penetrationstest ist keine Kette voneinander unabhängiger Aufgaben. Er ist ein gesteuerter Prozess mit definiertem Scope, klaren Zielsetzungen, kontrollierter Durchführung und nachvollziehbarer Bewertung. Was autonome Agenten heute liefern, sind Bruchstücke: Mal gut, mal schlecht, mal im Scope, mal außerhalb, mal dokumentiert, mal reproduzierbar, mal nicht.

Das ist das eigentliche Problem. Nicht, dass die KI heute schwächer ist als ein erfahrener Pentester, das wäre sie in den meisten Fällen ohnehin. Auch wenn sie bei manchen einfachen Tasks einfach schneller sein kann. Das eigentliche Problem ist, dass Konsistenz, Nachvollziehbarkeit und Scope-Disziplin fehlen. Und genau diese drei Dinge machen einen Penetrationstest zu einem belastbaren Ergebnis und nicht zu einer AI Pentesting Lotterie.

Wo das Potenzial tatsächlich liegt

Das bedeutet nicht, dass KI im Pentesting keine Rolle spielt. Im Gegenteil. Aber die Rolle ist eine andere als die, die der Markt derzeit verspricht.

Das echte Potenzial liegt nicht im autonomen Agenten, der den Pentester ersetzt. Es liegt in der Unterstützung des Pentesters und in der Automatisierung einzelner, kleiner Teilschritte:

  • Automatisierte Enumerierung: Wiederkehrende, zeitaufwändige Aufgaben wie die Erfassung von Endpunkten, Diensten oder Konfigurationen lassen sich zuverlässig automatisieren.
  • Ergebnisanalyse und -aufbereitung: Das Sichten großer Datenmengen, das Filtern von Daten, das Erstellen eigener API-Doku von Kundenanwendungen, hier kann KI hervorragend unterstützen.
  • Dokumentationsunterstützung: Die Aufbereitung von Rohdaten in strukturierte Berichte, die Durchführung einer Qualitätskontrolle des Berichts auf logische Fehler, Rechtschreibung- und Grammatikfehler. Das entlastet den Pentester in der Phase, die am wenigsten Spaß macht, aber selbst mit Tools wie PTDoc immernoch Zeit bindet.

Genau dort ist der Mehrwert. Nicht im „autonomen Pentest“, sondern im effizienteren, strukturierten Pentest, bei dem der Mensch die Kontrolle behält und die KI die lästige Fleißarbeit übernimmt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert