Robinhood hat am 19. Oktober 2026 den Aufbau seines internen Security-Review-Systems Prowler beschrieben. Nach Unternehmensangaben untersucht es seit mehreren Monaten jede Nacht produktive Services und erstellt Befunde für menschliche Prüfer. Über 90 Prozent der Services in den beiden höchsten Kritikalitätsstufen wurden bereits bewertet. Ein separater Verifikationsagent bestätigte laut Robinhood bislang 92 Prozent der Befunde auf Ebene ihrer Ursache.
Die Zahl ist keine allgemeine Erkennungsrate für Schwachstellen. Dafür müsste Robinhood auch wissen, welche Fehler Prowler übersehen hat. Das Unternehmen veröffentlicht keine entsprechende Recall-Messung und keine unabhängige Reproduktion.
Eine feste Ablaufsteuerung ersetzt den LLM-Orchestrator
Die erste Version verwendete ein Sprachmodell, um den gesamten Prüfablauf zu koordinieren. Dabei wurden gelegentlich unterschiedliche Befunde fälschlich zusammengeführt oder Schweregrade zwischen Durchläufen verändert. Robinhood verlegte daraufhin Schritte mit eindeutigem Ergebnis in gewöhnlichen Anwendungscode: Statusverwaltung, Deduplizierung, Abstimmungsregeln und Reporterstellung.
Modelle übernehmen weiterhin Aufgaben, die technische Beurteilung erfordern. Dazu gehören Bedrohungsmodellierung, die Suche nach Fehlern in Geschäftslogik und die Prüfung, ob ein gemeldeter Fehler tatsächlich erreichbar ist. Übergaben zwischen den Stufen folgen typisierten Schemas; ungültige Ergebnisse werden mit konkreter Fehlermeldung erneut angefordert. Checkpoints erlauben das Fortsetzen unterbrochener Läufe.
Zwei Suchverfahren prüfen denselben Service aus verschiedenen Richtungen
Ein Extraktor erstellt zunächst eine strukturierte Übersicht über Endpunkte, Authentifizierung, Datenzugriffe und externe Verbindungen. Darauf aufbauend erzeugt ein Agent ein Bedrohungsmodell. Ein weiterer Agent sucht nach bekannten Schwachstellenklassen anhand einer kuratierten YAML-Registry. Ein offener Spezialist untersucht parallel Fehler in der Geschäftslogik, die nicht in diese Registry passen.
Nach der Zusammenführung verfolgt ein eigener Agent die technische Erreichbarkeit der Verdachtsfälle. Unabhängige Verifikationsläufe prüfen anschließend die Belege und suchen gezielt nach Gründen, die gegen einen Befund sprechen. Bei schweren Meldungen werden mehrere Stimmen ausgewertet; das Ergebnis wird nach festen Regeln zusammengeführt.
Robinhood beschreibt einen Befund, bei dem ein gemeinsamer Berechtigungshelfer fehlerhaft war und 15 Endpunkte betraf. Eine andere Untersuchung identifizierte einen Workflow, der einen vom Client gelieferten Freigabestatus als gültig behandelte. Die Beispiele stammen aus der Unternehmensdarstellung; die im Blog gezeigten Codeausschnitte sind ausdrücklich nachgestellte Beispiele.
Fehlender Repository-Kontext führte zu einer falschen Entwarnung
Robinhood nennt auch einen Fehlentscheid: Prowler erkannte eine fehlende Zuordnungsprüfung, bewertete den Zugriffspfad aber mangels weiterer Informationen als praktisch nicht ausnutzbar. Wochen später bestätigte ein menschlicher Penetrationstest den Fehler. Die dafür nötige Information lag in einem anderen Repository, das Prowler nicht lesen konnte.
Die Architektur kann also plausible Begründungen und überprüfbare Belege liefern, ohne alle relevanten Zusammenhänge zu kennen. Robinhood bewahrt deshalb auch verworfene Verdachtsfälle mit ihrem Kontext auf. Für Teams, die ähnliche Prüfagenten einsetzen, sind die begrenzten Datenzugriffe und die Rückverfolgbarkeit jeder Entscheidung unmittelbar überprüfbare Qualitätskriterien.
Quelle: Robinhood Engineering, „Security Review at the Speed of Agents“, 19.10.2026: https://robinhood.com/us/en/careers/blog/security-review-at-the-speed-of-agents/