AI Swarm Pentest

Ein klar abgegrenzter, autorisierter Auftrag

AI Swarm Pentest ist der Schritt Validieren in Proof-Driven AppSec. Bevor Plexicus dir hilft, eine Schwachstelle im Code zu verstehen (Deep Code Analysis, Modul 5) oder zu beheben (Remediation, Modul 7), zeigt es dir, welche Angriffspfade in einer laufenden Anwendung real sind. Im Produkt heißt AI Swarm Pentest AI Pentest und hat in der Seitenleiste einen eigenen Eintrag Pentest.

Ein Pentest schickt echten Traffic an ein echtes System, deshalb beginnt alles mit der Autorisierung.

Einsatzregeln

Ein AI Swarm Pentest umfasst eine autorisierte Anwendung, eine API, Quellcode oder eine Testumgebung. Bevor die Arbeit beginnt, werden Ziel, Testzugang und Einsatzregeln schriftlich vereinbart, und Plexicus handelt nicht außerhalb dieses Scopes. In der Praxis beantworten deine Einsatzregeln vier Fragen:

• Was im Scope liegt: die genaue URL oder Domain der Anwendung und welche Umgebung (Staging oder Produktion).
• Welchen Testzugang du bereitstellst, falls überhaupt: keinen, ein dediziertes Testkonto oder Test-API-Keys bzw. -Header (Lektion 4 erklärt, warum du nicht davon ausgehen solltest, dass sie genutzt werden).
• Was tabu ist: zum Beispiel Konten löschen, E-Mails oder SMS versenden oder Zahlungen einziehen.
• Wer entscheidet, was mit den Ergebnissen passiert.

Wenn dein Team AI Pentest in der Plattform ausführt, schreibt und genehmigt ihr diese Regeln intern. Der Assistent erfasst einen Teil davon: das Ziel, die Authentifizierungseinstellungen, die Out-of-Scope-Punkte und das Briefing.

Was er ist und was nicht

AI Swarm Pentest nutzt koordinierte KI-Prüfungen, die deine Anwendung kartieren, Hypothesen bilden, Angriffspfade testen und ihren Ergebnissen Evidenz anhängen. Er automatisiert repetitives Erkunden, Korrelieren und Reproduzieren. Dein Team behält den Kontext, die Aufsicht und die endgültige Entscheidung.

Er ist nicht:

• ein Signatur-Scanner, der bekannte Muster abgleicht,
• ein Security-Chatbot, der Antworten vorschlägt,
• eine Prüfung, die ohne unterzeichneten Scope läuft,
• ein klassischer, mehrtägiger Pentest durch Menschen vor Ort,
• eine endlose Liste unpriorisierter „potenzieller Probleme“,
• ein Tool, das die Produktion automatisch verändert.

Wenn sich nichts bestätigen lässt, werden die Ergebnisse nicht mit theoretischen Alerts aufgefüllt. Plexicus verspricht nicht, dass es keine Schwachstellen gibt. Es verspricht, dass sich alles, was als verifiziert präsentiert wird, nachweisen lässt.

Die vier Leitplanken

Die vier Leitplanken aus Modul 1 (schriftlich vereinbarter Scope, nachvollziehbare Evidenz, Auftragsgrenzen und menschliche Entscheidung) gelten für jeden Lauf. In der Praxis setzt der Assistent sie so um:

Der Assistent übergibt dem Agenten einen engen Scope: nur den Host der Ziel-URL selbst, ohne zusätzliche Domains, auf den Ports 80 und 443 sowie jedem Port, der in der URL angegeben ist. Destructive actions ist im letzten Schritt des Assistenten als außerhalb des Scopes vorausgewählt. Jeder Punkt, den du als außerhalb des Scopes auswählst, erreicht den Agenten als schriftliche Anweisung, ihn nicht auszuführen. Das ist eine Anweisung, keine technische Sperre, also kombiniere sie mit einem Staging-Ziel und Test-Zahlungsmitteln. Jede Tiefe, auch Quick, schickt echte Requests an das Ziel.

