Start von ThreatBook RedAgents stellt mehrere KI-Pentester dem Einzelagentenmodell gegenüber
ThreatBook hat RedAgents mit mindestens vier KI-Pentest-Agenten gestartet und stellt damit die Annahme infrage, dass ein einzelner autonomer Tester eine vollständige Sicherheitsbewertung liefern kann. Mit dem Start von ThreatBook RedAgents werden konkurrierende Offensivsysteme zu einem koordinierten Testpool zusammengeführt. Das Unternehmen hat jedoch keinen unabhängigen Vergleich veröffentlicht, der belegt, dass der kombinierte Ansatz mehr Schwachstellen bei weniger Fehlalarmen findet.
RedAgents betritt einen Markt, der bereits von autonomen Sicherheitsplattformen wie XBOW und Horizon3.ai geprägt ist. Diese Wettbewerber verkaufen überwiegend die Leistungsfähigkeit einer einzelnen Plattform und ihres Testsystems. ThreatBook setzt auf einen anderen Ansatz: Sicherheitsteams sollen mehrere Agenten zusammenstellen und ihre Ergebnisse über eine Schnittstelle vergleichen.
Dieser Unterschied macht die eigentliche Geschichte aus. Mehr Agenten können unterschiedliche Angriffspfade untersuchen, erhöhen aber zugleich die Anzahl der Tools, Berechtigungen und Entscheidungen, die Betreiber steuern müssen. RedAgents muss beweisen, dass die Aggregation die Abdeckung verbessert, ohne das operative Risiko zu vervielfachen.
Der Start von ThreatBook RedAgents verändert die Einheit des Wettbewerbs
ThreatBook präsentiert keinen weiteren autonomen Scanner. Das Unternehmen positioniert die Agentensammlung selbst als Produkt.
ThreatBook kündigte RedAgents am 16. Oktober 2026 an. Das Unternehmen beschreibt es als Software-as-a-Service-Plattform, mit der mehrere KI-Penetrationstest-Agenten gegen dasselbe autorisierte Ziel eingesetzt werden können.
Ein KI-Pentest-Agent nutzt Modelle, Sicherheitstools und iterative Planung, um ausnutzbare Schwachstellen zu identifizieren und teils zu validieren. RedAgents bietet Sicherheitsteams eine einheitliche Oberfläche, um Agenten auszuwählen, ein Ziel festzulegen und ihre Ergebnisse zu prüfen.
Zum anfänglichen Aufgebot gehören Artex Pro, Cyber(YanJi), Yanxun und CyberStrikeAI Enterprise Edition. ThreatBook zufolge kann die Plattform diese Systeme je nach Bewertung unabhängig oder parallel ausführen.
Diese Wahl ist wichtig, da einzelne Pentest-Agenten ein Ziel nicht zwingend auf dieselbe Weise angehen. Einer kann Anwendungslogik im Web priorisieren, während ein anderer mehr Zeit für Aufklärung oder Zugangsdatenpfade aufwendet.
ThreatBook-CEO Feng Xue bezeichnete das Modell eines einzelnen Anbieters als Quelle eingeschränkter Sichtbarkeit. Sein Argument lautet, dass zwei Agenten unterschiedliche Schwachstellen finden können, selbst wenn beide dasselbe Ziel erhalten.
Das Unternehmen erklärt, RedAgents führe Testdaten, Protokolle und Schwachstellenbefunde in einer Ansicht zusammen. Dieses Design soll den manuellen Aufwand verringern, der beim Betrieb separater Produkte und beim Abgleich ihrer Berichte entsteht.
Der Start von RedAgents verknüpft diese Orchestrierungsebene zudem mit mehreren Sicherheitsversprechen. ThreatBook zufolge definieren Kunden den Testumfang über eine Whitelist, und Agenten müssen innerhalb dieser autorisierten Parameter bleiben.
Weiter erklärt das Unternehmen, Testdaten blieben in seiner Umgebung, statt an Drittanbieter-Agenten übertragen zu werden. Zudem wirbt es mit einer Aufbewahrung von null Daten, wodurch Kunden die vollständige Löschung ihrer Testdaten anfordern können.
Dabei handelt es sich weiterhin um Herstellerangaben, bis Kunden oder unabhängige Prüfer sie unter realistischen Bedingungen verifizieren. Die Ankündigung erläutert nicht, wie RedAgents Grenzen durchsetzt, wenn ein Agent einen unerwarteten Befehl erzeugt.
Sie legt auch nicht dar, ob jeder Befehl deterministische Richtlinienprüfungen durchläuft. Die Mitteilung enthält keine Details zu Notabschaltungen, Ratenbegrenzungen, Berechtigungsisolation oder menschlicher Freigabe für sensible Aktionen.
Dennoch verändert das Produkt die Wettbewerbsfrage. Käufer werden nicht mehr nur gefragt, welcher autonome Pentester die beste Leistung liefert.
Sie werden gefragt, ob die Wahl eines einzelnen Systems die falsche Architektur ist. ThreatBook möchte die Orchestrierungsebene wertvoller machen als jeden einzelnen daran angebundenen Agenten.
Dieses Konzept ähnelt Multi-Engine-Malware-Scans, bei denen mehrere Erkennungssysteme dasselbe Objekt prüfen. ThreatBook nutzt diese Idee ausdrücklich, um zu erklären, weshalb sich überschneidende und nicht überschneidende Befunde die Abdeckung verbessern können.
Pentesting schafft jedoch ein schwierigeres Koordinationsproblem. Eine Malware-Engine bewertet ein Artefakt, während ein Pentest-Agent mit Live-Diensten, Konten, Datenbanken und Netzwerksteuerungen interagieren kann.
Die Kombination von Agenten verlangt daher mehr als das Sammeln von Ergebnissen. Die Plattform muss Aktionen koordinieren, gegenseitige Beeinträchtigungen verhindern, Belege normalisieren und doppelte Befunde erkennen, ohne bedeutsame Unterschiede zu verbergen.
Diese Anforderungen machen RedAgents aus einem Produktbündel zu einer operativen Steuerungsebene. Ob es diese Rolle zuverlässig erfüllt, wird entscheiden, ob das Aggregatormodell echten Nutzen bietet.
Warum KI-Pentesting mit mehreren Agenten jetzt kommt
Der Zeitpunkt spiegelt den Wandel von geplanten Sicherheitsbewertungen hin zu kontinuierlicher Validierung mit Maschinengeschwindigkeit wider.
Traditionelle Penetrationstests hängen oft von knappen menschlichen Fachkräften, festen Einsatzzeiträumen und manuell erstellten Berichten ab. Diese Struktur liefert eine detaillierte Momentaufnahme, doch die Umgebung kann sich kurz nach Ende der Tests verändern.
Anwendungen erhalten heute häufige Releases, Cloud-Assets entstehen dynamisch, und exponierte Dienste ändern sich, ohne auf die nächste Bewertung zu warten. Die Lücke zwischen Tests kann daher zu einem unkontrollierten Risikofenster werden.
ThreatBook argumentiert, dass KI-Agenten kürzere Testzyklen praktikabel machen. RedAgents soll Sicherheitsteams ermöglichen, Bewertungen täglich, wöchentlich oder monatlich durchzuführen, statt Pentesting als jährliche Übung zu behandeln.
Diese Idee ist nicht einzigartig für ThreatBook. Anbieter autonomer Tests vermarkten bereits kontinuierliche Bewertungen, erneute Tests und die Validierung von Angriffspfaden als Alternativen zu isolierten Beratungsmandaten.
XBOW erklärt, sein System finde und nutze Webschwachstellen autonom aus und liefere dabei Belege für die validierten Schwächen. Das Unternehmen berichtete, 2025 die Spitzenposition auf HackerOnes US-Rangliste erreicht zu haben.
Laut der veröffentlichten Darstellung reichte das System bei diesem Einsatz fast 1.060 Schwachstellen ein. Menschliche Prüfer kontrollierten Berichte auf Programmkonformität, waren laut XBOW jedoch nicht an Entdeckung oder Ausnutzung beteiligt.
Diese Zahlen stammen von XBOW und sollten nicht als direkter Maßstab für RedAgents dienen. Sie zeigen dennoch, warum autonomes Pentesting über Labordemonstrationen hinausgegangen ist.
Die Benchmark-Historie von XBOW verdeutlicht auch die Schwierigkeit, Fortschritte zu messen. Das Unternehmen nutzte zunächst etablierte Trainingsaufgaben, entwickelte dann neuartige Szenarien und wechselte zu Produktionszielen in Bug-Bounty-Programmen.
ThreatBook hat keine vergleichbare Bewertung für die vollständige RedAgents-Plattform veröffentlicht. Stattdessen verweist das Unternehmen auf Erfolge einzelner Agenten seines Aufgebots.
Dem Unternehmen zufolge löste Cyber(YanJi) in einem Tencent-Cloud-Hackathon 54 von 54 Zielaufgaben. Zudem erklärt es, die Open-Source-Version von Artex habe im September 2026 Baidus Agent+ Offensive and Defensive Challenge gewonnen.
CyberStrikeAI sammelte Berichten zufolge mehr als 7.800 GitHub-Stars, bevor ThreatBook das Unternehmen im September 2026 übernahm. Beliebtheit kann auf Entwicklerinteresse hindeuten, misst jedoch weder die Genauigkeit von Unternehmenstests noch die sichere Ausführung.
Diese Signale auf Agentenebene erklären, weshalb Aggregation attraktiv erscheint. Ein Käufer kann auf mehrere Ansätze zugreifen, ohne vorhersagen zu müssen, welcher Agent bei jeder Anwendung, Schwachstellenklasse oder Infrastrukturumgebung überlegen sein wird.
Das Modell gibt ThreatBook außerdem eine Möglichkeit, künftige Systeme aufzunehmen. Auf der Produktseite heißt es, die Plattform werde weiterhin kommerzielle, akademische und Open-Source-Agenten ergänzen.
Das schafft potenziell einen schnelleren Aktualisierungspfad, als einen proprietären Agenten für jede neue Technik neu aufzubauen. Die Plattform kann einen Spezialisten ergänzen, wenn dieser eine eigenständige Fähigkeit bietet.
Dieselbe Architektur verlagert jedoch Verantwortung auf Bewertung und Governance. ThreatBook muss entscheiden, welche Agenten infrage kommen, welche Berechtigungen sie erhalten und wie Kunden ihr Verhalten vergleichen können.
Ein Sicherheitsteam muss außerdem wissen, ob zwei Agenten tatsächlich unabhängige Perspektiven bieten. Mehrere Produkte können weiterhin dieselben Modellschwächen, Trainingsdaten, Tools oder Planungsmuster übernehmen.
Die Multi-Agenten-These wird nur dann wertvoll, wenn Vielfalt zu nützlicher Abdeckung führt. Ähnliche Agenten mehrfach auszuführen kann die Aktivität steigern, ohne den Erkenntnisgewinn zu erhöhen.
Deshalb ist die wichtigste RedAgents-Kennzahl nicht die Anzahl angeschlossener Tools. Entscheidend ist die Zahl validierter, nicht doppelter Befunde, die diese Tools sicher über eine starke Einzelagenten-Basislinie hinaus entdecken.
RedAgents gegenüber dem Einzelagentenmodell für Pentesting
Im Mittelpunkt steht der Wettbewerb zwischen Portfolioabdeckung und der Konsistenz eines eng kontrollierten Testsystems.
Anbieter von Einzelplattformen können jeden Teil der Bewertung um eine Architektur herum optimieren. Sie kontrollieren Planung, Toolzugriff, Belegstandards, Sicherheitsregeln, Berichterstattung und erneute Tests.
Diese vertikale Integration kann Verantwortlichkeit vereinfachen. Wenn ein Test fehlerhaft arbeitet oder ein Befund sich als unzuverlässig erweist, hat der Kunde ein System und einen Anbieter, die er prüfen kann.
ThreatBook gibt einen Teil dieser Einfachheit zugunsten von Vielfalt auf. RedAgents kann Agenten zusammenführen, die von unterschiedlichen Teams entwickelt wurden und verschiedene Stärken sowie technische Wege besitzen.
Seine Multi-Agenten-Plattform stellt die Auswahl als Kundenentscheidung dar. Ein Team kann einen Agenten für eine fokussierte Aufgabe oder mehrere Agenten für eine breitere Gegenprüfung einsetzen.
Dies ähnelt der Zusammenstellung eines menschlichen Red Teams mit Spezialisten für verschiedene Angriffsflächen. Ein Experte für Webanwendungen, ein Identitätsspezialist und ein Cloud-Tester können unterschiedliche Wege durch dieselbe Umgebung erkennen.
Menschliche Teammitglieder kommunizieren jedoch, lösen Konflikte und hinterfragen Annahmen gemeinsam. Software-Agenten benötigen explizite Orchestrierung, um dieselbe Koordination zu erreichen.
Parallele Ausführung kann zudem gegenseitige Beeinträchtigungen verursachen. Ein Agent könnte den Anwendungszustand ändern, ein Token verbrauchen, eine Sperre auslösen oder Belege verändern, bevor ein anderer Agent denselben Pfad erreicht.
Die Startmaterialien erläutern nicht, wie RedAgents mit solchen Kollisionen umgeht. Sie sagen auch nicht, ob die Plattform gefährliche Aktionen serialisiert oder jeden Agenten in einer eigenen Testumgebung isoliert.
Die Aggregation von Ergebnissen schafft eine weitere Herausforderung. Zwei Agenten könnten dieselbe zugrunde liegende Schwachstelle mit unterschiedlichen Beschreibungen, Schweregradbewertungen oder Exploit-Belegen melden.
Eine nützliche Plattform muss diese Überschneidung erkennen, ohne unterschiedliche Angriffspfade zusammenzuführen. Sie muss zudem genügend Belege bewahren, damit ein menschlicher Tester jeden Befund reproduzieren und priorisieren kann.
ThreatBook erklärt, RedAgents entferne Duplikate und bewerte Befunde automatisch. Das Unternehmen hat keine Daten veröffentlicht, die zeigen, wie genau dieser Prozess über das anfängliche Agentenaufgebot hinweg funktioniert.
Auch die Verringerung von Fehlalarmen ist eine zentrale Behauptung. Mehrere Agenten auszuführen lässt ein falsches Ergebnis nicht automatisch verschwinden.
Agenten können dieselbe falsche Annahme wiederholen, insbesondere wenn sie ein zugrunde liegendes Modell oder Sicherheitstool teilen. Umgekehrt kann ein korrekter Befund eines Spezialisten nur einmal erscheinen.
Ein Abstimmungssystem könnte daher ein wertvolles Ergebnis verwerfen, weil andere Agenten es nicht reproduziert haben. Die Vereinigung aller Befunde könnte das gegenteilige Problem schaffen und Prüfer überfordern.
RedAgents benötigt einen besseren Entscheidungsmechanismus als einfachen Konsens. Es sollte zwischen reproduzierten Befunden, unabhängig entdeckten Befunden und Spezialistenbefunden unterscheiden, die manuell validiert werden müssen.
Die Plattform steht zudem im Wettbewerb mit etablierten autonomen Pentesting-Diensten. NodeZero von Horizon3.ai konzentriert sich auf die autonome Ermittlung von Angriffspfaden, während XBOW den Schwerpunkt auf validierte Web-Schwachstellen und Nachweise aus Produktivumgebungen legt.
Diese Systeme dienen als Referenzpunkt für die Erwartungen von Käufern. Kunden werden reproduzierbare Exploits, klar benannte betroffene Assets, Hinweise zur Behebung und eine verlässliche Bestätigung nach einem Fix erwarten.
RedAgents kann sich differenzieren, wenn mehrere Agenten während desselben Engagements substanziell unterschiedliche Schwachstellen aufdecken. Es kann auch überzeugen, wenn sich diese Ergebnisse über eine gemeinsame Steuerungsebene leichter verwalten lassen als über mehrere separate Verträge.
Der Aggregator verliert seinen Vorteil, wenn Kunden widersprüchliche Ergebnisse manuell untersuchen müssen. Er verliert ihn auch, wenn angebundene Agenten nicht die Tiefe einer spezialisierten Plattform erreichen.
Die ersten aussagekräftigen Vergleiche sollten daher identische Ziele, Umfänge und Testzeiträume nutzen. Sie sollten validierte eindeutige Funde, Fehlalarme, operative Vorfälle und den Zeitaufwand für menschliche Prüfung messen.
Ohne diese Belege bleibt RedAgents eine plausible Architektur statt eines nachgewiesenen Ersatzes. Der Launch definiert die Richtung des Produkts, nicht seine Überlegenheit.
Der Mechanismus funktioniert nur, wenn die Orchestrierung zusätzliche Erkenntnisse liefert
Mehr Agenten verbessern die Abdeckung nur, wenn RedAgents ihre Aktionen kontrolliert und ihre Ergebnisse in belastbare Nachweise überführt.
Die erste Aufgabe der Plattform ist die Durchsetzung des Testumfangs. Penetrationstests umfassen Handlungen, die außerhalb eines klar definierten Engagements nicht autorisiert wären.
Das United States National Institute of Standards and Technology definiert Einsatzregeln als Beschränkungen, die vor Beginn eines Tests festgelegt werden. Sie erteilen die Befugnis für bestimmte Aktivitäten, ohne eine unbegrenzte Erlaubnis zu gewähren.
Die NIST-Leitlinien nennen Ziele, eingeschränkte Systeme, zulässige Techniken, Testzeiträume und Quelladressen als wichtige Details eines Engagements. Die Testregeln bleiben relevant, auch wenn Software die Arbeit ausführt.
ThreatBook erklärt, dass RedAgents Whitelists zur Definition des Testumfangs verwendet. Eine Whitelist kann Zieladressen begrenzen, doch ein sicherer Betrieb erfordert granularere Kontrollen.
Teams müssen möglicherweise Denial-of-Service-Techniken, destruktive Datenbankaktionen, Passwortänderungen oder Zugriffe auf Kundenunterlagen in Produktivsystemen untersagen. Sie benötigen möglicherweise auch Wartungsfenster und Limits für Anfrageraten.
Eine Multi-Agenten-Plattform muss diese Einschränkungen über jedes angebundene System hinweg konsistent anwenden. Sie kann nicht davon ausgehen, dass jeder Agent eine schriftliche Anweisung auf dieselbe Weise interpretiert.
Autorisierungen sollten außerhalb des Denkprozesses des Modells durchgesetzt werden. Netzwerkkontrollen, isolierte Zugangsdaten, Befehlsrichtlinien und zielbezogene Berechtigungen bilden stärkere Grenzen als Prompts allein.
Das ist wichtig, weil Agenten auf Basis von Sprachmodellen Werkzeuge auswählen und Aktionssequenzen dynamisch erzeugen können. Ihre Flexibilität hilft bei der Erkundung unbekannter Umgebungen, erschwert jedoch die Vorhersage jeder künftigen Aktion.
OWASP bezeichnet eine Variante dieses Problems als excessive agency. Sie tritt auf, wenn ein KI-System mehr Funktionalität, Berechtigungen oder Autonomie erhält, als seine Aufgabe erfordert.
OWASP empfiehlt, verfügbare Werkzeuge zu reduzieren, Berechtigungen zu begrenzen, für folgenreiche Aktionen menschliche Genehmigungen zu verlangen und Autorisierungen in nachgelagerten Systemen durchzusetzen. Die Leitlinien zu excessive agency warnen zudem vor kompromittierten Peer-Agenten in Multi-Agenten-Umgebungen.
Diese Warnung lässt sich direkt auf RedAgents übertragen. Ein Aggregator muss jeden angebundenen Agenten sowohl als Quelle von Sicherheitskompetenz als auch als potenziell fehlerhafte Komponente behandeln.
Zentralisiertes Logging kann helfen. RedAgents erklärt, Protokolle und Ergebnisse teilnehmender Agenten an einem Ort zu erfassen und Prüfern damit einen gemeinsamen Audit-Trail bereitzustellen.
Ein gemeinsamer Verlauf sollte zeigen, welcher Agent jeden Befehl ausgelöst hat, welche Identität er nutzte, welches Ziel reagierte und ob eine Kontrolle die angeforderte Aktion verändert hat. Er sollte außerdem Nachweise für jeden validierten Fund aufbewahren.
Die vollständige Vermeidung von Datenaufbewahrung bringt einen weiteren operativen Zielkonflikt mit sich. Das Löschen sensibler Testdaten kann die Angriffsfläche verringern, doch Kunden benötigen möglicherweise ausgewählte Nachweise für Behebung, Audit und Vorfallsprüfung.
Die Plattform sollte ihre Aufbewahrungsrichtlinien daher präzise formulieren. Käufer müssen wissen, was „vollständige Löschung“ umfasst, wann die Löschung erfolgt und ob Backups oder Diagnoselogs derselben Richtlinie folgen.
Die Datenisolation wird komplexer, wenn Drittanbieter-Agenten an der Plattform teilnehmen. ThreatBook erklärt, dass Kundentestdaten innerhalb seiner Umgebung bleiben, statt diese Anbieter zu erreichen.
Diese Aussage erfordert eine architektonische Erklärung. Kunden sollten verstehen, ob Agentencode innerhalb einer von ThreatBook verwalteten Isolierung läuft, ob externe Modelle Prompts erhalten und wie Geheimnisse gefiltert werden.
Der Wert der Plattform entsteht letztlich durch ihre Evidenzpipeline. Die Entdeckung allein reicht nicht aus, wenn Sicherheitsteams den Funden nicht vertrauen, sie nicht reproduzieren und nicht priorisieren können.
Ein glaubwürdiger Multi-Agenten-Workflow würde einzelne Nachweise bewahren und zugleich eine einheitliche Bewertung erzeugen. Er würde zeigen, wann Agenten übereinstimmen, wann sie sich widersprechen und weshalb die Plattform ihre endgültige Schweregradbewertung gewählt hat.
RedAgents hat das übergeordnete Design beschrieben, nicht jedoch diese Ebene der Umsetzung. Technische Dokumentation und kontrollierte Kundenevaluierungen werden entscheiden, ob die Orchestrierung tatsächlich zusätzliche Erkenntnisse liefert.
Die Sicherheitsfrage ist Teil des Produkts
RedAgents bündelt offensive Fähigkeiten, die für Verteidiger nützlich bleiben müssen, ohne zu einer unkontrollierten Angriffsinfrastruktur zu werden.
Jedes autonome Pentesting-Produkt steht vor einem Dual-Use-Problem. Dieselben Fähigkeiten, die einem Unternehmen helfen, seine Abwehr zu validieren, können einem Angreifer helfen, Aufklärung und Ausnutzung zu automatisieren.
Die anfängliche Zusammenstellung von ThreatBook macht diese Spannung besonders deutlich. Das Unternehmen erklärt, dass Artex am 8. Oktober 2026 nach mutmaßlichem Missbrauch bei Angriffen von Open Source zu Closed Source wechselte.
Die Ankündigung von ThreatBook verknüpft diese Entscheidung mit Vorfällen bei südkoreanischen Finanzorganisationen. Die Veröffentlichung liefert jedoch keinen vollständigen unabhängigen Vorfallsbericht, der jedes Detail stützt.
Der Vorgang wirft dennoch eine direkte Governance-Frage auf. Wenn ein Agent mit Missbrauch in Verbindung gebracht wird, wie bewertet RedAgents dessen Code, Modelle, Abhängigkeiten und Betriebsverhalten vor der Bereitstellung?
Das Unternehmen erklärt, Artex Pro ergänze gegenüber der Open-Source-Edition Kontrolle, Stabilität und Nachverfolgbarkeit. Diese Beschreibungen wurden in den Launch-Unterlagen nicht unabhängig validiert.
Der Erwerb oder die Kommerzialisierung eines Werkzeugs kann Verantwortlichkeit schaffen, macht das Werkzeug aber nicht automatisch sicher. Kontrollen müssen gegen Fehler, bösartige Anweisungen, kompromittierte Abhängigkeiten und unerwartete Zielreaktionen getestet werden.
Die Vielfalt der Agenten kann die Angriffsfläche innerhalb der Testplattform vergrößern. Jeder Connector, jede Werkzeugintegration, jeder Modellendpunkt, jeder Credential Store und jeder Berichtsweg schafft eine weitere potenzielle Schwachstelle.
Der Aggregator muss sich zudem gegen Prompt Injection verteidigen. Ein feindliches Ziel könnte Inhalte präsentieren, die einen Agenten dazu manipulieren sollen, Einschränkungen zu ignorieren oder sensible Informationen preiszugeben.
Auch die Kommunikation zwischen Agenten eröffnet einen weiteren Weg. Ein kompromittierter Agent könnte irreführenden Kontext erzeugen, der die Entscheidungen eines Orchestrators oder eines Peer-Agenten beeinflusst.
OWASP empfiehlt, Ein- und Ausgaben von Agenten als nicht vertrauenswürdig zu behandeln. Deterministische Kontrollen sollten folgenreiche Anfragen vermitteln, statt jede Autorisierungsentscheidung einem Modell zu überlassen.
Die Whitelist und das zentralisierte Datenmodell von ThreatBook adressieren einen Teil dieses Problems. Sie beantworten nicht, ob einzelne Befehle vor ihrer Ausführung einer Richtliniendurchsetzung unterliegen.
Das Unternehmen hat zudem keine externen Audits, namentlich genannten Designpartner oder Produktivkunden für RedAgents benannt. Begrenzte Tests können diese Nachweise liefern, doch frühe Anwender sollten klare Grenzen verlangen.
Käufer sollten fragen, welche Systeme unterstützt werden, welche Aktionen eine Genehmigung erfordern und wie Zugangsdaten eingegrenzt werden. Sie sollten außerdem fragen, was geschieht, wenn ein Agent seinen zugewiesenen Workflow verlässt.
Rollback und Notabschaltung verdienen dieselbe Aufmerksamkeit. Ein Sicherheitsoperator braucht eine verlässliche Möglichkeit, alle aktiven Agenten zu stoppen, Zugangsdaten zu widerrufen und während eines ungewöhnlichen Tests Beweise zu sichern.
Unabhängige Benchmarks müssen Sicherheitsresultate einbeziehen, nicht nur die Anzahl der Schwachstellen. Ein System, das mehr Probleme findet, dabei aber Ausfälle verursacht oder Geheimnisse falsch behandelt, liefert keine bessere Bewertung.
Tests sollten zudem Trainingsumgebungen von Produktivsystemen trennen. Selbst ausgereifte autonome Plattformen räumen ein, dass keine automatisierte Sicherheitsbewertung eine folgenlose Ausführung garantieren kann.
Die Belastung steigt, wenn mehrere Agenten gleichzeitig arbeiten. Mehr Aktivität kann Schutzkontrollen auslösen, Konten sperren oder Dienste mit empfindlichen Ratenlimits beeinträchtigen.
RedAgents sollte Parallelität sichtbar und konfigurierbar machen. Kunden benötigen Kontrolle über Testfenster, Anfrageraten, geschützte Endpunkte und die maximale Zahl gleichzeitiger Aktionen.
Ein vorsichtiger Rollout würde mit isolierten Anwendungen, nichtproduktiven Replikaten und eng abgegrenzten externen Assets beginnen. Teams könnten die Funde dann mit menschlicher Validierung vergleichen, bevor sie den Zugriff ausweiten.
Dieser Ansatz würde den Wert des Produkts nicht schwächen. Er würde Sicherheitsteams Belege dafür liefern, welche Agenten in ihrer eigenen Umgebung gut funktionieren.
Der Launch stellt Fähigkeiten und Risiken daher als untrennbare Frage dar. RedAgents kann nur erfolgreich sein, wenn seine Steuerungsebene mindestens so ausgereift ist wie die offensiven Systeme, die sie koordiniert.
Drei Signale werden zeigen, ob RedAgents liefert
Die nächste Phase sollte anhand vergleichender Belege, durchsetzbarer Sicherheitskontrollen und echter Kundenakzeptanz beurteilt werden.
Das erste Signal ist ein kontrollierter Benchmark gegenüber einer starken Single-Agent-Basislinie. ThreatBook sollte Tests mit identischen Zielen, Zugangsdaten, Umfängen und Zeitlimits veröffentlichen.
Das aussagekräftige Ergebnis wäre nicht die Gesamtzahl der Warnungen. Es würde validierte eindeutige Schwachstellen, doppelte Funde, Fehlalarme, die Schweregradverteilung und die Zeit für menschliche Verifizierung zeigen.
Dieser Benchmark würde das Multi-Agenten-Argument stärken, wenn RedAgents konsistent wichtige Probleme findet, die jedem einzelnen Teilnehmer entgehen. Ähnliche Ergebnisse bei mehr operativem Aufwand würden es schwächen.
Das zweite Signal ist eine detaillierte Sicherheitsdokumentation. ThreatBook sollte Befehlsvermittlung, Agentenisolation, Credential-Kontrollen, Genehmigungsschranken, Aufbewahrungsverhalten und Notabschaltung erläutern.
Unabhängige Tests hätten mehr Gewicht als eine Funktionscheckliste. Käufer benötigen Belege dafür, dass ein Agent seinen Umfang nicht aufgrund von Prompt Injection, Modellfehlern oder kompromittierten Peer-Ausgaben verlassen kann.
Das dritte Signal ist eine wiederholte Nutzung über begrenzte Testläufe hinaus. Namentlich genannte Fallstudien sollten zeigen, wie häufig Organisationen Tests durchführen, welche Agenten sie auswählen und ob Funde zu verifizierten Behebungen führen.
Akzeptanzdaten würden außerdem offenlegen, ob Kunden die Agentenauswahl schätzen oder lediglich ein Standardsystem wählen. Die Aggregator-These wird schwächer, wenn die meisten Nutzer die breitere Auswahl ignorieren.
RedAgents betritt den Markt mit einer schlüssigen Antwort auf eine reale Einschränkung. Kein einzelner Testansatz entdeckt jede Schwachstelle, und häufige Softwareänderungen machen periodische Bewertungen weniger ausreichend.
Das Hinzufügen von Agenten garantiert jedoch keine bessere Sicherheit. Die Plattform muss nachweisen, dass ihre Orchestrierung vielfältige, validierte Funde erzeugt, ohne eine ebenso vielfältige Reihe von Risiken zu schaffen.
Sicherheitsverantwortliche, die den Launch von ThreatBook RedAgents bewerten, sollten mit einem engen Vergleich beginnen. Sie sollten RedAgents und einer etablierten Alternative dasselbe autorisierte Ziel geben und dann bestätigte Funde sowie die Arbeitslast der Operatoren messen.
Sie sollten die menschliche Prüfung für folgenreiche Aktionen beibehalten und explizite Einsatzregeln verlangen. Ergebnisse sollten nach Reproduzierbarkeit, Nutzen für die Behebung und sicherer Ausführung bewertet werden.
Die Frage für das nächste Quartal ist konkret: Kann ThreatBook nachweisen, dass mehrere kontrollierte Agenten einen ausgereiften autonomen Pentester übertreffen? Dieses Ergebnis – nicht die Größe des Teams – wird darüber entscheiden, ob KI-Pentesting mit mehreren Agenten zu einer dauerhaften Kategorie wird.
