Drift-Aware Governance-as-Code for Agentic Cloud Operations: Formalizing State Certifiability and Testing Dynamic Authority Control in an AWS Testbed

In der modernen digitalen Welt verlassen sich Unternehmen auf riesige Netzwerke von Computerservern und Softwarewerkzeugen, um ihre Geschäfte zu führen. Um diese Systeme reibungslos am Laufen zu halten, nutzen Organisationen automatisierte Programme, die oft durch künstliche Intelligenz gesteuert werden, um Entscheidungen zu treffen und Probleme ohne menschliche Hilfe zu lösen. Diese Programme können Dienste hochskalieren, Sicherheitseinstellungen ändern oder defekte Komponenten in einem Bruchteil einer Sekunde neu starten. Diese automatisierten Agenten operieren jedoch auf Basis einer Karte des Systems, das sie verwalten sollen. Diese Karte ist eine Liste von Regeln und Konfigurationen, die beschreiben, wie das System aussehen sollte. Das Problem entsteht, wenn sich das tatsächliche System auf eine Weise verändert, von der die Karte nichts weiß. Diese Lücke zwischen dem, was das System sein sollte, und dem, was es in jedem gegebenen Moment tatsächlich ist, wird als „Drift“ bezeichnet. Wenn ein automatisierter Agent versucht, ein Problem mithilfe einer veralteten Karte zu lösen, könnte er eine Änderung vornehmen, die laut der Karte sicher ist, in der Realität jedoch gefährlich ist. Die Kernherausforderung für Ingenieure besteht darin, herauszufinden, wann die Karte so unzuverlässig ist, dass der Agent aufhören sollte, Änderungen vorzunehmen, und stattdin auf einen Menschen warten muss, der die Situation überprüft.

Ein Forscherteam setzte sich zum Ziel, dieses spezifische Problem zu lösen, indem es eine neue Art und Weise entwickelte, diese automatisierten Agenten zu steuern. Sie entwickelten ein System, das ständig prüft, wie weit das reale System von seinem beabsichtigten Design abweicht. Anstatt nur zu prüfen, ob eine Regel befolgt wurde, misst ihr System die Qualität der Informationen, die der Agent verwendet. Sie nennen dieses Konzept „State Certifiability“ (Zustandszertifizierbarkeit), was vereinfacht bedeutet zu fragen: Verfügen wir über genügend vertrauenswürdige Beweise, um zu sagen, dass das Verständnis des Agenten über das System genau genug ist, um ihn handeln zu lassen? Wenn die Beweislage schwach ist, weil sich das System zu stark verändert hat oder die Daten zu alt sind, reduziert das System automatisch die Macht des Agenten. Es schaltet den Agenten nicht vollständig ab; stattdessen sperrt es ihn daran, große, riskante Änderungen vorzunehmen, während es ihm dennoch erlaubt, eine kleine, sichere Gruppe von Aktionen durchzuführen, die darauf ausgelegt sind, das Problem zu beheben und Ordnung wiederherzustellen.

Um diese Idee zu testen, bauten die Forscher eine kontrollierte Umgebung unter Verwendung von Amazon Web Services, einer populären Cloud-Computing-Plattform. Sie schufen ein Testfeld, in dem sie verschiedene Ebenen von Drift simulieren konnten, die von keiner Veränderung bis hin zu schweren, chaotischen Unstimmigkeiten zwischen Plan und Realität reichten. Sie führten tausende Experimente durch, bei denen automatisierte Agenten Aufgaben wie das Rotieren von Sicherheitspasswörtern, das Hochskalieren von Computer-Workloads oder das Isolieren kompromittierter Ressourcen ausführten. Sie verglichen drei verschiedene Ansätze: das Arbeiten der Agenten ohne jegliche Einschränkungen, die Verwendung eines Standard-Sets fester Regeln, die sich nicht basierend auf dem Systemzustand änderten, und ihr neues „drift-bewusstes“ System, das die Autorität des Agenten in Echtzeit anpasste. Die Ergebnisse waren beeindruckend. Wenn das System in einem Zustand schweren Drifts war, brachen die uneingeschränkten Agenten in 92,3 % der Fälle die Regeln. Die Agenten mit festen Regeln brachen sie in 55,2 % der Fälle. Die von dem neuen drift-bewussten System gesteuerten Agenten brachen die Regeln jedoch nur in 25 % der Fälle. Dies zeigte, dass, indem man die Macht des Agenten von der Güte seines Verständnisses des aktuellen Systemzustands abhängig machte, die Forscher das Risiko gefährlicher Fehler drastisch reduzieren konnten.

