Intune AI Agent Runtime Protection: Zwei Prüfpfade

Ich habe das neue Profil für AI Agent Protection in Intune geöffnet. Dort gibt es eine Einstellung. Microsoft beschreibt bei Runtime Protection aber zwei Inspektionswege.

Das übersieht man schnell, wenn die Abnahme bei „Richtlinie wurde zugewiesen“ endet. Es wird wichtig, sobald die Frage lautet: Was schützt diesen Coding-Agenten auf genau diesem Windows-Gerät?

Ich bin am 12. Oktober 2026 durch die Oberfläche in meinem Modern-Device-Management-Tenant gegangen. Hier zeige ich die echten Ansichten, die notwendigen Abgrenzungen und einen kleinen PowerShell-Collector. Er liest Einstellungen, verändert sie aber nicht. Ein erfolgreicher Blockiertest auf einem Windows-Endgerät ist damit noch nicht belegt.

Das Profil ist da. Der Schutzumfang braucht trotzdem eine Prüfung.

Der aktuelle Weg in meinem Tenant lautet Endpoint security → Antivirus → Create Policy → Windows → Microsoft Defender AI agent runtime protection.

Ich habe einen temporären Namen eingetragen, Configuration settings geöffnet und Defender aufgeklappt. Dort erschien Ai Agent Protection mit den Optionen Disabled, Block und Audit.

Der Hilfetext beschreibt die native Hook-/Bridge-Integration. Für die Einordnung ist dieser konkrete Text nützlicher als die allgemeinere Beschreibung bei der Profilauswahl.

Alle Aufnahmen stammen aus derselben Sitzung. Ich habe das Formular verworfen, ohne eine Richtlinie anzulegen oder zuzuweisen.

Native Events und Netzwerkverkehr sind getrennte Wege

Microsoft unterscheidet Agent-native Event-Inspektion und die Inspektion unterstützter Agent-zu-Modell-Netzwerkverbindungen. Die Einstellungen heißen AiAgentProtection und AiAgentNetworkInspection. Das dokumentierte Intune-Antivirusprofil konfiguriert den nativen Weg, die Netzwerkinspektion hat einen separaten PowerShell-Einrichtungsweg. Einrichtung bei Microsoft.

Deshalb würde ich nicht schreiben: „Aktiviere dieses Profil, dann sind alle lokalen Agents abgesichert.“ Dahinter stecken zwei verschiedene Fragen.

Ist der relevante Inspektionsweg auf dem Gerät eingeschaltet? Und unterstützt die konkrete Kombination aus Anwendung, Betriebssystem und Nutzungsmodus diesen Weg?

Eine Windows-Richtlinie beantwortet beispielsweise nicht automatisch, was mit einem Agenten in einer anderen Laufzeitumgebung passiert.

Auch die Netzwerkinspektion ist keine pauschale Paketkontrolle für sämtliche AI-Anwendungen. Microsoft nennt unter anderem Certificate Pinning und HTTP/3 als nicht unterstützte Fälle. Runtime-Protection-Überblick.

Ich würde eine unterstützte Client-Konfiguration wählen. Transportverschlüsselung abzuschwächen, nur damit eine Demo durch einen Inspektionsweg passt, wäre nicht mein Ansatz.

Die Support-Matrix ist wichtiger als der Produktname

Bei der Prüfung fiel eine konkrete Unstimmigkeit auf: Der Überblick nennt Codex CLI bei nativen Schnittstellen. In der detaillierten Runtime-Support-Tabelle war Codex am Prüftag jedoch nicht unter der nativen Inspektion aufgeführt – in der Discovery-Tabelle dagegen schon.

Diese Kombination würde ich bis zur Klärung als nicht bestätigt behandeln. Eine allgemeine Aussage aus dem Überblick ist kein ausreichender Beleg für eine konkrete Deployment-Zusage.

Die Tabelle unterscheidet außerdem beispielsweise Claude Desktop im Code-Modus und ChatGPT Desktop im Chat-Modus. Für Letzteres ist beim Netzwerkweg eine mindestens getestete Version angegeben. Discovery und Runtime Protection stehen bewusst in getrennten Tabellen. Aktuelle Support-Matrix.