Wie der Schwarm arbeitet

Ein Signatur-Scanner vergleicht deine Anwendung mit bekannten Mustern und sagt dir, wo du suchen sollst. Ein Security-Chatbot beantwortet Fragen auf Basis des Kontexts, den du ihm gibst. AI Swarm Pentest tut weder das eine noch das andere. Er erkundet Pfade, testet Hypothesen und hängt Evidenz an, damit du priorisieren kannst, was Aufmerksamkeit verdient.

Die Arbeit ist auf koordinierte KI-Prüfungen verteilt. Sie kartieren die Angriffsfläche, bilden Hypothesen und testen Angriffspfade innerhalb des vereinbarten Scopes, und ein zweiter Durchlauf bestätigt jeden Befund unabhängig, bevor er als verifiziert markiert wird. Im Produkt läuft der Pentest-Agent von Plexicus gegen deine Ziel-URL, gesteuert durch das Briefing, das du im Assistenten schreibst (Lektion 4). Tiefere Scan-Modi erlauben längere Läufe und mehr Aufwand des Agenten. Während ein Lauf aktiv ist, zeigt der War room (live board) auf der Laufseite die Aktivität des Schwarms.

Vom Signal zum verifizierten Befund

Der Auftrag ist so angelegt, dass eine einzelne Prüfung nie ausreicht, um etwas als verifiziert zu bezeichnen. Ein Ergebnis durchläuft drei Phasen:

1. Möglicher Befund. Eine Hypothese erzeugt ein Signal mit technischem Kontext.
2. Unabhängige Verifizierung. Ein zweiter Durchlauf versucht, das beobachtete Verhalten eigenständig zu bestätigen.
3. Verifizierter Befund. Nur ein bestätigtes Ergebnis wird als verifiziert präsentiert, mit seiner Auswirkung und einer Priorität, die auf dem realen Risiko beruht (Schweregrad plus Kontext), nicht auf der Reihenfolge des Eintreffens.

Nach dem Evidenzstandard wird ein Ergebnis, das ein zweiter Durchlauf nicht reproduzieren kann, nicht als verifizierter Befund präsentiert. Es wird als unverifiziert markiert oder verworfen. Das ist die Regel aus Modul 1: Ohne reproduzierbaren Nachweis kein verifizierter Befund.

Im Produkt bezieht sich das Badge Unverified in der Pentest-Liste auf das Eigentum am Ziel (Lektion 3), nicht auf Befunde. Lies es nicht als Urteil über einen Befund.

Was das beim Lesen der Ergebnisse bedeutet

Aus diesem Design ergeben sich zwei praktische Konsequenzen.

Wenige Befunde sind ein Ergebnis, kein Fehlschlag. Ein Lauf, der endet, weil er sein Zeit- oder KI-Budget erreicht hat, wird trotzdem als Completed markiert. Ein Completed-Lauf mit wenigen oder keinen Befunden zeigt dir, was der Schwarm in diesem Zeitfenster bestätigen konnte und was nicht. Er beweist nicht, dass das Ziel erschöpfend getestet wurde. Steuere den nächsten Lauf gezielter: mit einem tieferen Scan, konkreten Fokusbereichen und einem klareren Briefing.

Menschliches Review gilt weiterhin. Pentest-Befunde durchlaufen dieselbe KI-Validierung wie andere Plexicus-Befunde, einschließlich des KI-Urteils und der False-Positive-Analyse aus den Modulen 4 und 5. Wenn du einem Urteil nicht zustimmst, nutze Mark as false positive. Die Aktion nimmt keine schriftliche Begründung auf, also halte deine Begründung im Ticket oder in den Notizen deines Teams fest. Nichts erreicht die Produktion ohne eine Entscheidung deines Teams.

Wenn deine Organisation einen eigenen KI-Anbieter konfiguriert hat, nutzt der Pentest-Agent diesen Anbieter. Andernfalls nutzt er ein von Plexicus verwaltetes Modell. Kundencode wird nicht zum Training von KI-Modellen verwendet.

