Zusammenfassung

  • Revision 02 des Entwurfs zur agentischen Sensorik begrenzt weitere Interaktionen beispielhaft mit einem dekrementierten Wert, lässt aber offen, wie eine Agentenidentität an die konkrete Befugnis für eine Sensor- oder Netzhandlung gebunden wird.
  • Eine gültige Attestierung kann den Zustand einer Umgebung für eine Bewertung belegen. Sie beweist weder die Autorisierung für diese Aufgabe noch die Weitergabe der Richtlinie, die Ausführung der Netzkonfiguration oder das Erreichen des Messziels.

Der Agent bestand die Attestierungsprüfung. Sein Softwareabbild stimmte, die erwartete Umgebung war messbar, der Schlüssel gültig. Daraufhin ließ die Orchestrierung ihn eine Route ändern und die Verarbeitung von Sensordaten auf einen anderen Standort verlagern. Erst später stellte sich heraus: Der Agent war für Diagnose und Empfehlung zugelassen, nicht für Ausführung. Der technische Nachweis war echt. Die daraus abgeleitete Vollmacht war erfunden.

Diese Trennung ist der produktivste Zugang zu Revision 02 von Solutions for enabling agentic sensing with network optimization. Carlos J. Bernardos, Alain Mourad und Muhammad Awais Jadoon reichten sie am 2. Oktober 2026 ein. Der Text beschreibt, wie eine Sensing Control Function eine Aufgabe an KI-Agenten für Sensorik, AIaS, übergibt. Diese wählen Sensorknoten und eine Verarbeitungsfunktion, koordinieren Konnektivität mit KI-Agenten für Netze, AIaN, und liefern Antworten zurück. Eine anschließende Überwachung kann eine Rekonfiguration anstoßen.

Der Status setzt die Beweisgrenze. Es handelt sich um einen aktiven individuellen Internet-Draft, nicht um ein vom NMRG angenommenes Dokument, einen IETF-Standard oder einen Einsatzbericht. Datatracker nennt weder Stream noch verantwortlichen Area Director oder formalen Standardisierungsstand. Als beabsichtigter Status steht Experimental im Text. Revision 02 ändert gegenüber 01 Datum, Ablauf, Seitenfluss und die Fördermittel-Danksagung, nicht aber den hier untersuchten Mechanismus. Die IANA Considerations lauten N/A; Security Considerations bleiben TBD.

Der Entwurf ist deshalb keine Ausführungs- oder Sicherheitsbescheinigung. Er ist ein nützlicher Architekturvorschlag, weil er Akteure und benötigte Governance-Felder sichtbar macht. Ein Nachrichtenformat, unabhängige Implementierungen, Interoperabilitätsspuren oder gemessene Ergebnisse liefert er nicht. Ein Sequenzdiagramm zeigt eine gewünschte Ordnung von Aufrufen, nicht die nachgewiesene Erhaltung von Autorität.

Attestierung beantwortet die Zustandsfrage

Attestierung im Sinne des RFC 9334 stellt Evidenz bereit, die eine Relying Party anhand ihrer Appraisal Policy bewertet. Je nach System kann sie Aussagen über Software, Konfiguration, Startzustand oder Geräteeigenschaften stützen. Das ist für eine belastbare Agentenarchitektur wertvoll: Ein Auftraggeber möchte wissen, welche Umgebung eine sensible Aufgabe ausführt.

Die Evidenz beantwortet aber nicht von selbst, ob diese Umgebung eine bestimmte Handlung vornehmen darf. Eine bekannte, unveränderte Diagnosekomponente kann weiterhin nur Leserechte haben. Ein Agent kann für Mandant A zugelassen und für Mandant B ausgeschlossen sein. Eine Netzfunktion kann Pfade vorschlagen, ohne sie anwenden zu dürfen. Eine Erlaubnis kann auf einen Zeitraum, einen Datentyp, eine Region oder eine Richtlinienversion beschränkt sein.