Mein Pilot-Prüfblatt hätte deshalb diese Felder:

Eine unbekannte Angabe bleibt unbekannt. Sie sollte nicht beim nächsten Export versehentlich zu einem grünen Haken werden.

Voraussetzungen vor den Alert-Screenshots prüfen

Die Preview-Einrichtung verlangt eine passende Defender-Lizenz, ein angebundenes Gerät, aktiven Defender Antivirus und aktuelle Plattform-, Engine- und Intelligence-Stände. Der Leitfaden nennt auch den Preview-Updatekanal und eine Mindestversion der Intelligence. Diese Voraussetzungen würde ich vor jedem Pilot mit der aktuellen Dokumentation abgleichen. Microsoft-Voraussetzungen.

Ohne diesen Ausgangszustand ist „kein Alert“ kaum interpretierbar. War die Erkennung unzureichend? War die Anwendung nicht unterstützt? Oder war das Gerät gar nicht bereit?

Die Richtlinie finde ich im Portal. Den effektiven Zustand prüfe ich auf dem Gerät. Die Erkennung korreliere ich in der Security-Oberfläche. Diese drei Fragen sollten nicht in einem einzigen Statusfeld verschwinden.

Ein rein lesender PowerShell-Check

Für einen ersten Blick auf dem Windows-Testgerät:

# Liest nur. Aktiviert keinen der beiden Schutzwege.
Get-MpPreference |
    Select-Object AiAgentProtection, AiAgentNetworkInspection

Get-MpComputerStatus |
    Select-Object AntivirusEnabled, RealTimeProtectionEnabled,
                  AMRunningMode, AMProductVersion,
                  AntivirusSignatureVersion

Eine fehlende Property bedeutet nicht dasselbe wie Disabled. Eine ältere Plattform kann eine andere Objektstruktur zurückgeben. Das sollte im Nachweis erhalten bleiben.

Der folgende Collector macht diesen Unterschied sichtbar. Er gibt JSON aus, sendet keine Netzwerkanfrage und ruft kein Set-MpPreference auf:

[CmdletBinding()]
param()

$ErrorActionPreference = 'Stop'
$report = [ordered]@{
    CapturedAtUtc = [DateTime]::UtcNow.ToString('o')
    Scope = 'Local settings only; no enforcement test'
    AiAgentProtection = $null
    AiAgentNetworkInspection = $null
    Errors = @()
}

try {
    $preferences = Get-MpPreference
    foreach ($name in @('AiAgentProtection', 'AiAgentNetworkInspection')) {
        $property = $preferences.PSObject.Properties[$name]
        if ($null -eq $property) {
            $report.Errors += "Property unavailable: $name"
        } else {
            $report[$name] = [string]$property.Value
        }
    }
} catch {
    $report.Errors += 'Could not read Defender preferences.'
}

[pscustomobject]$report | ConvertTo-Json -Depth 4

Die Werte so bewahren, wie sie zurückgegeben werden. Numerische Enums nicht anhand einer ähnlich benannten Richtlinie interpretieren. Ein Fehler im Report heißt „prüfen“, nicht „Schutz bestätigt“.

Den vollständigen Collector habe ich lokal auf Syntax geprüft. Defender-Cmdlets wurden in dieser Sitzung nicht gegen ein Windows-Endgerät ausgeführt. Deshalb gibt es hier auch keinen vermeintlichen Gerätenachweis.

Zuerst normale Arbeit testen

Eine Sicherheitsprüfung sollte nicht nur aus einem eindrucksvollen blockierten Prompt bestehen. Ich würde mit einem Entwickler einen kleinen Satz normaler Aufgaben vereinbaren:

1. Ein fiktives Repository lesen und eine Funktion erklären.
2. Eine kleine Codeänderung darin vorschlagen.
3. Bestehende Tests über den normalen Freigabeprozess starten.
4. Eine harmlose Antwort vom genehmigten Testdienst verarbeiten.

