What's new in Microsoft Security: August 2026
Agenten-Sichtbarkeit, Runtime-Schutz und aktuelle Neuerungen aus Redmond – für Security- und Compliance-Verantwortliche.|
SECURITY & COMPLIANCE |
|---|
What's new in Microsoft Security: August 2026
Agenten-Sichtbarkeit, Runtime-Schutz und ein Marktanteil, den du deinem Vorstand zeigen darfst.
Executive Summary
Der August-Rundumschlag aus Redmond hat einen roten Faden, und der heißt nicht Copilot, sondern Kontrolle. Microsoft behandelt AI-Agents ab sofort wie das, was sie längst sind: Assets mit Identität, Rechten, Werkzeugen und einem Blast Radius. Defender entdeckt sie, bewertet ihr Risiko, erkennt Angriffe zur Laufzeit und kann Tool-Aufrufe blocken, bevor sie passieren. Das ist der eigentliche Nachrichtenwert des Monats – alles andere ist Beiwerk.
Beiwerk, das du trotzdem brauchst: Defender Experts MDR deckt jetzt Drittquellen ab, die über Microsoft Sentinel hereinkommen, darunter Palo Alto Networks, AWS und Okta. Entra Tenant Governance ist allgemein verfügbar und räumt im Schatten-Tenant-Zoo auf. Intune bekommt Autopilot Device Association und unbeaufsichtigtes Remote-Sign-in. Purview labelt automatisch statt 100.000 nun bis zu 500.000 SharePoint- und OneDrive-Dateien pro Tag. Und Exposure Management liefert unter „Secure Now“ eine Handlungsanleitung für agentic containment.
Für die Entscheiderebene: Frost & Sullivan hat Microsoft im Frost Radar für Cloud Workload Protection Platforms 2026 als visionary leader eingestuft, bei über 22 Prozent Marktanteil. Schön für die Folie im Lenkungsausschuss. Wichtiger ist die Begründung: Der Markt konsolidiert sich auf ein einziges Runtime-Sicherheitsmodell, das Code, Cloud, Laufzeit, Identität und SOC zusammenzieht. Deshalb gehören die Agenten-Themen und die Cloud-Themen hier zusammen.
|
DIE UNBEQUEME ZEILE IM KLEINGEDRUCKTEN Fast alles rund um Agenten-Sicherheit ist Public Preview, läuft nur in der Commercial Cloud – keine Sovereign oder National Clouds – und die wirklich nützlichen Teile hängen an Microsoft 365 E7 oder Microsoft Agent 365. Wer mit E5 plant, sieht seine Agenten. Er erfährt nur nicht, welche davon gefährlich sind. |
|---|
Worum geht es im Detail?
Kurz zurücktreten, damit klar wird, warum das mehr ist als ein weiterer Blogeintrag. Ein AI-Agent ist aus Sicherheitssicht ein höchst unangenehmes Geschöpf: Er hat eine Identität wie ein Dienstkonto, handelt initiativ wie ein Mensch, ist so vertrauensselig wie ein Praktikant am ersten Tag – und niemand hat ihn je in ein CMDB-Feld eingetragen. Die klassische Sicherheitsarchitektur kennt Geräte, Benutzer, Anwendungen und Daten. Ein Agent ist von allem etwas und passt in keine der Schubladen. Microsoft schneidet deshalb eine neue auf.

