KENSAI-Forschung: Vorbedingungen sind wichtiger als größere Versprechen zur agentenbasierten Sicherheit

Die entscheidende Erkenntnis aus den jüngsten KENSAI-Abläufen ist einfach: Agentenbasierte Sicherheit braucht keine lautstärkere Selbstgewissheit. Sie braucht strengere Vorbedingungen, bevor ein Ergebnis als Behauptung gelten darf.

Der eigentliche Fehlermodus

Moderne Sicherheitsautomatisierung ist sehr gut darin, Ergebnisse zu erzeugen. Das ist nicht dasselbe, wie Wahrheit zu erzeugen. Ein Scanner kann einen passiven Befund ohne nachweisbare Auswirkungen liefern. Ein Test-Runner kann fehlschlagen, weil die API nie gestartet wurde. In einem Veröffentlichungssystem kann eine Datei in einem Verzeichnisbaum vorhanden sein, während die ausgelieferte Spiegelkopie veraltet bleibt.

Das sind unterschiedliche Probleme, doch sie haben dieselbe Ursache: Das System hat eine nachgelagerte Behauptung zugelassen, bevor die vorgelagerte Vorbedingung nachgewiesen war.

Vorbedingungen sind die verborgene Steuerungsebene

Bei agentenbasierter Sicherheit sollte die Vorbedingungsebene genauso ernst genommen werden wie die Modellebene. Bevor eine Testsuite Produktfehler meldet, sollte sie nachweisen, dass die erforderlichen Dienste fehlerfrei funktionieren. Bevor eine Schwachstelle zur Einreichung weitergeleitet wird, sollte ihre Auswirkung nachgewiesen werden, anstatt passive Aufklärung als Fortschritt bei Bug-Bountys zu zählen. Bevor die Aktualität von Inhalten behauptet wird, sollten die Live-Route und der abgeleitete Index mit der Quelldatei übereinstimmen.

Das ist weniger glamourös, als eine weitere Agentenschleife hinzuzufügen. Es ist außerdem wertvoller. Vorbedingungen verwandeln Automatisierung von einem selbstsicheren Erzähler in ein kontrolliertes System.

Was KENSAI durchsetzt

KENSAI wendet dieses Muster bereits bei Bug-Bounty-Abläufen an: Befunde außerhalb des Geltungsbereichs, mit geringen Auswirkungen oder aus reiner Aufklärung dürfen nicht zur Einreichung gelangen. Dasselbe Muster gehört in die Entwicklung und Veröffentlichung. Eine Routenprüfung ist aussagekräftiger als eine Behauptung im Dashboard. Eine Live-Integritätsprüfung ist aussagekräftiger als ein nur angenommener Dienstbetrieb. Eine Nachweisschranke ist aussagekräftiger als eine Schweregradbezeichnung.

Die Testergebnisse vom 26. April haben dies erneut verdeutlicht. Die Root-Testsuite erzeugte Hunderte Fehler, doch der erste Schritt besteht nicht darin, die Anwendungslogik blind neu zu schreiben. Der erste Schritt besteht darin, den Runner prüfen zu lassen, ob seine API-Abhängigkeit online ist und ob seine Befehle für Testabdeckung und Ende-zu-Ende-Tests tatsächlich vorhanden sind.

Das Betriebsprinzip

Ein nützlicher Agent sollte sich drei leise Fragen stellen, bevor er laute Aussagen trifft: War die Voraussetzung erfüllt, hat sich das Artefakt geändert und wurde dies auf der öffentlichen Oberfläche nachgewiesen? Lautet eine Antwort nein, ist die richtige Ausgabe ein mit Belegen dokumentierter Blocker und keine Erfolgskennzeichnung.

Das ist die praktische Forschungsrichtung: weniger große Behauptungen, mehr ausführbare Wahrheit. Gewinnen werden die Systeme, die jede Behauptung mit einem Beleg versehen.

Fazit

Der sinnvolle Standard ist einfach: Behauptungen werden real, wenn Voraussetzung, Artefakt und Route vollständig übereinstimmen. Die heutige Arbeit hält diesen Standard sichtbar.