Microsoft veröffentlichte am 4. September 2026 Leitlinien zur Absicherung künstlicher Intelligenz am Netzwerkrand (Edge AI) und warnte davor, dass die Verlagerung der Modellausführung auf Geräte, Gateways oder lokale Umgebungen im Besitz der Kunden nicht nur den Ort der Datenverarbeitung verändert, sondern auch die Verantwortung für Vertrauen und Sicherheit neu verteilt. In diesem Modell können sich Modellgewichte, Kundendaten, Zugangsdaten und die Möglichkeit, reale Systeme zu beeinflussen, innerhalb einer Infrastruktur befinden, die der Modellanbieter nicht direkt kontrolliert.
Microsoft definiert Edge AI als die Ausführung der Inferenz auf dem Gerät oder in dessen Nähe, wo Daten erzeugt und zur Entscheidungsfindung verwendet werden, anstatt vollständig auf einen zentralen Cloud-Dienst angewiesen zu sein. Organisationen können diesen Ansatz aus Gründen der Kosten, der Modellwahl, der Datenhoheit, der Verringerung der Latenz oder der Fähigkeit wählen, bei einem Verbindungsabbruch weiterzuarbeiten.
Was ändert sich am Vertrauensmodell?
Bei cloudbasierten KI-Diensten sind der Besitz der Hardware und der Plattform, die Modellgewichte sowie der Nachweis ihres Zustands häufig auf Anbieter verteilt, die einheitliche Nachweise über die Umgebung bereitstellen können. Bei Edge AI verwaltet der Kunde einen größeren Teil des Stacks und muss daher Hardware, Firmware, Laufzeitumgebung, Modell und integrierte Komponenten überprüfen, bevor er ihnen Zugriff auf sensible Ressourcen gewährt.
Die Risiken steigen, weil die Umgebung selbst das Modell, Daten, Schlüssel und Zugriffsmöglichkeiten auf physische Systeme enthalten kann. Zu den möglichen Angriffspunkten gehören Prompt Injection, Modellmanipulation, Änderungen an der Firmware, die Vergiftung von Retrieval-Daten, die Konfiguration von Tools und die Modell-Lieferkette. Bei vom Netzwerk getrennten Edge-Prozessen kann man sich nicht immer auf eine direkte Erkennung in der Cloud, sofortige Richtlinienaktualisierungen oder eine zentrale Aufhebung von Berechtigungen verlassen.
Vier Säulen der Überprüfung vor der Freigabe
- Nachweis der Betriebsumgebung: Es muss sichergestellt werden, dass die Ausführungsumgebung messbar ist, ihren Zustand melden kann und einem genehmigten Baseline-Status entspricht.
- Nachweis der Herkunft der Komponenten: Modellgewichte, Tooldefinitionen, Agentendefinitionen, Retrieval-Indizes sowie deren Erstellungs- und Bereitstellungspfad sollten überprüft werden.
- Deterministische Vermittlung von Aktionen: Das Modell soll eine Aktion empfehlen, ihr aber nicht direkt die Berechtigung erteilen. Eine vom Modell getrennte Schicht setzt eine Allowlist durch, beschränkt Parameter, steuert die Häufigkeit und gibt Zugangsdaten gemäß einer festgelegten Richtlinie frei.
- Bindung sensibler Ressourcen an die vertrauenswürdige Umgebung: Schlüssel, Daten oder Modellgewichte werden erst herausgegeben, nachdem die erforderlichen Nachweise gesammelt und eine Überprüfungsrichtlinie erfüllt wurde.
Der Nachweis allein reicht nicht aus
Microsoft erklärt, dass der Nachweis der Betriebsumgebung und der Nachweis der Herkunft der Komponenten zwei unterschiedliche Fragen beantworten. Eine akzeptable Laufzeitumgebung kann eine kompromittierte Komponente laden, während eine vertrauenswürdige Komponente auf einer kompromittierten Plattform ausgeführt werden kann. Daher müssen beide Nachweise kombiniert werden, wobei die Nachweiskette vom Erstellungs- und Verteilungsprozess bis zur vom Prüfer akzeptierten Hardware verfolgt werden muss.
Vertrauliches Computing kann dieses Modell unterstützen, wenn es den vollständigen Pfad gemäß dem für die Plattform offengelegten Bedrohungsmodell abdeckt. Ein Host mit weitreichenden Berechtigungen oder ein ungeschützter Beschleunigerpfad kann möglicherweise Gewichte, Schlüssel oder Daten lesen, nachdem sie entschlüsselt wurden. Der Schutz vor dem Zugriff des Hosts hindert das Modell jedoch nicht daran, über eine autorisierte Schnittstelle eine schädliche Aktion auszuführen; deshalb bleiben unabhängige Vermittlung und Richtlinien erforderlich.
Auch die Freigabe von Ressourcen sollte nicht als dauerhafte Entscheidung betrachtet werden. Die Leitlinien schlagen vor, sie als erneuerbare, befristete Überlassung zu behandeln, die endet, sobald aktuelle Nachweise nicht mehr mit dem genehmigten Zustand übereinstimmen. Diese Nachweise können zur Steuerung der Arbeitslastplanung, des Speichers, der Identität und der Verfügbarkeit von Zugangsdaten verwendet werden.
Warum reichen herkömmliche Software-Sicherheitskontrollen nicht aus?
Herkömmliche Software arbeitet mit Code, den der Entwickler ausliefert, während das Verhalten von KI-Systemen durch Prompts, Retrieval-Daten, Agentenanweisungen und Laufzeiteingaben beeinflusst wird. Daher reichen das Signieren ausführbarer Dateien oder die Prüfung der Codeintegrität nicht aus, um das System zu schützen. Eine Signatur kann zwar die Herkunft der Daten belegen, nicht aber, dass ihr Inhalt sicher ist, damit ein KI-Modell ihn interpretieren kann.
Microsoft betont, dass Prompt Injection angenommen werden muss, unabhängig davon, ob sie direkt oder indirekt erfolgt, und dass Agentenausgaben sowie Bildschirmeingaben an sich keine Autorisierung darstellen. Da das Verhalten nicht deterministisch ist, ist die alleinige Abhängigkeit von signaturbasierten Erkennungen oder herkömmlichen Tests begrenzt. Deshalb müssen an den Autoritätsgrenzen deterministische Schranken eingerichtet werden, verbunden mit einer unabhängigen Genehmigung, einem Trennmechanismus oder einem sicheren Verhalten bei Aktionen mit hohen Folgen oder irreversiblen Auswirkungen.
Was bedeutet das für Organisationen?
In der Praxis muss die Organisation eine Karte der sensiblen Ressourcen, der Betriebsumgebungen und der Komponenten erstellen, die auf sie zugreifen, sowie die für jede Freigabeentscheidung verantwortliche Stelle festlegen. Außerdem sollten die an jeder Vertrauensgrenze erforderlichen Nachweise definiert werden. Lokale Änderungen sollten als Abweichung in den Messwerten sichtbar bleiben, anstatt stillschweigend als neue Baseline übernommen zu werden.
Die redaktionelle Einschätzung von certi.news: Der zentrale Wert dieser Leitlinien liegt darin, dass sie die Sicherheit von Edge AI vom Schutz des Modells als Datei auf die Verwaltung der gesamten Vertrauenskette verlagern – von der Hardware bis zu den Aktionen, die das System ausführen kann. Sie bieten jedoch keine Garantie dafür, dass jede von der Vermittlung erlaubte Aktion sicher ist, und machen weder physische Kontrollen noch eine unabhängige Überprüfung risikoreicher Vorgänge überflüssig. Daher bleibt für jede lokale Bereitstellung die offene Frage: Welcher Nachweis belegt, dass die aktuelle Umgebung, die Komponenten und die Richtlinie die Freigabe der sensiblen Ressource jetzt rechtfertigen?