Zwischen „dies ist der erwartete Agent“ und „dieser Agent darf jetzt diese Route für diese Sensoraufgabe ändern“ liegt eine Relying-Party-Entscheidung. Sie muss Identität und Zustand mit Principal, Zweck, Fähigkeit, Ressource, Zeitraum und Kontext verbinden. Wer den zweiten Satz direkt aus dem ersten ableitet, verschiebt den schwächsten Teil des Systems hinter starke Kryptografie.

Auch eine Signatur löst das nicht. Sie kann eine Nachricht einem Schlüssel zuordnen und Manipulation erkennbar machen. Sie sagt nicht, ob der Unterzeichner die behauptete Fähigkeit besaß, ob die übermittelte Richtlinie aktuell war oder ob die reale Wirkung eintrat. Authentizität, Integrität, Autorisierung und Ergebnis sind getrennte Aussagen.

Der Interaktionswert ist keine Capability

Der Entwurf führt einen allowed level of agentic AI interactions ein. Er kann Kontakte zu Sensor-, Netz- oder bestimmten Eigentümeragenten begrenzen und beeinflussen, ob Agenten überwachen oder Rekonfigurationen vorschlagen dürfen. Der Wert könne als maximale Zahl von Hops, Ebenen, Worker-Agenten oder als Graphentiefe ausgedrückt werden; bei Delegation werde er beispielhaft um eins reduziert.

Die illustrative Kodierung verwendet 0 für keine Delegation, 1 für die Interaktion des lokalen AIaS mit einem lokalen AIaN, 2 für Kontakte zu weiteren Sensorknoten ohne deren weitere Delegation und 3 für zusätzliche Ebenen. An anderer Stelle sind weitere Interaktionen nur bei einem empfangenen Wert größer als 1 vorgesehen, jeweils mit Dekrement.

Als Topologiebudget ist das plausibel. Unbegrenzte Agentenketten werden schwieriger, und eine einfache Invariante lässt sich testen. Doch Graphentiefe ist nicht Workerzahl. Ein Elternagent kann auf derselben Ebene viele Kinder erzeugen. Hops begrenzen nicht automatisch parallele Zweige, administrative Domänen, Datenkopien, Wiederholungen oder Netzaktionen.

Vor allem beschreibt der Wert keine Befugnis. Darf ein Agent Telemetrie lesen, eine Konfiguration vorschlagen, sie anwenden, Rohdaten übertragen oder nur abgeleitete Daten verarbeiten? Für welche Ressource und wie lange? Der Wert zwei beantwortet keine dieser Fragen. Wer „noch eine Ebene übrig“ als allgemeine Erlaubnis liest, verwandelt eine Zählregel in ein unkontrolliertes Berechtigungsmodell.

Benötigt werden getrennte Grenzen wie maxDelegationDepth, maxWorkers, maxConcurrentBranches, maxAdministrativeDomains und maxActions. Jede Kante sollte Eltern- und Kindidentität, Werte vor und nach der Übergabe, Aufgabenfragment, Richtlinie und Begründung enthalten. Null beweist dann nur, dass ein Budget erschöpft ist, nicht dass alle vorherigen Handlungen autorisiert waren.

Fähigkeiten müssen sich beim Delegieren verengen

Ein Kind sollte nicht die gesamte Identität oder Macht des Elternagenten kopieren. Es erhält eine konkrete Capability: ein Signal in einem Gebiet und Zeitfenster erheben, eine bestimmte transformierte Datenklasse verarbeiten oder Konnektivität mit definierten Eigenschaften anfragen. Ein AIaN darf für diese Aufgabe einen Pfad beantragen, ohne Zugriff auf unbeteiligte Mandanten und Ressourcen zu erben.

Die Übergabe muss den verantwortlichen Principal, Aufgabenkennung, unveränderliche Richtlinienversion oder deren Hash, Datenklassen, erlaubte Transformationen, Ziele, Zeitfenster, geografischen oder administrativen Umfang, Weiterdelegation und verbleibende Budgets binden. Das Kind bestätigt, was es angenommen hat. Spätere Ergebnisse verweisen auf genau diese Kante.

