Wie Stave mit KI-Agenten Cloud-Sicherheit automatisch validiert

Vor einem Jahr wollte Stave nur ein CLI-Tool für Solo-Entwickler sein. Doch die Architektur, die für menschliche Produktivität entworfen wurde, entpuppte sich als perfekte Grundlage für KI-Agenten. Mit rein maschinell lesbaren Verträgen und binären Testresultaten können autonome Agenten heute Cloud-Sicherheit analysieren – ohne Code, Dokumentation oder menschliche Hilfe. Die jüngsten Tests mit fünf verschiedenen Reasoning-Engines zeigen: Die Technologie funktioniert. Und sie könnte die Art, wie Unternehmen Sicherheit betreiben, grundlegend verändern.

Von einem CLI-Tool zum agentenzentrierten Ökosystem

Als ich mit der Entwicklung von Stave begann, war das Ziel klar: Ein einziges Tool, das eine einzelne Person warten und bedienen kann. Die Architektur sollte simpel sein, ohne proprietäre Formate oder nicht-deterministische Ausgaben. Stattdessen setzte ich auf standardisierte JSON-Schemata, klare Exit-Codes und kleine, kombinierbare Komponenten – alles Entscheidungen, die zunächst der menschlichen Effizienz dienten.

Doch diese Entscheidungen legten gleichzeitig den Grundstein für Agenten-Kompatibilität. Ein Agent benötigt keine proprietären Formate, die er erst entschlüsseln muss. Er braucht keine vagen Bewertungen, sondern klare Ja/Nein-Entscheidungen. Und er kann keine monolithischen Systeme warten, die niemand versteht. Staves Architektur erfüllt genau diese Anforderungen – nur als Nebenprodukt.

Was agentenzentrierte Sicherheit wirklich bedeutet

Die meisten Sicherheitsanbieter integrieren heute KI als "Copiloten": Sie fassen Befunde zusammen, beantworten Fragen oder schlagen Korrekturen vor. Doch das sind nur Oberflächen-Features auf Basis alter Architekturprinzipien. Agentenzentriert bedeutet etwas anderes: Ein Tool, das Agenten nicht nur als Nutzer, sondern als aktive Entwickler anspricht.

Der entscheidende Test ist simpel: Kann ein Agent, der nie zuvor den Quellcode oder interne Dokumentation gesehen hat, allein anhand der veröffentlichten Schnittstellen korrekte Ergebnisse liefern? Stave besteht diesen Test – nicht nur einmal, sondern fünfmal. Und in zwei Fällen sogar völlig blind, ohne vorherige Kontextinformationen.

Die unsichtbaren Verträge hinter der Automatisierung

Jede Schnittstelle in Staves Pipeline basiert auf drei unverhandelbaren Prinzipien:

• Maschinell lesbare Spezifikationen: Statt menschlicher Dokumentation nutzt Stave JSON-Schemata oder YAML-Dateien. Agenten parsen diese, generieren passende Ausgaben und validieren ihre Ergebnisse automatisch.

• Binäre Assertionen: Jeder Schritt endet mit einem klaren Erfolg oder Misserfolg. Der Befehl stave validate --strict liefert Exit-Code 0 bei Erfolg oder einen Fehlercode. stave apply erzeugt entweder deterministische Befunde oder keine Ausgabe. Subjektive Bewertungen wie "wirkt das korrekt?" haben hier keinen Platz.

• Handlungsorientierte Fehlerrückmeldung: Scheitert eine Assertion, nennt die Fehlermeldung präzise den betroffenen Feldnamen und die erwartete Struktur. Der Agent korrigiert den Wert und startet neu – ganz ohne menschliche Interpretation.

Diese Prinzipien lassen sich in einer Pipeline visualisieren, die Agenten genauso durchlaufen wie menschliche Entwickler:

Steampipe-Tabellen-Schema
↓
Veröffentlichte Mapping-YAML (Agent liest Spaltennamen und Feldzuordnungen)
↓
`stave validate --strict` (Assertion: Exit-Code 0?)
↓
`stave apply` (Assertion: Deterministische Befunde?)
↓
`stave export-sir` (SIR: Stave Intermediate Representation als JSONL-Tripel oder SMT-LIB-Assertionen)
↓
Reasoning-Spec-YAML (Agent übersetzt Logikvorgaben in Engine-spezifischen Code)
↓
Vergleich mit Golden Answer (Assertion: Übereinstimmung?)

Jeder Pfeil in dieser Kette ist ein Vertrag. Jeder Vertrag ist maschinell lesbar. Jede Assertion ist binär. Ein Agent durchläuft diese Pipeline wie ein Entwickler – mit dem entscheidenden Unterschied: Er muss nie fragen "Ist das richtig?", weil die Verträge die Antwort automatisch liefern.

