Governance als Eintrittsbedingung in die unternehmensweite KI
Microsoft traf auf der Build 2026 eine wenig beachtete Entscheidung, die mehr Aufmerksamkeit verdient, als sie erhalten hat: Statt ein leistungsfähigeres Modell oder einen fähigeren Agenten vorzustellen, überführte das Unternehmen das Agent 365 SDK in die allgemeine Verfügbarkeit und umgab es mit Identitäts-, Richtlinien- und Datenkontrollmechanismen, die bereits beim Design aktiviert werden – nicht erst dann, wenn der Agent in der Produktion bereits etwas beschädigt hat. Die implizite Wette lautet, dass die Modellleistung aufgehört hat, der Engpass für große Organisationen zu sein. Was Agentenprojekte aufhält, ist nicht die Stärke des Systems, sondern die Unfähigkeit nachzuweisen, dass jemand weiß, was dieser Agent tut, mit welchen Daten, unter welcher Genehmigung und in wessen Namen.
Das ist kein technisches Argument. Es ist ein Argument über die Machtarchitektur innerhalb von Organisationen.
Denn der Grund, warum Agentenprojekte in der rechtlichen Prüfung, in Risikoausschüssen oder auf dem Schreibtisch eines CISO zum Stillstand kommen, ist nicht, dass das Modell schlecht ist. Es ist, dass niemand drei grundlegende Fragen beantworten kann: Wer hat genehmigt, dass dieser Agent existiert, was darf er anfassen und wie lässt sich das gegenüber einem Audit nachweisen. Microsoft hat diesen Engpass identifiziert und entschieden, seine Plattform rund um ihn herum aufzubauen.
Was Microsoft verstanden hat, das seine Wettbewerber noch mit Geschwindigkeit zu lösen versuchen
Das Agent 365 SDK kommt mit einem zentralen Register, das Microsoft als die „einzige Quelle der Wahrheit" für das Inventar unternehmensweiter Agenten beschreibt. Dieses Register ist mit Defender, Purview, Entra und Foundry verbunden, was bedeutet, dass die Sicherheits-, Identitäts- und Compliance-Kontrollen, die ein großes Unternehmen bereits eingerichtet hat, nicht für Agenten repliziert werden müssen: Sie werden einfach ausgeweitet. Jeder Agent kann eine eindeutige Identität haben, die von jeder menschlichen Benutzeridentität getrennt ist. Administratoren können festlegen, welche Agenten auffindbar sind, welche unter Quarantäne gestellt werden, wer sie erstellt und unter welchen Bedingungen sie operieren.
Das Register erkennt auch Agenten, die bereits laufen, ohne dass jemand sie genehmigt hätte. Microsoft erklärt, dass das System mehr als 20 Typen lokaler Agenten erkennt, darunter Server des Model Context Protocol – genau die Art von Infrastruktur, die Ingenieurteams schnell einsetzen, ohne den Beschaffungsprozess zu durchlaufen. Den Begriff „Agent Sprawl" zu verwenden ist die elegante Umschreibung dafür, dass Organisationen bereits Agenten haben, die außerhalb jedes Kontrollrahmens operieren, und dass dies ein Governance-Problem ist, bevor es ein Sicherheitsproblem wird.
Im Vergleich zu Google Cloud, das seine Agentenplattform rund um einzigartige kryptografische Identitäten pro Agent aufgebaut hat, und zu AWS, das mit Bedrock AgentCore auf einen schnelleren und leichteren Weg gesetzt hat, wählte Microsoft das Terrain, auf dem es bereits gewinnt: die Kontrollinfrastruktur, die seine größten Unternehmenskunden bereits installiert haben und der sie bereits vertrauen. Das ist kein technischer Vorteil. Es ist ein über zwei Jahrzehnte akkumulierter Vorteil an sozialem Kapital bei den Sicherheitsteams von Unternehmen.
Das entstehende Muster ist kein Zufall. Die drei großen Cloud-Anbieter konvergieren auf dieselbe konzeptionelle Architektur: eine Kontrollebene für Agenten, die das repliziert, was Kubernetes für Container war. Der Unterschied besteht darin, dass Microsoft mit Entra, Intune, Defender und Purview bereits in den meisten großen Unternehmen verankert ist. Agenten-Governance kommt nicht als neue Plattform, die im Budget begründet werden muss. Sie kommt als Erweiterung dessen, was das Sicherheitsteam bereits heute betreibt.
Wer im Raum war, als dies entworfen wurde, und was das offenbart
Hier wird die Geschichte aus einer Perspektive des strukturellen Designs noch interessanter. Das Agent 365 SDK wurde gebaut, um das Problem des Unternehmenskäufers zu lösen, nicht das des Entwicklers, der schnell vorankommen möchte. Die Funktionalitäten, die Microsoft priorisiert hat – das Register, die Zugriffskontrolle, die Datenverlustprävention zur Laufzeit, die Windows-Kontrollen auf Betriebssystemebene – sind darauf ausgelegt, einen CISO, ein Rechtsteam oder einen Compliance-Beauftragten davon zu überzeugen, dass der Agent einsatzfähig ist. Das ist eine Designentscheidung, die offenbart, wer im Adoptionszyklus ein Vetorecht hat.
Das ist kein unbedeutendes Detail. Wenn eine Plattform so gestaltet wird, dass sie die Reibung für den Prüfer vor der Reibung für den Entwickler reduziert, wird explizit anerkannt, dass die Blockierungsmacht in großen Organisationen nicht beim technischen Team liegt. Sie liegt in den Kontrollfunktionen. Microsoft hat darauf gesetzt, dass es mehr Marktanteile gewinnen wird, indem es das Risikoteam überzeugt als das Ingenieurteam – und diese Wette hat Implikationen dafür, wie andere Unternehmen die Einführung ihrer eigenen Agentenwerkzeuge denken sollten.
Die strukturelle Frage, die sich daraus ergibt, ist, wer außen vor blieb in diesem Designraum. Das SDK erklärt Kompatibilität mit jeder Agentenplattform, nicht nur der von Microsoft, was ein Signal taktischer Offenheit ist. Aber die stärkste Kontrollarchitektur operiert innerhalb des Perimeters von Windows, Entra und Microsoft Foundry. Ein Unternehmen, das Agenten auf AWS, in Google Cloud und in einem Set vererbter SaaS-Tools betreibt, gewinnt Sichtbarkeit innerhalb der Microsoft-Grenze und erbt gleichzeitig eine tiefere Abhängigkeit von dieser Grenze. Multi-Cloud-Governance bleibt de facto ein von keinem der drei großen Anbieter gelöstes Problem. Unabhängige Anbieter wie Saviynt oder TrueFoundry existieren genau deshalb, weil diese Nachfrage real ist und von den Hyperscaler-Plattformen nicht befriedigt wird.
Es gibt noch etwas, das es verdient, präzise benannt zu werden: Microsoft hat das Agent Governance Toolkit als Open-Source-Projekt unter MIT-Lizenz im April 2026, vor der Build, veröffentlicht. Das Unternehmen positioniert es als das erste Toolkit, das auf die zehn agentischen KI-Risiken reagiert, die von OWASP identifiziert wurden, und zwar mit deterministischer Richtlinienanwendung in weniger als einer Millisekunde. Das ist ein Schachzug, um den Standard zu definieren, bevor jemand anderes es tut. Wenn ein dominanter Akteur das Sicherheitsreferenzrahmenwerk als Open Source veröffentlicht, ist er nicht großzügig. Er stellt seine konzeptionelle Architektur in den Mittelpunkt der Branchendiskussion.
Die Governance-Kosten, die keine Verkaufspräsentation erwähnt
Microsoft löst nicht alle Probleme, die es schafft. Es gibt drei Reibungspunkte, die jede Organisation, die diese Architektur übernimmt, benennen sollte, bevor sie sich festlegt.
Der erste ist, dass ein erheblicher Teil des auf der Build 2026 Angekündigten noch in der Vorschau ist, nicht in der allgemeinen Verfügbarkeit. Die Integration zwischen Defender und GitHub Code Security ist verfügbar. Windows 365 für Agenten ist verfügbar. Aber das MDASH-System für agentisches Scannen mit mehr als 100 spezialisierten Agenten, die Purview-Laufzeitsteuerungen und verschiedene Defender-Funktionen befinden sich noch in der Vorschau oder haben noch zu bestätigende Termine. Ein Governance-Plan, der auf Vorschaufunktionen aufgebaut ist, ist ein Plan mit einer Leerstelle.
Der zweite Reibungspunkt ist operativer Natur. Jede Kontrollschicht, die die Organisation schützt, verlangsamt auch den Entwickler. Teams, die die Kontrollen übermäßig verschärfen, werden sehen, wie ihre Ingenieure nach alternativen Wegen suchen und Agenten außerhalb des Registers einsetzen, weil der Genehmigungsprozess drei Wochen dauert. Governance, die übermäßige Reibung erzeugt, produziert genau den Sprawl nicht verwalteter Agenten, den das Register erkennen sollte. Das ist ein Problem des organisatorischen Designs, nicht der Technologie.
Der dritte Reibungspunkt ist strategischer Natur. Organisationen, die Agent 365 als ihre Kontrollschicht übernehmen, gewinnen reale Sichtbarkeit innerhalb des Microsoft-Perimeters. Was sie gleichzeitig erben, ist eine tiefere Abhängigkeit von diesem Perimeter. Das ist kein Argument gegen die Plattform. Es ist eine Variable, die in jeder ehrlichen Architekturentscheidung auftauchen sollte. Die Portabilität von Governance durch Standards wie das Model Context Protocol, das alle drei großen Anbieter zu unterstützen behaupten, ist in der Praxis möglicherweise nicht so verfügbar wie in Pressemitteilungen.
Nicht-menschliche Identität als neue Grenze der unternehmerischen Kontrolle
Was Microsoft aufbaut, wenn man es ohne Produktterminologie beschreibt, ist ein Identitäts- und Autorisierungssystem für Entitäten, die keine Menschen sind, aber so handeln können, als wären sie es: sensible Daten lesen, Werkzeuge aufrufen, Prozesse auslösen, Entscheidungen im Namen der Organisation treffen. Dieses Problem existierte vor zwei Jahren in diesem Ausmaß noch nicht.
Die Budgetimplikation ist direkt. Die Ausgaben, die für den Zugang zu Modellen und für Experimente verwendet wurden, brauchen nun eine Haushaltslinie für die Identitäts- und Governance-Schicht, die Experimente in genehmigte Deployments verwandelt. Diese Ausgaben sind nicht diskretionär, sobald Agenten eigenständig Daten lesen und Aktionen auslösen können. Nicht-menschliche Identität wird zu einem erstrangigen Problem, mit derselben Dringlichkeit, mit der Organisationen menschliche Identität behandeln, seitdem der Unternehmensperimeter aufgehört hat, eine physische Wand zu sein.
Der Schachzug von Microsoft beantwortet nicht die Frage, wie gut Governance funktioniert, wenn die Organisation in mehreren Clouds mit Dutzenden von SaaS-Tools und Agenten operiert, die auf Plattformen von Drittanbietern aufgebaut sind. Aber er offenbart die Machtmechanik, die bestimmen wird, welche Organisationen Agenten skalieren können und welche weiterhin im Zyklus von Pilotprojekten gefangen bleiben, die in der rechtlichen Prüfung sterben. Die Fähigkeit nachzuweisen, was jeder Agent getan hat, mit welchen Daten und unter welcher Genehmigung – bevor ein Regulierer oder ein Vorstand danach fragt –, ist das Kriterium, das diejenigen, die deployen, von denen trennen wird, die auf unbestimmte Zeit experimentieren.
Die Architektur, die Microsoft auf der Build 2026 vorgestellt hat, ist nicht die einzige Möglichkeit, dieses Problem zu lösen. Aber sie ist die erste, die verpackt mit der Kontrollinfrastruktur kommt, die die größten Organisationen bereits installiert haben. Dieser Distributionsvorteil ist nicht technischer Natur. Er ist struktureller Natur – und er ist viel schwieriger zu replizieren als ein Sicherheits-Benchmark.