Die Verengung muss monoton sein. Ein Kind darf den Bereich reduzieren oder weitere Delegation ablehnen. Es darf ohne neue Autorisierung keine lokale Verarbeitung in entfernte Verarbeitung umdeuten, die Quellmenge erweitern, Beobachtung in Ausführung verwandeln oder die Genauigkeitsgrenze zugunsten eines Energieziels lockern. Das wären neue Entscheidungen, keine internen Optimierungen.

Der Entwurf sagt ausdrücklich, dass die Entscheidung über zusätzliche Sensoraufgaben außerhalb seines Umfangs liegt und von Implementierung und lokalem Wissen abhängt. Genau dort kann Vollmacht unbemerkt wachsen. Ein Agent erfindet eine Teilaufgabe, wählt einen weiteren Sensor, fordert Netzänderungen an und überwacht anschließend das Ergebnis. Ohne Kantenbelege lässt sich nicht rekonstruieren, welche lokale Schlussfolgerung welchen physischen Effekt verursachte.

Governance-Felder sind keine Durchsetzungsbelege

Der Entwurf nennt wichtige Anforderungen: Rohdaten sollen eventuell lokal bleiben; lokale, entfernte oder teilweise Verarbeitung kann erlaubt sein; Verschlüsselung kann vorgeschrieben sein; Erzeuger oder administrative Domänen können zugelassen oder ausgeschlossen werden; Vertrauens- und Fusionsregeln können die Datenkombination steuern. Hinzu kommen Energie, räumliche und zeitliche Genauigkeit sowie Konfidenz.

Diese Anforderungen sind orthogonal. Verschlüsselung schützt Transport oder Speicherung, erlaubt aber keinen fremden Verarbeitungsort. Eine vertrauenswürdige Quelle garantiert keine ausreichende Messgenauigkeit. Ein günstiger Energieverbrauch beweist weder Datenlokalität noch Vollständigkeit. Und eine attestierte Netzkomponente darf nicht allein deshalb sämtliche Konfigurationen ändern.

Jede Richtlinie braucht Identität, Version, Herausgeber, Gültigkeit, Frische und gegebenenfalls Widerruf. Wenn eine Liste vertrauenswürdiger Quellen eine administrative Grenze überquert, muss das Kind die konkrete Version annehmen. Ein gleichnamiger lokaler Stand ist kein Ersatz. Sonst kann ein formell korrektes Kind mit veralteter oder fremder Bedeutung weiterarbeiten.

Security Considerations stehen weiterhin auf TBD. Das sollte in jedem Versuch sichtbar sein. Die Aufzählung von Governance-Feldern ist eine Anforderungssammlung, kein Threat Model und kein Protokoll. Ein Team darf nicht aus dem Vorkommen eines Feldnamens folgern, dass Vererbung, Replay-Schutz, Widerruf oder Enforcement bereits entworfen seien.

Eine Netzantwort ist noch keine Netzbeobachtung

Im Ablauf sendet AIaS eine Konnektivitätsanforderung über AIaN an eine Netzsteuerungsfunktion. Die Antwort kann belegen, dass eine Konfiguration angenommen oder angewendet wurde. Sie belegt nicht, dass Pakete den gewünschten Pfad nahmen, rechtzeitig ankamen, vertraulich blieben oder die gewählte Verarbeitungsfunktion erreichten.

RFC 9232 bietet einen Rahmen für Erzeugung, Export, Analyse und Nutzung von Netztelemetrie. Beobachtungen begründen jedoch nicht automatisch Kausalität. Sinkt die Latenz nach einer Änderung, können Last, Funkbedingungen oder ein paralleler Controller die Ursache sein. Erforderlich sind Konfigurationsauftrag, autorisierter Aktuator, Steuerungsbeleg und unabhängig zuordenbare Delivery-Beobachtungen.

Auf der Sensorseite genügt eine aggregierte Antwort ebenfalls nicht. Welche Quellen waren beteiligt? Welcher Zweig fehlte? Welche Vorverarbeitung fand statt? War die Synchronisation ausreichend? Welche Unsicherheit begleitet den KPI? Drei von vier Quellen werden nicht dadurch vollständig, dass eine Funktion „success“ zurückgibt. Abwesenheit ist kein Messwert null.