Von der Entdeckung bis zur Untersuchung: die vier Stufen der Agenten-Sicherheit und die Datenquellen dahinter.
Der Agent wird zum Inventargegenstand
Der Einstieg ist erfreulich unspektakulär: Defender for Endpoint entdeckt lokale AI-Agents und deren MCP-Server auf Windows- und macOS-Geräten automatisch. Keine Skripte, kein zusätzliches Rollout. Gerät onboarden, Defender Antivirus im aktiven Modus mit Echtzeitschutz, aktuelle Plattform- und Engine-Updates – fertig. Erkannt werden mehr als 35 bekannte Agententypen; im Portal findest du sie unter Assets, AI agents, Reiter Local agents.
Spannend sind weniger die Namen als die Metadaten. Pro Agent-Installation siehst du den Hersteller, den Hostprozess – häufig code.exe –, ob dieser Prozess vertrauenswürdig ist, welche MCP-Server konfiguriert sind und, das ist die wichtigste Spalte im ganzen Portal, ob der Agent seine eigenen Aktionen automatisch genehmigt. Das Feld heißt autoApprove. Steht dort „true“, dann ruft dieser Agent Werkzeuge auf und greift auf Ressourcen zu, ohne dass ein Mensch einzelne Schritte bestätigt. Was er darf, definieren dann nur noch das Konto und das Gerät, unter dem er läuft.
|
AUS DEM PROJEKTALLTAG Ein Kunde mit rund 4.000 verwalteten Geräten war sich vollkommen sicher: „AI-Agents setzen wir nicht ein, das ist noch nicht freigegeben.“ Nach zwei Tagen Discovery standen dreistellig viele lokale Agent-Installationen im Inventar, der Löwenanteil in der Entwicklung, ein beträchtlicher Teil mit autoApprove auf „true“ und lokalen MCP-Servern, die per Kommandozeile gestartet wurden. Freigegeben war davon exakt nichts. Die Diskussion danach war kurz und sehr produktiv – Inventarlisten gewinnen gegen Meinungen. |
|---|
Von der Entdeckung zur Bewertung
Sichtbarkeit allein hilft niemandem. Defender bewertet deshalb jeden Agent gegen sogenannte Risikoindikatoren und leitet daraus eine Gesamtrisikostufe ab. Ein Risikoindikator ist schlicht ein Sicherheitszustand: Der Agent ist veröffentlicht, er darf ohne menschliche Freigabe laufen, er hat privilegierten Zugriff, es gibt aktive Alerts zu ihm. Die Indikatoren speisen sich aus Konfiguration, Werkzeugen, Zugriffen, Laufzeitverhalten, dem Geräte- und Benutzerkontext lokaler Agents sowie aus aktiven Sicherheitswarnungen.
Konkret heißen die Dinger dann Weak Instructions – die Anweisungen des Agenten sind zu schwammig für vorhersagbares Verhalten –, High-usage Agent, Indirect Prompt Injection Exposure, Privileged Business-system Access oder Active Threat. Bei lokalen Agents kommen Kontextindikatoren dazu: Used by a critical user, Running on a critical device, Running on a device with vulnerabilities, Privileged Software Development Access. Die Gesamtstufe ergibt sich aus Schwere und Kombination der aktiven Indikatoren und lautet Hoch, Mittel, Niedrig, kein bekanntes Risiko oder nicht bewertet.
Zwei Feinheiten sorgen in der Praxis regelmäßig für Diskussionen. Erstens ist nicht jeder Indikator behebbar: Ein Chatbot, der bewusst ohne Anmeldung erreichbar ist, ist kein Konfigurationsfehler, sondern das Produkt. Der Indikator liefert Kontext, kein Ticket. Zweitens werden Empfehlungen und Risikostufe getrennt ermittelt – ein Agent mit hohem Risiko kann null Empfehlungen haben. Kein Bug, sondern Design: Die Stufe beschreibt die Exposition, die Empfehlung beschreibt, was du dagegen tun kannst.
Darüber liegt der Exposure Graph. Er beantwortet die Frage, die im Ernstfall wirklich zählt: Was kann dieses Ding eigentlich erreichen? Agent-Knoten hängen über die Kanten runs on am Gerät, über uses am MCP-Server und über used by an der Identität. Cloud-Agents haben zusätzlich eine Kante can authenticate as zum Service Principal. Kritikalität wird im Knoten mitgeführt, wobei die Stufe 0 die höchste ist. Damit kannst du gezielt die Agenten herausziehen, die unbeaufsichtigt handeln und auf geschäftskritischen Geräten laufen.
|
ZWEI KQL-FALLEN, DIE DIR ZWEI STUNDEN KOSTEN Erstens: In der Tabelle AgentsInfo ist AgentId eine GUID-Spalte, im Exposure Graph steht derselbe Wert als String. Ein Join ohne tostring() auf beiden Seiten liefert nicht etwa einen Fehler, sondern null Zeilen. Zweitens: ExposureGraphEdges hat kein Merkmal, an dem du lokale Agenten erkennst. Wer nur auf SourceNodeLabel filtert, bekommt sämtliche Agenten des Tenants zurück, Cloud inklusive. Erst die Knoten auflösen, dann über die Node-ID joinen. |
|---|
Runtime-Schutz: Audit ist der Anfang, Block ist die Entscheidung
Jetzt wird es operativ. Defender prüft Agentenaktivität im laufenden agentischen Loop und kann riskante Aktionen stoppen, bevor sie ausgeführt werden. Die Abdeckung hängt am Agententyp, und das ist die wichtigste Architekturinformation des Monats. Bei Agent-365-Agenten bewertet Defender Tool-Aufrufe über die Integration mit Work IQ MCP, inklusive eigener MCP-Tools, die du in Agent 365 onboardest. Bei Copilot Studio werden Tool-Aufrufe geprüft, dort ohne Work IQ MCP. Bei Foundry-Agenten geht Defender am weitesten und bewertet Benutzeranfragen, Agentenantworten, Tool-Aufrufe und Tool-Antworten. Lokale Agenten laufen über den Endpoint-Runtime-Schutz.
Und jetzt der Satz, den du dir markieren solltest: Agenten, die auf nicht unterstützte Werkzeuge setzen oder gar nicht mit Work IQ MCP integriert sind, sind schlicht nicht abgedeckt. Das ist keine Fußnote, das ist die Bauart. Wer seine Agenten am Governance-Pfad vorbeibaut, bekommt keinen Schutz – er bekommt nur eine Zeile im Inventar.
Erkannt werden dabei Jailbreak-Versuche, indirekte Prompt Injection, das Weitertragen bösartiger Inhalte, das Abfließen von Secrets und Zugangsdaten, Verschleierungstechniken, LLM-Reconnaissance sowie auffällige Benutzer- oder IP-Zugriffe. Die Steuerung läuft über Regeln. Eine Default-Regel auditiert alle Agenten und schreibt jede Trefferaktivität als Behavior mit, ohne irgendetwas zu verhindern. Eigene Regeln blocken – wahlweise für alle oder für ausgewählte Agenten, mit Ausnahmeliste, wobei nur Agenten mit Entra Agent ID überhaupt zur Auswahl stehen. Die wählbaren Detection Types sind derzeit Secret exfiltration, Malicious content propagation, Evasion techniques und Unsafe email domain.