Ergebnis, unerwartete Rückfragen und neue Reibung festhalten. Ein Schutz, der die Demo blockiert, aber alltägliche Arbeit unbrauchbar macht, wird auf Dauer kaum akzeptiert.

Danach würde ich Microsofts harmloses Validierungsszenario im freigegebenen Pilot ausführen. Die verlinkte Demo setzt ausdrücklich die native Inspektion voraus; sie ist kein allgemeiner Test der Netzwerkinspektion. Eine Ablehnung durch den Agenten selbst beweist außerdem noch keine Defender-Erkennung. Microsoft-Demonstration.

Keine echten Zugangsdaten oder Kundendokumente als Köder verwenden. Ein synthetischer Marker reicht, um die Nachweiskette zu prüfen. Mehr Risiko macht das Ergebnis nicht aussagekräftiger.

Audit, Block und eine brauchbare Abnahme

Audit lässt eine erkannte Aktion weiterlaufen und protokolliert die Erkennung. Block soll unterstützte schädliche Aktivität am verfügbaren Inspektionspunkt stoppen. Beides ist keine Garantie, dass ein Agent keine falsche Entscheidung mehr treffen kann. Betriebsarten bei Microsoft.

Für den Rollout würde ich einen kleinen Entwickler-Ring nehmen. Endpoint Engineering und Security sehen dieselben Ergebnisse. Vorher festlegen, welcher Fehlalarm die Ausweitung stoppt und wann eine Ausnahme ausläuft. Das sind meine Betriebsempfehlungen, keine zusätzlichen Produktschalter.

Wer schließt die Lücke zwischen Inventar und Schutz?

Hier hilft Erfahrung aus dem Endpoint-Betrieb: Inventar, Konfiguration und Verhalten brauchen eigene Nachweise.

Das Endpoint-Team kennt das verwaltete Gerät und die effektiven Einstellungen. Der AI-Plattformverantwortliche kennt Client und Arbeitsablauf. Security prüft die passende Erkennung und deren Untersuchung.

Ich würde alle drei in die Pilot-Abnahme holen. Sonst meldet ein Team „Agent entdeckt“, ein anderes „Richtlinie verteilt“, und niemand merkt, dass der tatsächliche Ablauf einen anderen Weg nimmt.

Mein OpenClaw- und Shadow-AI-Artikel beginnt beim Finden und Untersuchen lokaler AI-Nutzung. Hier geht es um den nächsten Schritt: Welchen tatsächlich aktiven Schutz kannst du nachweisen?

Häufige Fragen zu Intune AI Agent Runtime Protection

Aktiviert das Intune-Profil beide Inspektionswege?

Nein. Das dokumentierte Antivirus-Profil konfiguriert die native Inspektion. Netzwerk-Inspektion hat eine eigene Einrichtung. Prüfe AiAgentProtection und AiAgentNetworkInspection auf dem Windows-Gerät und gleiche Client und Version mit der Support-Matrix ab.

Ist ein erkannter AI-Agent automatisch geschützt?

Nein. Discovery, Richtlinienzuweisung und Runtime-Enforcement sind unterschiedliche Nachweise. Intune AI Agent Runtime Protection braucht einen unterstützten Client-Pfad und die überprüfte Gerätekonfiguration. Ein Inventareintrag allein belegt das nicht.

Was hilft nach dem Pilot weiter?

Für den Betrieb helfen die Einordnung der Security-Copilot-Agents in Intune und mein Intune-Troubleshooting-Ablauf. Die getrennten nativen und Netzwerk-Prüfungen bleiben trotzdem notwendig.

Mein Fazit

Ich finde es gut, dass Agent Runtime Protection im Endpoint-Management ankommt. Die sinnvolle Einheit für die Abdeckung bleibt aber: diese Anwendung, in diesem Modus, auf diesem Gerät, über diesen Inspektionsweg.

Dort anfangen. Beide Einstellungen getrennt lesen. Normale Arbeit und vereinbarte Validierung testen. Nicht unterstützte Kombinationen sichtbar lassen.

Eine Richtlinie ist ein guter Anfang. Sie ist kein Beweis dafür, dass alle Agents geschützt sind.