Energieziele machen die Trennung anschaulich. Entfernte Verarbeitung kann den Verbrauch eines Geräts senken und zugleich eine Lokalitätsregel brechen. Eine reduzierte Abtastrate kann Energie sparen und Genauigkeit verlieren. „Optimiert“ hat erst Bedeutung, wenn Zielvektor, harte Grenzen, Ausgangszustand und beobachtetes Resultat genannt werden.

Monitoring schafft eine neue Autoritätsgrenze

Der Ablauf endet mit Überwachung von Konnektivität, geschätzter Messgenauigkeit und Energie. Schwellen können Aktionen auslösen und zu einer Rekonfiguration führen. Das ist ein Feedback-System: Eine Beobachtung wird zur Ursache eines weiteren Eingriffs.

Der Beobachter sollte Beobachtung und Vorschlag liefern, nicht automatisch Aktuator werden. Für die Ausführung braucht es einen benannten Entscheidungsträger, die aktuelle Richtlinienversion, einen zugelassenen Aktuator, Umfang, Rückrollbedingung und eine neue Messung danach. Wer einen Schwellenwert erkennt, darf daraus kein Recht ableiten, Routing, Funkzustand, Rechenort oder Datenexposition zu verändern.

Eine falsche Autorisierung vervielfacht sich im Regelkreis. Hat der erste Agent eine Lokalitätsregel verloren oder seine Diagnosebefugnis zur Ausführung erweitert, bewertet die nächste Runde bereits einen verfälschten Zustand. Lokale Kennzahlen können sich verbessern, während die Kette sich vom Mandat entfernt.

Attestierung kann hier die Umgebung jeder Rolle belegen. Sie ersetzt aber nicht die Rollentrennung. Der Monitor, Entscheider und Aktuator können alle korrekt attestiert sein und dennoch falsch miteinander verbunden werden. Die Organisation muss die erlaubten Kanten definieren, nicht nur die Knoten prüfen.

Acht verknüpfte Belege statt eines Erfolgsflags

Erstens: ursprüngliche Aufgabe und verantwortlicher Principal. Zweitens: unveränderliche Richtlinie und erlaubte Transformationen. Drittens: jede Delegationskante, Kindidentität und verengte Capability. Viertens: Netzkonfigurationsauftrag und autorisierter Aktuator. Fünftens: Konfigurationsannahme und beobachtete Konnektivität. Sechstens: Verwahrung und Transformation der Sensordaten. Siebtens: KPI-Evidenz mit Unsicherheit und fehlenden Beiträgen. Achtens: Monitoring-Auslöser, Rekonfigurationsentscheidung und beobachtete Folge.

Ablehnung, Timeout, Teilergebnis, verifizierter Fehler und unbekannter Zustand müssen getrennt bleiben. Eine fehlende Kindantwort ist kein Nullwert. Wenn Richtlinienkontinuität nicht belegbar ist, muss der Agent stoppen oder unknown melden, statt die Lücke mit lokaler Zuversicht zu füllen.

Das entspricht Heng Lus Disziplin der Realitätsebenen. Attestierungsbefund, Richtlinie und Zähler sind symbolische Informationen. Delegation und Konfiguration sind Kontrollakte. Datenort, Paketlieferung und Messgenauigkeit sind beobachtete Realität. Der Übergang zwischen Ebenen verlangt einen nachprüfbaren Join, kein gemeinsames Etikett.

Eine Minimum Initial Specification sollte den schmalen Übergabevertrag standardisieren: Principal, Richtlinienhash, Capability-Verengung, getrennte Budgets und Kantenbelege. Running-Code Primacy verlangt anschließend unabhängige Implementierungen, aufgezeichnete Abläufe und reproduzierbare Ergebnisse, bevor Einsatzbehauptungen zulässig werden. Ein attestierter Knoten macht aus einem Diagramm noch keinen sicheren Regelkreis.

Im Eingangsfall war die Attestierung nicht nutzlos. Sie beantwortete nur eine andere Frage. Der Agent war der erwartete Agent in einer erwarteten Umgebung; er war nicht für die konkrete Netzänderung bevollmächtigt. Ein belastbares System erhält beide Aussagen, statt die erste in die zweite umzubenennen.

Sources