Der agentische Loop mit Defender dazwischen – und der Nebenwirkung, die beim Scharfschalten gern übersehen wird.
|
DIE STILLE NACH DEM SCHARFSCHALTEN Sobald eine Block-Regel einen Agenten abdeckt, erzeugt Defender für diesen Agenten keine Near-real-time-Alerts mehr. Die Ereignisse landen weiterhin als Behaviors in BehaviorInfo – nur eben nicht mehr auf dem Alert-Dashboard, auf das dein SOC schaut. Wenn nach dem Rollout die Zahlen einbrechen, ist das kein Erfolg, sondern eine verschobene Datenquelle. Baue deine Custom Detections und dein Reporting vorher auf Behaviors um, nicht nachher. |
|---|
Advanced Hunting: sechs Tabellen, ein Blast Radius
Für die Untersuchung stehen sechs Tabellen bereit, und sie ergänzen sich sauber. AlertInfo und AlertEvidence liefern die Warnungen samt beteiligter Entitäten, CloudAppEvents die Agent-365-Observability-Daten mit Aktionen, Tool-Aufrufen und Datenzugriffen, AgentsInfo den Bestand und seine Konfiguration. BehaviorInfo und BehaviorEntities halten die Audit- und Block-Ereignisse des Echtzeitschutzes als abfragbare Telemetrie vor – die Grundlage für eigene Erkennungen und Automatisierungen. Damit überhaupt Daten fließen, brauchst du den Microsoft-365-App-Connector und Agenten, die Observability senden. Copilot Studio, Foundry und der Agent Builder tun das von Haus aus; alles andere muss über das Agent-365-SDK instrumentiert werden. Wer das überspringt, bekommt ein Portal voller leerer Detailseiten.
Der Rest des Monats, kurz und schmerzlos
Defender Experts MDR deckt über Plan 2 nun auch Drittquellen ab, die über Sentinel ins Haus kommen – Palo Alto Networks, AWS, Okta und weitere. Relevant für alle, deren Realität nicht ausschließlich Microsoft ist, und das sind so ziemlich alle. Entra Tenant Governance ist allgemein verfügbar, bringt sämtliche Tenants einer Organisation in eine Sicht, erlaubt zentrale Richtlinien sowie tenantübergreifende delegierte Administration und überwacht Konfigurationsdrift. Wer schon einmal einen Tenant gefunden hat, den ein Fachbereich „nur mal kurz zum Testen“ angelegt hat, weiß, warum es das Feature gibt.
In Intune verknüpft Windows Autopilot Device Association Geräte mit dem Tenant und erlaubt es, die Erfahrung vor der Registrierung zu konfigurieren, inklusive Umbenennung. Unattended Support mit Remote Sign-in lässt IT-Mitarbeiter sich ohne Beteiligung des Benutzers am Gerät anmelden – mit rollenbasierten Berechtigungen, Compliance-Prüfungen und Sitzungsprotokollierung. Purview hebt die automatische Klassifizierung von 100.000 auf bis zu 500.000 SharePoint- und OneDrive-Dateien pro Tag, die Voraussetzung dafür, dass Copilot nicht munter ungelabelte Altlasten zusammenfasst. Und Exposure Management liefert unter Secure Now eine Anleitung für agentic containment.
Und der Frost Radar? Der ist überraschend brauchbar
Analystenlob ist normalerweise Fassadenschmuck. Hier lohnt der Blick in die Begründung. Frost & Sullivan hat aus über 45 qualifizierten Anbietern 20 bewertet und Microsoft als visionary leader eingestuft, mit einem geschätzten Anteil von mehr als 22 Prozent am globalen CWPP-Markt und damit als größter Anbieter nach Umsatz. Der Markt selbst wächst von rund 6,43 Milliarden US-Dollar 2025 auf etwa 7,95 Milliarden 2026 und danach mit rund 19 Prozent jährlich bis 2030.
Gelobt wurde die Breite über Infrastruktur, Workloads, Identitäten, Berechtigungen, Daten und Anwendungen in einem Rahmen. Technisch dahinter stecken eBPF-basierte Sensoren für Kubernetes-Ereignisse, Prozessaktivität und Netzwerkverkehr, DNS-Erkennung für AKS, EKS und GKE, Anti-Malware-Blocking, Runtime-Schutz für EKS Bottlerocket und Drift-Blocking, wenn sich Binärdateien während der Ausführung ändern. Dazu Model Scanning für Azure AI Foundry, Azure OpenAI, Google Vertex AI und Amazon Bedrock sowie die Rückkopplung von Laufzeitfunden nach GitHub Advanced Security und Copilot Autofix. Übersetzt: Der Befund aus der Produktion landet beim Entwickler, nicht in einem PDF.
Was sind Chancen? Was sind Risiken?
Die große Chance ist banal und trotzdem entscheidend: Du bekommst zum ersten Mal eine belastbare Antwort auf die Frage, wie viele AI-Agents in deinem Unternehmen laufen und was sie erreichen können. Bisher war das eine Schätzung mit Tendenz zum Wunschdenken. Weitere Chancen:
Priorisierung. Du kannst Agenten priorisieren, statt sie zu zählen. Risikostufe plus Geräte- und Benutzerkritikalität ergibt eine Reihenfolge, die auch ein Vorstand versteht.
Prävention statt Nachlese. Der Echtzeitschutz greift vor der Ausführung. Das ist etwas anderes als ein Alert, den jemand morgen früh triagiert.
Ein Werkzeugkasten. Agentendaten liegen in denselben Tabellen wie der Rest. Kein Zusatzportal, kein Extra-SIEM, keine neue Abfragesprache.
Betriebsentlastung. MDR für Drittquellen und Tenant Governance nehmen zwei Dauerbaustellen aus dem Betrieb, die bisher jeder selbst zusammenklebte.
Die Risiken sind nicht technischer, sondern organisatorischer Natur – und genau deshalb gefährlich. Der Preview-Status betrifft praktisch alle Agenten-Funktionen: Vorabversionen ändern sich, Featurenamen wandern, Abdeckung wird verschoben. Wer darauf jetzt eine Betriebsvereinbarung baut, schreibt sie in einem halben Jahr neu. Dazu kommt die Beschränkung auf die Commercial Cloud, was Behörden und regulierte Umgebungen vorerst außen vor lässt.