Nachweisen, dass dir das Ziel gehört

Bevor der Agent auch nur einen Request sendet, verlangt Plexicus einen Nachweis, dass du das Ziel kontrollierst. Launch AI Pentest bleibt deaktiviert, bis das Eigentum verifiziert ist, und der Server lehnt nicht nachgewiesene Ziele ab, selbst wenn jemand die Oberfläche umgeht.

Warum das Akzeptieren von Bedingungen kein Nachweis ist

Nutzungsbedingungen zu akzeptieren ist eine Erklärung, keine Evidenz. Jeder kann Bedingungen für eine Domain akzeptieren, die er nicht kontrolliert, deshalb wertet Plexicus das nicht als Autorisierung. Weil der Agent Live-Traffic sendet, der den Zustand des Ziels verändern kann, akzeptiert Plexicus nur Nachweise, für die du am Ziel selbst etwas ändern musst: ein Token in seinem HTML, in einer Datei, die es ausliefert, oder in seinem DNS.

Zwei Scopes, drei Methoden

Im Schritt Verify ownership des Assistenten wählst du einen Scope:

Scope	Methode	Deckt ab	Am besten für
Verify this application	HTML-Meta-Tag oder eine Datei unter /.well-known/	Nur genau diesen Host	Eine App, schnellster Weg
Verify the whole domain	DNS-TXT-Record	Die Domain und jede aktuelle und künftige Subdomain	Teams, die viele Apps auf einer Domain testen

Die Prüfung beim Start akzeptiert beide Nachweise. Eine verifizierte Domain deckt die Domain selbst und alle ihre Subdomains ab. Eine verifizierte Anwendung deckt genau diesen Host ab.

Eine Anwendung verifizieren

Der Assistent zeigt ein Verification token. Veröffentliche es auf eine von zwei Arten. Entweder fügst du diesen Meta-Tag in die Zielseite ein, exakt wie angezeigt kopiert, mit name vor content:

<meta name="plexicus-site-verification" content="YOUR-TOKEN">

Oder du lieferst unter /.well-known/plexicus-verification.txt eine Datei aus, die das Token enthält. Klick dann auf Recheck. Plexicus prüft beides automatisch: zuerst die Datei am Origin der Site, dann den Meta-Tag auf der exakten Ziel-URL. Behalte drei Regeln im Kopf:

• Die Response muss HTTP 200 sein.
• Weiterleitungen werden nicht verfolgt, daher scheitert eine Seite, die auf einen Login-Bildschirm weiterleitet, an der Prüfung.
• Jeder Request hat ein Timeout von 10 Sekunden.

Wenn die Prüfung erfolgreich ist, lautet der Status „Ownership verified · HTML meta tag or file“.

Die ganze Domain verifizieren

Wähle Verify the whole domain, und der Assistent zeigt einen Host und einen TXT record value, ein Token, das mit verif- beginnt. Der Assistent schlägt die übergeordnete Domain deines Ziels vor: Für app.example.com ist das example.com. Prüfe den Host, bevor du irgendetwas veröffentlichst. Du kannst ihn nicht bearbeiten, und der Assistent schlägt immer die letzten beiden Labels des Hosts vor. Wenn das falsch ist (zum Beispiel co.uk für shop.example.co.uk), nutze stattdessen Verify this application. Andernfalls legst du den TXT-Record bei deinem DNS-Anbieter an, wartest, bis er propagiert ist, und klickst dann auf Recheck. Ist der Record noch nicht sichtbar, siehst du „Verification token not found yet — DNS changes can take time to propagate“.

Wenn Badge und Startprüfung nicht übereinstimmen

Die Spalte Verification in der Pentest-Liste erkennt nur eine Domain an, die für genau den Ziel-Host verifiziert ist. Ein Ziel, das durch eine App-Verifizierung oder eine verifizierte übergeordnete Domain abgedeckt ist, kann Unverified anzeigen. Seine Zeile bietet dann womöglich Verify first statt View Findings, Rescan oder Run. Maßgeblich ist allein die Prüfung beim Start. Öffne in diesem Fall die Befunde über Findings App Pentest , und um erneut zu testen, starte einen New AI Pentest für dieselbe URL.

