Microsofts Intune-Roadmap kündigt den Wechsel des Policy Configuration Agent zu einer Microsoft-Entra-Agentenidentität an. Das klingt zunächst nach Benennung, betrifft betrieblich aber Vertrauen: Eine Dienstkomponente erhält ein eigenes Identitätsmodell, das sich autorisieren und auditieren lässt. Diese Identität verdient dieselbe Prüfung wie jeder andere Automations-Principal.
Bedeutung für den Betrieb
Dienstidentitäten werden schnell unsichtbar, weil die Plattform sie erstellt und niemand sich interaktiv damit anmeldet. Trotzdem können sie Richtlinien auswerten, Dienste aufrufen und große Gerätebestände beeinflussen. Teams müssen feststellen, wo die neue Identität erscheint, welche Rechte sie erhält, wie Zustimmung sichtbar wird, welche Logs ihre Aktivität erfassen und ob Workload-Identity-Kontrollen greifen.
Die Migration verändert auch Störungsfragen. Bei unerwarteter Richtlinienzuweisung muss zwischen menschlicher Administration, Intune-Verarbeitung und agentischer Aktion unterschieden werden. Eine benannte Identität hilft nur, wenn Protokolle erhalten und an das untersuchende Team geleitet werden. Sonst wird sie zum unbekannten Eintrag, der erst während des Vorfalls auffällt.
Vor dem Rollout werden aktuelles Agentenverhalten und Rechte erfasst, Microsoft-Hinweise zum Tenant-Zeitplan geprüft sowie Monitoring und Allowlists angepasst. Eine kleine Gruppe testet Richtlinienzustellung und Auditnachweise. Für dem Agenten zugeschriebene Aktivität braucht es einen dokumentierten Eskalationsweg und im Preview einen begrenzten Wirkungsbereich.
Praktische Konsequenz
Die praktische Konsequenz: Agentische Identität sollte Nachvollziehbarkeit verbessern und nicht nur Automation ermöglichen. Der Principal wird wie Produktionsinfrastruktur behandelt: inventarisieren, Rechte minimieren und prüfen, Auditpfad aufbewahren, Verantwortung benennen. Vertrauen wächst, wenn Automation leichter zu erkennen und zu erklären ist.