Sehen kannst du mit Defender for Endpoint P2. Verstehen und eingreifen kostet extra.
Das teuerste Risiko ist die Lizenzkante. Discovery, Inventar und Advanced Hunting bekommst du mit Defender for Endpoint Plan 2 – und damit auch mit Microsoft 365 E5. Risikostufe, Risikoindikatoren und Empfehlungen erfordern dagegen Microsoft 365 E7 oder Microsoft Agent 365 zusätzlich zu Defender for Endpoint Plan 2. Wer das im Business Case übersieht, verspricht dem Management eine Risikobewertung, die er gar nicht einkaufen wollte.
Drei weitere Punkte gehören auf deine Risikoliste. Erstens die Abdeckungslücke: Agenten ohne Work-IQ-MCP-Integration oder mit nicht unterstützten Werkzeugen bleiben ungeschützt, und in einem gewachsenen Umfeld ist das eher die Regel als die Ausnahme. Zweitens die bereits erwähnte Alert-Unterdrückung bei Block-Regeln, die dein Monitoring blind machen kann. Drittens die Prompt Evidence: Standardmäßig werden Ausschnitte aus Prompts und Agentenantworten als Beweismittel in die Alerts geschrieben. Secrets werden redigiert, der Rest bleibt Inhalt einer Nutzerkonversation. Diese Diskussion führst du besser vorher mit dem Betriebsrat als hinterher mit dem Datenschutzbeauftragten.
Was müssen wir jetzt schon vorbereiten?
Die gute Nachricht: Der Großteil davon ist Hausarbeit, die du ohnehin schuldest. Die schlechte: Sie wird nicht dadurch besser, dass du sie noch ein Quartal liegen lässt.
Discovery einschalten und aushalten. Prüfe, ob Defender Antivirus im aktiven Modus läuft und die Plattform- und Engine-Updates aktuell sind. Danach läuft die Erkennung von allein. Plane eine Woche ein, um die Ergebnisliste emotional zu verarbeiten.
Kritikalität klassifizieren. Ohne Asset-Kritikalität für Geräte und Benutzer ist die halbe Bewertung wertlos – genau daraus speisen sich die Kontextindikatoren.
Observability sicherstellen. Microsoft-365-App-Connector einrichten und prüfen, welche Agenten überhaupt Daten senden. Alles, was nicht auf Copilot Studio, Foundry oder dem Agent Builder basiert, braucht das Agent-365-SDK.
Entra Agent IDs vergeben. In den Regelausnahmen tauchen nur Agenten mit Entra Agent ID auf. Ohne saubere Identitäten blockst du entweder alles oder nichts.
Dreißig Tage auditieren, bevor du blockst. Erst die Default-Regel laufen lassen, Trefferquoten und Fehlalarme zählen, dann eng gescopete Block-Regeln für die klaren Fälle bauen. Und vorher das Reporting auf Behaviors umstellen.
Lizenzfrage vorab klären. Kläre mit Einkauf und Partner, ob Microsoft 365 E7 oder Agent 365 kommt – und wenn nicht, welche Aussagen du dann eben nicht treffen kannst. Diese Klarheit ist billiger als eine gescheiterte Erwartung.
Datenschutz und Mitbestimmung einbinden. Prompt-Ausschnitte in Alerts sind zustimmungsfähig, aber erklärungsbedürftig. Die Einstellung lässt sich abschalten – dann verlierst du allerdings genau den Kontext, der eine Untersuchung trägt.
Purview-Labeling hochziehen. Wenn du Copilot ernsthaft ausrollst, nutze die neue Kapazität von bis zu 500.000 Dateien pro Tag und arbeite deinen Altbestand ab, bevor die Agenten ihn für dich entdecken.
|
DER EINSTIEGSSCHRITT, DER NICHTS KOSTET Setze zwei Abfragen auf und lasse sie wöchentlich laufen: erstens alle lokalen Agenten, bei denen autoApprove auf „true“ steht oder der Hostprozess nicht vertrauenswürdig ist; zweitens genau diese Agenten, gejoint auf Geräte mit hoher Kritikalität. Das Ergebnis passt meistens auf eine halbe Seite und ist die ehrlichste Risikoliste, die dein Unternehmen zu AI je gesehen hat. |
|---|
|
FAKTEN KOMPAKT Über 35 erkannte Agententypen · 6 Advanced-Hunting-Tabellen für Agenten · 4 Detection Types für Block-Regeln · Purview: 100.000 auf 500.000 Dateien pro Tag · CWPP-Marktanteil über 22 Prozent · 20 von über 45 Anbietern im Frost Radar bewertet · Preview, Commercial Cloud, E7 oder Agent 365 für die Bewertung. |
|---|
Häufig gestellte Fragen
Brauche ich Microsoft Agent 365, um lokale AI-Agents überhaupt zu sehen?
Nein. Für Entdeckung, Inventar, die konfigurierten MCP-Server und die Abfrage in Advanced Hunting genügt Microsoft Defender for Endpoint Plan 2, das auch in Microsoft 365 E5 enthalten ist. Erst die Risikostufe, die Risikoindikatoren und die Sicherheitsempfehlungen setzen zusätzlich Microsoft 365 E7 oder Microsoft Agent 365 voraus.
Warum bekomme ich keine Alerts mehr, seit meine Block-Regel aktiv ist?
Das ist beabsichtigtes Verhalten: Sobald eine blockierende Regel einen Agenten abdeckt, erzeugt Defender für diesen Agenten keine Near-real-time-Alerts mehr. Die Ereignisse werden weiterhin als Behaviors protokolliert und lassen sich in der Tabelle BehaviorInfo abfragen – dein Monitoring muss also von Alerts auf Behaviors umgestellt werden.
Welche AI-Agents deckt der Echtzeitschutz von Defender nicht ab?
Nicht abgedeckt sind Agenten, die nicht mit Work IQ MCP integriert sind oder auf Werkzeuge setzen, die nicht unterstützt werden. Copilot-Studio- und Foundry-Agenten werden über eigene Wege geprüft, lokale Agenten über den Runtime-Schutz in Defender for Endpoint – selbst gebaute Agenten auf fremden Plattformen brauchen dagegen mindestens die Instrumentierung über das Agent-365-SDK.
Sind die Prompt-Ausschnitte in den Alerts ein Datenschutzproblem?
Sie sind zumindest erklärungsbedürftig. Defender speichert standardmäßig nur die als verdächtig eingestuften Teile von Prompts und Antworten und redigiert Secrets, dennoch handelt es sich um Inhalte aus Benutzerkonversationen. Die Erfassung lässt sich in den Einstellungen unter Security for AI vollständig abschalten, kostet dich dann aber Untersuchungskontext.
Lohnt sich Defender Experts MDR, wenn ich Sentinel mit Drittquellen schon selbst betreibe?
Der Unterschied liegt nicht in der Datenaufnahme, sondern in der Rufbereitschaft: Mit Plan 2 übernimmt Microsoft die Erkennung und Reaktion jetzt auch für über Sentinel eingespeiste Drittquellen wie Palo Alto Networks, AWS oder Okta. Wer ein eigenes SOC mit belastbarem 24/7-Betrieb hat, gewinnt wenig – wer nachts auf Bereitschaftshandys hofft, gewinnt viel.
Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/microsoft-security-update-august-2026-deine-agenten-sind-nicht-mehr-unsichtbar.pdf — © Ulrich B. Boddenberg · boddenberg.de
