Microsoft stuft KI-Agenten als Insider ein, die externe, adaptive Sicherheitskontrollen erfordern

Microsoft hat ein Sicherheitsframework vorgestellt, das KI-Agenten als eine Form von Insider-Risiko behandelt. Das Unternehmen argumentiert, dass Organisationen ihre Identitäten, Berechtigungen und das Laufzeitverhalten unabhängig von den Modellen selbst kontrollieren müssen.

Der Microsoft-Sicherheitsleitfaden vom 19. Oktober 2026 ist keine Meldung über einen Vorfall oder eine Schwachstelle. Er befasst sich mit dem operativen Risiko, das entsteht, wenn Agenten Zugang zu Unternehmensdaten, Werkzeugen und Infrastruktur erhalten und danach mit Maschinengeschwindigkeit handeln können.

Microsoft bezeichnet Agenten nicht grundsätzlich als feindselig. Die Sorge gilt vielmehr dem Umstand, dass Modellausgaben variieren können, sich der Kontext einer Aufgabe verschieben kann und externe Inhalte einen sonst legitimen Agenten manipulieren können. Ein System, das eine Aufgabe korrekt beginnt, kann daher später aufgrund eines Fehlers, einer Kompromittierung oder einer Prompt-Injection abweichen.

Das Unternehmen nennt dies einen „agentischen Insider“: Software, die mit delegierter Organisationsbefugnis handelt, deren Verhalten jedoch nicht vollständig deterministisch ist.

Kontrollen müssen außerhalb des Modells bleiben

Microsofts zentraler Grundsatz lautet, „nicht-deterministische Intelligenz mit deterministischen Kontrollen, unabhängigen Nachweisen und Eindämmungsgrenzen zu umgeben“.

Nach diesem Modell soll ein Agent nicht selbst über die Grenzen seiner Befugnisse entscheiden. Identitäts-, Zugriffs- und Durchsetzungsmechanismen müssen außerhalb des Modells arbeiten, jenseits seiner Möglichkeit, sie zu umgehen oder zu verändern.

Microsoft-Vorstandsvorsitzender und CEO Satya Nadella fasste den Ansatz so zusammen, dass die vertrauenswürdigste agentische Architektur darauf ausgelegt sei, „dem Modell so wenig wie möglich zu vertrauen“. Der praktische Unterschied liegt darin, ob man einem Modell vertraut, sich korrekt zu verhalten, oder ob man ein System baut, das den Schaden begrenzt, wenn es das nicht tut.

Microsoft gliedert das Framework in vier fortlaufende Aufgaben:

1. Erfassen: Ein Inventar der Agenten führen, mit ihren Verantwortlichen, vorgesehenem Zweck und beobachteter Aktivität.
2. Eindämmen: Daten, Systeme und Aktionen einschränken, bevor ein Agent seinen Betrieb aufnimmt.
3. Schützen: Jede Komponente auf dem Weg des Agenten absichern, einschließlich Werkzeuge, Laufzeitumgebungen und Unternehmensressourcen.
4. Anpassen: Schutzmaßnahmen überarbeiten, wenn sich Verhalten, Kontext oder bewertetes Risiko ändern.

Diese Aufgaben werden nicht als aufeinanderfolgende Umsetzungsphasen dargestellt. Microsoft beschreibt eine Rückkopplungsschleife, in der neue Erkenntnisse das Risiko verändern, das Risiko die Richtlinie verändert und die Richtlinie bestimmt, was ein Agent tun darf.

Steigt das Risiko, kann das Framework den Lesezugriff beibehalten und Schreibzugriffe blockieren, die dem Agenten zur Verfügung stehenden Ressourcen reduzieren, für folgenreiche Aktionen eine verifizierte menschliche Freigabe verlangen oder den Agenten isolieren und stoppen.

Jeder Agent erhält eine eigene Identität

Eine unmittelbare Konsequenz für Sicherheitsteams ist, dass ein Agent nicht einfach als Erweiterung eines Mitarbeiterkontos arbeiten sollte.

Microsoft erklärt, jeder Agent brauche eine eigene, vollwertige Identität, die von der Person getrennt ist, die ihn verantwortet. Dadurch können Audit- und Zugriffssysteme die direkten Handlungen eines Mitarbeiters von Vorgängen unterscheiden, die ein Agent im Auftrag dieses Mitarbeiters ausführt.

Das Unternehmen erweitert die Erkennung um 35 zusätzliche Typen lokaler Agenten, sodass insgesamt 60 unterstützt werden. Beispiele sind Claude Code, OpenAI Codex und GitHub Copilot. Die Erkennung soll von Microsoft entwickelte Agenten, Partnerplattformen und SDKs sowie lokal eingeführte Agenten abdecken.

Microsoft erweitert außerdem Microsoft Entra Agent ID um Identitätstypen für weitere Agentenmuster, darunter lokale Agenten und bislang unbekannte Agenten, die von Sicherheitssensoren erkannt werden. Laut dem Unternehmen tauschen Project Perception und Microsoft Agent 365 Signale aus und nutzen ein einheitliches Register.

Für Administratoren macht das vorgeschlagene Modell die Erkennung von Agenten zu einer Frage des Asset-Managements: Eine Organisation kann keine sinnvollen Zugriffskontrollen anwenden, wenn sie nicht feststellen kann, welche Agenten existieren, wer für sie verantwortlich ist und was sie tun.

Sandboxing und vermittelter Werkzeugzugriff

Microsoft empfiehlt, Modelle und die sie umgebenden Harnesses in kontrollierten Umgebungen auszuführen, statt ihnen alle Berechtigungen eines Geräts zu überlassen.