Die Studie untersuchte auch, was passiert, wenn das System entscheidet, einen Agenten auszusperren. Eine häufige Befürchtung ist, dass das Aussperren eines Agenten verhindern könnte, ein kritisches Problem zu lösen, wodurch das System kaputt bleibt. Die Forscher testeten ein spezielles Design, bei dem der Agent selbst im gesperrten Zustand in der Lage war, eine begrenzte Anzahl von „nur zur Wiederherstellung geeigneter“ Aktionen durchzuführen, wie etwa das Isolieren eines kompromittierten Servers oder das Rückgängigmachen einer fehlerhaften Änderung. Sie fanden heraus, dass dieser Ansatz ein kluger Mittelweg war. Ein striktes Aussperren, das alle Aktionen stoppte, reduzierte das Risiko unsicherer Bewegungen um über 80 %, verhinderte aber auch, dass der Agent das Problem in den meisten Fällen lösen konnte. Der „Recovery-Only“-Ansatz hingegen reduzierte das Risiko unsicherer Bewegungen um etwa 55 %, ermöglichte es dem Agenten aber dennoch, das Problem in fast 84 % der Fälle erfolgreich zu beheben. Dies demonstrierte, dass es möglich ist, ein System sicher zu halten, ohne es zu lähmen, vorausgesetzt, der Agent darf nur spezifische, vorab genehmigte Schritte unternehmen, um Ordnung wiederherzustellen.

Einer der wichtigsten Funde der Forschung betraf die Natur des „Lockout“-Punktes (Aussperr-Punkt). Das Team hatte einen spezifischen Schwellenwert festgelegt, an dem sie den normalen Betrieb des Agenten stoppen würden, in der Hoffnung, dass diese Zahl einen natürlichen Bruchpunkt darstellt, an dem das System zu gefährlich zu verwalten sei. Ihre Daten zeigten jedoch, dass das Risiko von Fehlern nicht abrupt an diesem spezifen Punkt anstieg. Stattdessen nahm das Risiko graduell zu, je weiter das System von seinem Plan abwich. Dies bedeutet, dass die Entscheidung, einen Agenten auszusperren, keine Entdeckung eines Naturgesetzes ist, sondern eine bewusste Entscheidung, die von der Organisation getroffen wird. Es ist eine Richtlinienentscheidung zu sagen: „Wir sind bereit, ein gewisses Risiko zu akzeptieren, aber sobald die Unsicherheit diesen Punkt überschreitet, werden wir der Karte des Agenten nicht mehr vertrauen.“ Die Forscher kamen zu dem Schluss, dass es keine einzige magische Zahl gibt, die für jede Situation funktioniert; stattdessen müssen Organisationen ihre eigenen Grenzen basierend auf ihren spezifischen Bedürfnissen und ihrer Risikotoleranz sorgfältig wählen.

Die Studie bestätigte auch, dass das neue System selbst dann funktioniert, wenn die Daten, auf die es sich stützt, unvollkommen sind. Sie testeten, wie das System performte, wenn die Messungen des Drifts leicht ungenau waren oder wenn die Daten etwas veraltet waren. Das System blieb robust, identifizierte gefährliche Situationen korrekt und schränkte die Macht des Agenten in fast allen Fällen ein. Darüber hinaus führten sie eine separate Validierung unter Verwendung echter, Live-Befehle auf der Cloud-Plattform durch, um sicherzustellen, dass das System außerhalb einer Simulation funktioniert. In diesen realen Tests reduzierte das neue System unbefugte Aktionen von fast 9 % auf nur etwas über 1 %, was bewies, dass das Konzept nicht nur in der Theorie, sondern auch in der Praxis funktioniert. Die Forschung legt nahe, dass die Zukunft des sicheren, automatisierten Cloud-Betriebs darin liegt, die Autorität des Agenten als eine flexible Variable zu behandeln. Indem Organisationen ständig prüfen, ob das Wissen des Agenten vertrauenswürdig genug ist, um eine bestimmte Aktion zu rechtfertigen, können sie ihre automatisierten Systeme schneller und freier arbeiten lassen, während sie gleichzeitig eine feste Hand für die Sicherheit behalten.