Wird ein Lauf wegen des Eigentums abgelehnt, lautet die Meldung „Target URL is not verified. Please verify this application or the whole domain under Settings → Domain Verification.“ Im Einstellungsmenü heißt diese Seite Ownership Verification.

Ein Assessment durchführen

Ein Assessment ist eine gespeicherte Pentest-Definition (Name, Ziel-URL, Authentifizierung, optionales Repository, Scan-Vorgaben), die du beliebig oft ausführen kannst.

Der Assistent Schritt für Schritt

Schritt	Was du festlegst
1. Target	Assessment name und Target URL. Lässt du das Schema weg, wird https:// ergänzt.
2. Verify ownership	Nachweis für die App oder die ganze Domain (Lektion 3), dann Recheck.
3. Authentication	No authentication, Username / Password (Login URL, Test-Benutzername, Test-Passwort) oder API Keys / Headers.
4. Source repository	Optional: Select existing, Connect new oder überspringen für einen Black-Box-Lauf.
5. Scan & launch	Scan-Tiefe, Fokusbereiche, Out-of-Scope-Punkte, bekannter Tech-Stack, Additional context, dann eine Summary.

Hinweise zum Assistenten:

• Authentifizierung. Wenn du Zugang bereitstellst, nutze ein dediziertes Testkonto, nie das eines echten Nutzers. Gespeicherte Passwörter und Header-Werte gibt die API nie zurück. Um andere Zugangsdaten zu verwenden, leg ein neues Assessment an. Authentifiziertes Testen ist nicht garantiert: Behandle einen Lauf als nicht authentifiziert, solange die Live-Browseransicht oder die Aufzeichnung nicht zeigt, dass der Agent angemeldet war und die erwarteten Bereiche erreicht hat.
• Quell-Repository. Wenn du ein Repository verknüpfst, erhält der Agent deinen Quellcode für einen White-Box-Lauf. Share source code with the engine (whitebox scan) ist standardmäßig aktiviert. Deaktiviere es für einen Black-Box-Test, bei dem das Repository trotzdem verknüpft bleibt.
• Tiefe. Quick („Minutes · CI/CD & smoke checks“), Standard („30 min–1 hr · routine review“, die Voreinstellung) oder Deep („1–4 hr · full audit, chained exploits“). Die Zeitangaben im Assistenten sind Richtwerte. Jeder Lauf ist je nach Tiefe zeitlich begrenzt, und ein Lauf ohne Ergebnis vor Ablauf seines Limits wird als Failed markiert.
• Vorgaben. Wähle Fokusbereiche wie Access control (IDOR), prüfe die Out-of-Scope-Liste und schreib Additional context wie ein Briefing für einen menschlichen Pentester: kritische Abläufe, erneut zu prüfende Probleme, zu meidende Endpunkte. All das wird zum Briefing des Agenten.

Wenn du auf Launch AI Pentest klickst, prüft Plexicus außerdem, ob der AI Pentest-Connector aktiviert ist, ob ein verknüpftes Repository zu deiner Organisation gehört und ob du in diesem Monat noch eine Session übrig hast. Sind alle Prüfungen erfolgreich, siehst du „Scan started.“ und landest auf der Laufseite. Ist der Connector deaktiviert, kann ihn jemand mit der Berechtigung zur Verwaltung von Connectors unter Pentest Configure aktivieren.

Schlägt eine Prüfung fehl, zeigt der Assistent einen Fehler und speichert das Assessment als Draft. Behebe die Ursache, öffne dann den Draft aus der Pentest-Liste und klick auf seiner Laufseite auf Run. Ein erneuter Start aus dem Assistenten legt ein zweites Assessment an.

Status eines Laufs