Die fünf Tests, die alles ändern könnten

Für die Experimente schrieben wir sogenannte Reasoning-Spezifikationen – YAML-Dateien, die eine Sicherheitsfrage, die Eingabedaten, eine Schritt-für-Schritt-Logik und das erwartete Ausgabeformat definieren. Wichtig: Diese Spezifikationen enthalten keine Implementierungsdetails, sondern reine Logikvorgaben wie "Ein Bucket ist öffentlich, wenn die Policy den Principal AllUsers erlaubt".

Den Agenten gaben wir ausschließlich diese Spezifikationen und die exportierten Daten – ohne Zugriff auf unseren Code. Ihre Aufgabe bestand darin, die Logikvorgaben in die spezifische Syntax der jeweiligen Reasoning-Engine zu übersetzen: Soufflés Datalog, Z3s SMT-LIB, Clingos ASP-Atome oder Prologs Beweisbäume.

| Versuch | Engine | Frage | Blind? | Ergebnis | |---------|--------|-------|--------|----------| | 1 | Z3 | Können anonyme Nutzer auf diesen S3-Bucket zugreifen? | Nein | Erfolg – korrekte Entscheidung (SAT-Beweis mit Angriffsweg) | | 2 | Soufflé | Wie viele Ressourcen kann eine anonyme Identität erreichen? | Nein | Erfolg – Zählung: 12 (bytegenau identisch) | | 3 | Clingo | Welche Verstöße werden in dieser Konfiguration ausgelöst? | Ja | Erfolg – alle 4 Verstöße korrekt identifiziert | | 4 | Prolog | Wie sieht der Beweibaum für diesen Angriffsweg aus? | Ja | Erfolg – 12 Beweisbäume korrekt generiert | | 5 | PRISM | Wie hoch ist die Erfolgswahrscheinlichkeit eines Angriffs? | Nein | Erfolg – 0.412 (±0.005) |

Die Tests deckten sogar zwei reale Defekte auf: In einem Fall stimmte der Agent mit der Engine überein, während unser Golden-Answer-Datensatz einen Fehler enthielt (wir hatten 6 statt der korrekten 12 gezählt). In einem anderen Fall zeigte sich eine Unschärfe in der Spezifikation – das Feld mfa_enforced existierte im Export als has_mfa_enforced. Die Verträge ermöglichten es den Agenten, unsere eigenen Testmethoden zu debuggen.

Solche Belege für autonome Sicherheitsreasoning hat bisher kein anderer Anbieter veröffentlicht.

Was das für Unternehmen bedeutet

Vom Teamproblem zur automatisierten Sicherheitskontrolle

Traditionell erfordert die Einführung von Cloud-Sicherheitslösungen:

• Spezialisierte Teams für Einrichtung und Wartung
• Manuelle Konfiguration proprietärer Formate
• Subjektive Bewertungen von Sicherheitsbefunden
• Regelmäßige Anpassungen bei Tool-Updates

Staves Ansatz eliminiert diese Hürden. Agenten können Sicherheitslogik direkt aus veröffentlichten Verträgen ableiten und validieren. Das reduziert nicht nur den manuellen Aufwand, sondern erhöht auch die Zuverlässigkeit – schließlich arbeiten Agenten nach klaren Regeln, während menschliche Analysten anfällig für Fehler und Unstimmigkeiten sind.

Unternehmen müssen nicht mehr warten, bis ein Sicherheitsingenieur Kapazitäten für Analysen hat. Stattdessen können sie autonome Agenten einsetzen, die rund um die Uhr Sicherheitsrisiken erkennen und bewerten. Die Verträge sorgen dafür, dass die Ergebnisse reproduzierbar und nachvollziehbar bleiben – selbst wenn die zugrundeliegenden Reasoning-Engines komplex sind.

Ein Blick in die Zukunft: Agenten als Sicherheitsarchitekten

Die jüngsten Tests sind erst der Anfang. Wenn Agenten heute bereits Sicherheitsfragen auf Basis maschinell lesbarer Verträge beantworten können, ist der nächste logische Schritt ihre aktive Mitgestaltung von Sicherheitsarchitekturen. Stellen Sie sich vor, ein Agent erkennt nicht nur ein Sicherheitsrisiko, sondern schlägt automatisch eine korrigierende Infrastrukturänderung vor – und validiert diese gegen denselben Vertrag.

Die Technologie ist bereit. Die Frage ist nicht mehr, ob Agenten Sicherheit autonom bewerten können, sondern wie schnell Unternehmen diese Möglichkeiten nutzen werden. Die Ära der agentenzentrierten Cloud-Sicherheit hat begonnen – und sie wird die Branche nachhaltig verändern.