Zusammenfassung

  • draft-smith-opsawg-ai-network-governance-01 erklärt, dass mitgeteilte KI-Beschränkungen die unabhängige programmatische Durchsetzung nicht ersetzen.
  • Zulässiger Vorschlag, angenommene Management-Operation und ausgelöster Rollback beweisen weder dieselbe Autorität noch einen wiederhergestellten Dienst.

Ein verantwortungsvoll formulierter Prompt kann die falsche Policy perfekt wiedergeben.

Das ist der unangenehme Ausgangspunkt für autonome Netzoperationen. Der KI-Dienst kann sich an jede sichtbare Grenze halten, während der lokale Executor eine ältere Allow List, einen unvollständigen Zähler oder einen noch nicht angekommenen Widerruf verwendet.

draft-smith-opsawg-ai-network-governance-01 vom 27. September 2026 zieht deshalb eine wichtige Linie. Das Dokument ist ein aktiver individueller Internet-Draft ohne IETF-Billigung, formalen Standardsrang oder RFC-Stream. Der Kopf nennt Informational als Ziel. Es ist ein Architekturvorschlag, keine Norm und kein Einsatznachweis.

Sein enger Scope verlangt direkten Managementzugriff auf Router oder Switch, einen externen KI-Dienst für Analyse und Vorschläge, autonome Änderungen ohne Einzelgenehmigung und Schnittstellen wie NETCONF, RESTCONF oder gNMI. Reine Beratung mit menschlicher Ausführung ist ausgenommen.

Der externe Dienst schlägt vor; der lokale Agent sammelt, erkennt, prüft und handelt. Die KI darf keinen direkten Gerätezugang bekommen. Damit bleibt die probabilistische Komponente von Credentials und Ausführung getrennt. Der lokale Agent wird aber zum privilegierten Knoten von Policy, Historie und Wirkung.

Das Action Registry enthält fest implementierte Aktionen mit Parametern, Risiko und Reversibilität. Die Operator Allow List wählt den im Deployment erlaubten Teil. Nicht registrierte Vorschläge werden verworfen; die KI kann keine Typen erfinden. Parameter außerhalb sicherer Grenzen bleiben verboten.

Allowed und blocked actions, protected targets, Raten und Risikodeckel sollen im Prompt stehen. Das senkt unnötige Vorschläge und verbessert Erklärungen. Doch Section 16 sagt ausdrücklich: Kommunikation ersetzt Enforcement nicht. Jede Empfehlung muss unabhängig geprüft werden. Section 17 verteilt die Kontrolle auf Prompt, Parser, Guardrail und Execution Layer.

Damit entsteht eine Beweispflicht. Ein Action Receipt muss den menschlich genehmigten Snapshot, Registry- und Listenstände, Target Rules, Parametergrenzen, Risiko, Rate State, Degradation, Widerruf, Vorschlag, Parse-Ergebnis, Verdict, letzte Prüfung, authentisierte Operation, Pre-State, Reply, frische Verifikation und Rollback oder Eskalation verbinden.

Der Prompt-Hash identifiziert nur eine Projektion für den externen Dienst. Sie kann sensible Regeln auslassen, Muster vereinfachen oder einen früheren Rate-Stand zeigen. „Guardrail passed“ ohne Eingaben zeigt ebenso wenig, weshalb das Urteil galt.

Die vorgeschlagenen Limits machen den historischen Charakter sichtbar. Fünf Remediation Actions pro Stunde mit vorgeschlagenem Maximum zwanzig, drei pro Target in 24 Stunden mit Maximum fünf sowie weitere Grenzen für irreversible Aktionen, KI-Anfragen und Retries sind Draftwerte, keine universell validierten Konstanten.

„Fünfte Aktion dieser Stunde“ setzt vollständige Events, Clock, Window und Kontinuität nach Neustart voraus. Cooldown, Retry, Revocation und Degradation tun das ebenfalls.

Section 17.3 empfiehlt stateless checks, wo möglich, mit Eingaben aus einem persistenten Audit Trail. Das verhindert Zählerverlust beim Restart, beseitigt den Zustand aber nicht. Log-Integrität, Reihenfolge, Retention, Zeit, Policy-Aktivierung und Replikatkonvergenz werden zu Sicherheitsmerkmalen.

Die Fail-safe-Beispiele passen: Unlesbare Rate-Daten bedeuten Limit erschöpft; Fehler im Target Matching bedeuten geschützt; unerreichbares Registry bedeutet unregistriert. Unbekanntes darf nicht zu Erlaubnis werden.

Nach dem Policy-Entscheid folgt die Gerätewirklichkeit. Der Agent soll Pre-State aufnehmen, frische Telemetrie holen und bei fehlender Verbesserung zurückrollen. Cache und Duplicate Suppression sind keine Recovery-Evidenz.

Ein Snapshot stellt jedoch keine verlorenen Pakete, beendeten Sessions, geleerten Queues oder entfernten Timer wieder her. Rollback ist eine weitere Vorwärtsoperation in einem laufenden System. Er benötigt eigenen Reply, Readback und Service-Nachweis.

Auch Single Target ist nicht Single Impact. Interface oder Routing-Metrik können in einer gemeinsamen Failure Domain liegen. Lokale Syntax kann durch Konvergenz entfernte Wirkung erzeugen.

Bei Prompt Injection können geräteerzeugte Logs und Beschreibungen das Modell beeinflussen. Sanitizing hilft; die Architektur lebt von advisory-only und unabhängiger Prüfung. Tests müssen Parser, Registry, Target, Parameter, History, Execution und Failover durchlaufen, nicht nur eine Modellablehnung zeigen.

Der Draft nennt den Audit Trail den primären Accountability-Mechanismus und empfiehlt Integritätsschutz sowie externe Aufbewahrung. Dorthin gehört der Policy-Beleg pro Aktion. Ein Startup Config Log erklärt keine spätere Handlung nach Reloads.

Die Autoren führen die Konzepte auf Production-Erfahrung zurück. Das ist ihre Aussage, keine unabhängige Studie mit Umfang und Resultaten. Schwellen und Controls bleiben lokal zu testende Annahmen.

Heng Lus Minimum Initial Specification spricht für prüfbare Invarianten: Die KI erweitert das Aktionsvokabular nicht; unbekannte Policy scheitert geschlossen; der Agent ändert seine Regeln nicht; jede Mutation benennt ihre Autorität. Reality Layers trennt „allowed“ vom Zustand des Netzes. Running-Code Primacy verlangt Readback und Dienstwirkung.

Quellen