Cloudflare hat am 18. Juni 2026 einen Beitrag veröffentlicht, der auf den ersten Blick wie eine weitere KI-Sicherheitsgeschichte wirkt. Beim zweiten Hinsehen ist er deutlich interessanter: Das Unternehmen beschreibt, wie aus einem kleinen Security-Skill ein modellagnostischer Vulnerability-Harness geworden ist, der über mehrere Stufen hinweg Schwachstellen sucht, validiert und für die weitere Bearbeitung aufbereitet. Die eigentliche Nachricht ist nicht, dass ein LLM Code liest. Die Nachricht ist, dass KI-Sicherheit in der Praxis nur dann skaliert, wenn sie wie eine echte Pipeline behandelt wird.
Für FreshCore-Leser ist das aus mindestens drei Gründen relevant. Erstens zeigt es, wie sich KI-Funktionen vom Chatbot-Feeling entfernen und in operativen Werkzeugen ankommen. Zweitens macht der Beitrag sichtbar, dass Sicherheit nicht an der Modellqualität allein hängt, sondern an Orchestrierung, Zustandsverwaltung, Validierung und Wiederholbarkeit. Drittens ist das Thema direkt anschlussfähig an alles, was mit Monitoring, Automation, Incident Response und DevSecOps zu tun hat. Genau dort liegen die Parallelen zu realen Betriebsprozessen: Ein gutes System ist nicht nur clever, sondern robust genug, um unter Last, bei Wiederholungen und im Fehlerfall konsistent zu bleiben.
Worum es bei dem Harness geht
Cloudflare beschreibt einen Weg, der in vielen Teams noch fehlt: Statt einen KI-Agenten einfach auf ein Repo loszulassen, zerlegt das Unternehmen die Aufgabe in klar getrennte Phasen. Eine erste Version begann als rund 450 Zeilen großer Security-Skill. Daraus wurde später ein vollständiger Workflow mit Recon, Hunt und Validate, ergänzt um weitere Schichten wie Dedup, Trace, Feedback und Report. Damit wird die Security-Arbeit nicht nur automatisiert, sondern strukturiert.
Das ist ein wichtiger Unterschied. Ein Chatbot beantwortet Fragen. Ein Harness bearbeitet Arbeitsschritte. Das klingt banal, ist aber operativ entscheidend. Sobald eine Sicherheitsprüfung mehrere Repos, mehrere Attack-Classes und mehrere Kontrollpunkte umfasst, reicht es nicht mehr, wenn ein Modell „irgendwie“ gute Antworten produziert. Dann braucht man einen Prozess, der Aufgaben persistent speichert, Ergebnisse gegeneinander prüft und Wiederholungen sauber aushält. Cloudflare schreibt ausdrücklich, dass ein einzelner Run nur einen Teil der Bugs findet und dass erst mehrere Durchläufe mit externer Zustandsverwaltung ein brauchbares Bild ergeben.
Warum Modellagnostik wichtig ist
Besonders stark ist die Entscheidung, den Harness nicht an ein einziges Modell zu binden. Cloudflare argumentiert, dass verschiedene Modelle unterschiedliche Bugs finden und deshalb austauschbar eingesetzt werden sollten. Das ist praktisch vernünftig und strategisch klug. In der KI-Welt ändern sich Preis, Leistung und Verfügbarkeit eines Modells laufend. Wer die Sicherheitslogik an ein einzelnes Modell koppelt, baut sich stille Abhängigkeiten ein. Wer den Orchestrator dagegen als stabile Schicht versteht, kann Modelle wechseln, ohne den gesamten Prozess neu zu entwerfen.
Für Betreiber bedeutet das: Die wertvolle Einheit ist nicht das Modell, sondern die Kontrolllogik darum herum. Genau hier liegt die Parallele zu klassischer Infrastruktur. Auch dort ist nicht der einzelne Server das strategische Asset, sondern die Fähigkeit, Zustände reproduzierbar auszurollen, zu prüfen und wiederherzustellen. Ein durchdachter Harness ist im Grunde eine Sicherheits- und Qualitätsplattform. Er trennt Eingabe, Prüfung, Verifikation und Auswertung so, dass menschliche Review-Zeit nur noch für wirklich belastbare Ergebnisse verwendet wird.
Was an dem Ansatz technisch überzeugt
Der Beitrag nennt mehrere Punkte, die in der Praxis oft unterschätzt werden. Erstens: Persistenz. Wenn ein Lauf abbricht, darf nicht die gesamte Analyse verloren sein. Zweitens: Entkopplung von Kontext. Ein Agent mit zu viel Kontext wird langsamer, ungenauer und vergisst unter Umständen genau die Erkenntnisse, die er vorher mühsam gesammelt hat. Drittens: Validierung durch eine andere Instanz. Cloudflare lässt die Ergebnisse nicht nur generieren, sondern zusätzlich adversarial prüfen und später noch einmal unabhängig verifizieren. Das reduziert Fehlalarme und macht die Ergebnisse für Ingenieure belastbarer.
Der Beitrag beschreibt außerdem, dass der gesamte Fleet-Scanner auf 128 Repositories skaliert wurde. Aus 20.799 Rohkandidaten wurden am Ende 7.245 bearbeitbare Findings. Dazwischen liegen Validierung, Deduplication, Re-Checks und eine Menge Noise-Reduktion. Genau diese Zahl ist die eigentliche Pointe: KI produziert im Sicherheitskontext zunächst sehr viel mehr Kandidaten als echte Erkenntnisse. Der Mehrwert entsteht nicht beim ersten Output, sondern beim Filtern, Priorisieren und Wiederholen. Das ist eine sehr unromantische, aber richtige Sicht auf KI im Betrieb.
- Recon schafft Kontext, damit später nicht im Nebel gesucht wird.
- Hunt erzeugt gezielte Angriffe statt allgemeines Raten.
- Validate verhindert, dass plausible Fehler als echte Findings durchrutschen.
- Dedup reduziert doppelte Arbeit und vermeidet Ticket-Müll.
- Trace verbindet einzelne Repos und zeigt Abhängigkeiten auf.
- Feedback verbessert den nächsten Lauf statt nur den aktuellen.
Was Teams daraus lernen sollten
Die wichtigste Lehre ist nicht, dass jeder sofort einen eigenen KI-Vulnerability-Harness bauen sollte. Die eigentliche Lehre ist: Sobald KI operative Aufgaben übernimmt, müssen Zustandsführung, Reproduzierbarkeit und Gegenprüfung mitgedacht werden. Wer heute mit Agenten experimentiert, baut oft nur die Vorderseite des Systems. Cloudflare zeigt, dass die produktive Seite dahinter liegt: Datenbank statt Chat-Verlauf, Validator statt Bauchgefühl, Orchestrator statt Prompt-Sammlung.
Das ist besonders relevant für Security-Teams, aber nicht nur für sie. DevOps-Teams kennen das Muster aus anderen Bereichen: Ein Alarm ohne Historie ist schwer zu bewerten. Ein Heartbeat ohne Zustandsmodell ist schwer zu interpretieren. Ein Incident ohne Timeline ist schwer postmortem-fähig. Das Gleiche gilt hier. Erst wenn ein KI-System Entscheidungen nachvollziehbar speichert, lässt es sich sauber betreiben. Sonst bleibt es ein beeindruckender Demo-Generator.
Auch ökonomisch ist der Ansatz interessant. Cloudflare macht klar, dass der teure Teil nicht das reine Modell ist, sondern das wiederholte, kontrollierte Abarbeiten in einem Prozess. Wer KI in sicherheitskritische Workflows integriert, sollte deshalb früh über Kosten, Wiederholbarkeit und Nutzungsmuster nachdenken. Ein Harness ist kein hübsches Experiment, sondern Betriebstechnik. Genau deshalb lohnt sich die Trennung von Modellen, Runs und Validierungsschritten.
Die Grenze des Ganzen
So überzeugend der Ansatz ist, er bleibt eine technische Maschine, keine automatische Wahrheit. Ein Harness kann gute Hinweise liefern, aber keine Governance ersetzen. Auch Cloudflare betont indirekt, dass menschliche Einordnung weiter nötig bleibt. Wer Findings ungeprüft in Workflows kippt, verschiebt das Problem nur. Die Qualität entsteht erst dann, wenn der Prozess so gebaut ist, dass nur verlässliche, begründete Ergebnisse weiterkommen. Das ist anstrengender als eine reine Prompt-Lösung, aber genau deshalb brauchbarer.
Für FreshCore-Leser ist das der Kernpunkt: Die Zukunft der KI im Betrieb wird nicht von immer längeren Prompts gewonnen, sondern von besserer Infrastruktur um die Modelle herum. Agenten, die nur reden, bleiben Spielzeug. Agenten, die prüfen, speichern, wiederholen und gegeneinander validieren, werden zu Werkzeugen. Cloudflare liefert mit diesem Beitrag ein gutes Beispiel dafür, wie dieser Übergang aussieht.
Fazit: Der neue Cloudflare-Harness ist keine glatte Marketingmeldung, sondern ein Hinweis darauf, wohin sich KI-gestützte Sicherheitsarbeit entwickelt. Weg vom einzelnen Modell, hin zu einer belastbaren Orchestrierungsschicht mit klaren Prüfungen, Zuständen und Rollen. Das ist für Security, DevOps und Plattform-Teams mindestens so wichtig wie die Frage, welches Modell gerade die besten Benchmarks liefert.
Quellen: Cloudflare Blog, "Build your own vulnerability harness" vom 18. Juni 2026. Bildquelle: Cloudflare Blog, Hero-Grafik desselben Beitrags.