Status	Bedeutung
Draft	Angelegt, nicht gestartet. Nur ein Draft lässt sich ändern, und zwar nur über die API.
Pending	Start angenommen. Der Lauf beginnt gerade.
Running	Der Agent testet. Abbrechen kannst du ihn auf seiner Laufseite.
Completed	Der Lauf ist beendet und hat Ergebnisse geliefert.
Failed	Der Agent hat einen Fehler gemeldet, oder vor dem Zeitlimit des Laufs kam kein Ergebnis an.
Cancelled	Jemand hat den Lauf abgebrochen.

Einen Lauf beobachten

Die Laufseite zeigt „Scan in progress“ mit einem Timer für die verstrichene Zeit. Nach 90 Minuten wechselt das Banner zu „Scan may be stuck“ und bietet Cancel an.

Die Live browser view streamt den Browser des Agenten. Der War room (live board) zeigt die Aktivität des Schwarms mit einem Badge LIVE. Bei abgeschlossenen Läufen zeigt er Replay, und Expand schaltet in den Vollbildmodus. Nur deine Organisation kann diese Live-Ansichten öffnen.

Außerdem bekommst du Screenshots und, falls vorhanden, eine Aufzeichnung des Agenten-Browsers (Session recording). Mit den integrierten Rollen können Admin und Cyberoper Läufe starten und abbrechen. Developer hat nur Lesezugriff (Modul 10).

Evidenz und Ergebnisse

Wenn ein Lauf abgeschlossen ist, hast du Befunde, einen Bericht, Screenshots und, falls eine erstellt wurde, eine Sitzungsaufzeichnung. Pentest-Befunde enthalten in der Regel ein Proof-of-Concept-Artefakt.

Befunde auf der Laufseite

Die Karte Findings listet jeden Befund mit einem Schweregrad-Badge und einem Titel. Klick auf einen Befund, um seine Beschreibung, die betroffene URL und den Typ seines Proof-of-Concept-Artefakts aufzuklappen:

Artefakt	Was es enthält
cURL-Befehl	Den HTTP-Request, der das Problem nachgewiesen hat, als cURL-Befehl.
Shell-Skript	Die aufgezeichneten Reproduktionsschritte als Skript.
HAR-Mitschnitt	Ein aufgezeichnetes HTTP Archive der Sitzung, angezeigt als formatiertes JSON.

View PoC öffnet das Artefakt in einem Viewer, und Download speichert es unter seinem ursprünglichen Dateinamen. Artefakte bleiben auch nach dem Ende des Laufs verfügbar. Hat ein abgeschlossener Lauf keine Befunde, zeigt die Karte „No findings“.

Befunde über Läufe hinweg

Pentest-Befunde werden als reguläre Plexicus-Befunde gespeichert und mit ihrem Pentest verknüpft. Öffne Findings App Pentest , um sie in der Standard-Befundtabelle mit Filtern und Detailbereich zu bearbeiten, oder klick in der Pentest-Liste bei einer abgeschlossenen Zeile auf View Findings.

Im Detailbereich zeigt ein Pentest-Befund Evidence & attack path statt Code & taint trace. Dort findest du die Ziel-URL, einen Chip, der angibt, ob ein Quell-Repository verknüpft war („White-box run — source repository linked“ oder „Black-box run — no source repository“), den Artefakttyp (CURL, HAR oder SCRIPT) und Download artifact. Laut Detailbereich ist das Artefakt ein deterministisches Replay: Befehl und erwartete Evidenz werden genau so angezeigt, wie sie aufgezeichnet wurden, und nichts wird aus deinem Browser erneut ausgeführt („shown as recorded; nothing is re-run from your browser.“). Der Viewer zeigt bis zu 64 KB eines Artefakts an. Alles, was größer ist, lädst du herunter, um den vollständigen Mitschnitt zu sehen. Wurde kein Artefakt gespeichert, zeigt der Bereich „No stored replay artifact for this finding.“

Bericht und Aufzeichnung