Als Beispiel für eine Sandbox, die richtlinienbasierten Zugriff auf Ressourcen durchsetzen soll, nennt das Unternehmen Microsoft Execution Container (MXC). Die Durchsetzungsgrenze soll außerhalb des Agenten liegen und nicht von Anweisungen im Modell abhängen.

Das Framework lehnt außerdem eine uneingeschränkte Werkzeugerkennung ab. Ein Agent sollte nicht automatisch jede API, jeden MCP-Server, jede Netzwerkressource, jedes lokale Werkzeug oder jeden anderen Agenten aufrufen können, auf den er stößt. Diese Verbindungen sollten durch lokale, netzwerkbezogene und datenbezogene Kontrollen vermittelt werden.

Auch die Inhaltsprüfung gehört zum Design. Sicherheitssysteme sollten die Sensibilität und Herkunft von Informationen bewerten, die in einen Agenten hineinfließen oder ihn verlassen, einschließlich der Frage, ob nicht vertrauenswürdiges Material seine Entscheidungen beeinflussen könnte.

Microsoft veranschaulicht das Risiko an einem Agenten für Spesengenehmigungen. Ein solcher Agent muss möglicherweise Abrechnungen lesen, sie mit den Richtlinien vergleichen und Routineerstattungen freigeben. Er benötigt jedoch nicht alle Berechtigungen, die sein Auftraggeber besitzt. Enthält ein externes Dokument eine Prompt-Injection, kann die Konfiguration des Agenten unverändert bleiben, obwohl sich sein Verhalten – und damit sein Risiko – verschoben hat.

Berechtigungen, die mit der Aufgabe enden

Microsoft stellt Dynamic Permissions als Möglichkeit dar, einem Agenten standardmäßig keinen dauerhaften Zugriff zu gewähren. Der Agent würde nur die Befugnis erhalten, die für eine genehmigte Aufgabe erforderlich ist, und zwar nur für deren Dauer.

Eine unternehmensweite Richtlinie würde die maximale Grenze festlegen. Insbesondere könnte ein Agent keine Befugnisse erlangen, die dem auftraggebenden Benutzer nicht zur Verfügung stehen. Berechtigungen könnten auf eine Aufgabe beschränkt sein, nach einem festgelegten Zeitraum ablaufen oder im Verlauf der Aufgabe reduziert werden. Wirkungsstärkere Operationen könnten eine verifizierte menschliche Freigabe erfordern.

Der Mitarbeiter behielte seinen eigenen Zugang, während der Agent eine separate Identität und seine eigenen aufgabenspezifischen Berechtigungen hätte. Diese Trennung soll Zuordnung und Entzug präziser machen, als wenn ein Agent die Zugangsdaten und Privilegien einer Person weiterverwenden würde.

Microsoft beschreibt außerdem Dynamic Agent Risk als laufend aktualisierten Wert, der aus Signalen zu Identität, Endgerät, Daten, Cloud, Netzwerk, Laufzeit und Agentenaktivität gebildet wird. Die Bewertung berücksichtigt die Sicherheitskonfiguration des Agenten, die Ressourcen, die er erreichen kann, die wahrscheinlichen Auswirkungen eines Fehlers sowie Anzeichen dafür, dass seine Handlungen von der Absicht des Benutzers oder der Organisation abweichen.

Ein Diagramm zur Ankündigung zeigt, dass Microsoft Sentinel, Entra, Intune, Purview, Global Secure Access und Defender Signale für die Kontextanalyse und die Risikobewertung in Echtzeit liefern. Microsoft verknüpft diese Bewertung mit Dynamic Conditional Access, wonach eine Richtlinie in einem bestimmten Moment verändern kann, was ein Agent lesen, ändern, aufrufen oder freigeben darf.

Dabei handelt es sich um Microsofts Beschreibungen seiner Fähigkeiten und der vorgesehenen Architektur, nicht um Belege aus einem unabhängig demonstrierten Einsatz.

Auch die Agenten werden automatisiert überwacht

Microsoft argumentiert, dass manuelle Prüfung nicht skalieren wird, wenn Organisationen „Tausende oder Hunderttausende“ Agenten einsetzen. Als Antwort nennt das Unternehmen unter anderem Guardian Agents – KI-Systeme, die dabei helfen, andere Agenten zu beaufsichtigen, und dabei weiterhin an vom Menschen definierte Grenzen gebunden sind.

Ein am 20. Oktober 2026 veröffentlichter Bericht von Security Affairs erklärt, Guardian Agents könnten von Betreibern erstellten Playbooks folgen, Risikoänderungen untersuchen, Reaktionen empfehlen oder umsetzen und die Ergebnisse nutzen, um Richtlinien zu verfeinern. Menschen würden weiterhin die Ziele festlegen und bedeutende Entscheidungen freigeben.

Dieser Ansatz führt zu einer zentralen Herausforderung im Design: Die Durchsetzung darf nicht allein von einem anderen Modell abhängen, dessen Verhalten ebenfalls variieren kann. Microsofts erklärte Antwort lautet, die maßgeblichen Kontrollen außerhalb der Modelle zu halten, wo Agenten sie nicht verändern können.

Für Organisationen, die Agenten jetzt einführen, übersetzt sich das Framework in konkrete Prioritäten: lokal und zentral bereitgestellte Agenten erkennen, jedem eine eigene Identität zuweisen, übernommene Benutzerprivilegien entfernen, Laufzeit und Werkzeugpfade eingrenzen, nicht vertrauenswürdige Eingaben prüfen und menschliche Freigabe oder Isolation verlangen, wenn sich das Risiko so verändert, dass eine Aktion unsicher wird.