Download report erscheint im Kopfbereich der Laufseite, sobald der Agent seinen Bericht gespeichert hat, eine Markdown-Datei (.md), die am Ende des Laufs erstellt wird. Download video speichert die Sitzungsaufzeichnung als .webm-Datei. Für PDF- oder JSON-Exporte von App Pentest-Befunden nutze Findings App Pentest Download (Berichte behandelt Modul 8). Verifizierte Befunde gehen danach in deinen normalen Behebungs-Workflow über (Modul 7). Kläre mit deinem Ansprechpartner bei Plexicus, ob KI-Fixes für Pentest-Befunde in deinem Release verfügbar sind. Ob gemergt wird, entscheidet immer dein Team.

Session-Kontingente

Die Nutzung von AI Pentest wird in monatlichen Sessions gezählt, getrennt von deinem KI-Nutzungskontingent. Wie viele Sessions du hast, hängt von deinem Plan ab. Wenn dein Plan AI Pentest nicht enthält, zeigt New AI Pentest statt des Assistenten einen Upgrade-Hinweis.

• Jeder Lauf über Run oder Rescan verbraucht eine Session.
• Wenn Nutzungsdaten verfügbar sind, zeigt dein Profilmenü eine Anzeige Pentest mit den verbrauchten Sessions und dem Limit dieses Monats (oder Unlimited). Wenn für deinen Plan die Abrechnung angezeigt wird, hat Settings Billing außerdem eine Karte Pentest Sessions.
• Eine Session wird nur dann automatisch wieder gutgeschrieben, wenn der Lauf fehlschlägt, bevor der Agent startet, zum Beispiel weil das Setup scheitert. Sobald der Agent gestartet ist, verbraucht auch ein Abbruch des Laufs oder ein späterer Fehler die Session.
• Sind keine Sessions mehr übrig, wird der Start abgelehnt, mit Angabe der verbrauchten Sessions, des Limits und des Datums, an dem das Kontingent zurückgesetzt wird.
• Die Zählung wird am 1. jedes Kalendermonats (UTC) zurückgesetzt, nicht an deinem Abrechnungsdatum.

Plane, bevor du eine Session verbrauchst: Verifiziere das Eigentum, prüfe die Out-of-Scope-Liste, schreib das Briefing und wähle die Tiefe, die zu deiner Fragestellung passt.

Das Wichtigste in Kürze

• AI Swarm Pentest (im Produkt AI Pentest) ist ein klar abgegrenzter, autorisierter Auftrag, gebunden an die vier Leitplanken aus Modul 1: schriftlich vereinbarter Scope, nachvollziehbare Evidenz, Auftragsgrenzen und menschliche Entscheidung. Er nimmt keine automatischen Änderungen in der Produktion vor.
• Der Schwarm kartiert die Angriffsfläche, bildet Hypothesen und testet Angriffspfade innerhalb des vereinbarten Scopes, und ein zweiter Durchlauf muss ein Ergebnis bestätigen, bevor es als verifiziert präsentiert wird. Ohne reproduzierbaren Nachweis kein verifizierter Befund.
• Ein Start setzt nachgewiesenes Eigentum voraus: einen Meta-Tag oder eine Datei unter /.well-known für einen Host oder einen DNS-TXT-Record für eine ganze Domain. Das Akzeptieren von Bedingungen ist kein Nachweis, und das Badge Verification in der Pentest-Liste ist nur ein Hinweis.
• Der Assistent New AI Pentest hat fünf Schritte. Bevorzuge Staging, denk daran, dass Out-of-Scope-Punkte Anweisungen und keine technischen Sperren sind, und schreib das Briefing so, wie du es für einen menschlichen Pentester tun würdest.
• Pentest-Befunde enthalten in der Regel ein Proof-of-Concept-Artefakt (cURL-Befehl, Shell-Skript oder HAR-Mitschnitt), das genau so angezeigt wird, wie es aufgezeichnet wurde. Aus deinem Browser wird nichts erneut ausgeführt.
• Jeder Lauf über Run oder Rescan verbraucht eine monatliche Session, die nur wieder gutgeschrieben wird, wenn der Lauf fehlschlägt, bevor der Agent startet. Das 90-Minuten-Banner „Scan may be stuck“ ist für sich allein kein Grund, einen Deep-Lauf abzubrechen.