In vielen Tenants, die ich betreue, ist Security Copilot spätestens seit Anfang 2024 ein Dauerthema. Was bisher oft fehlte, war die echte Einbindung in die tägliche Arbeit von SecOps-, Identity- oder Compliance-Teams. Meist diente Copilot als unterstützender Chat oder lieferte punktuelle Analysen. Mit der Ankündigung der Security Copilot Agents am 24. März 2025 verschiebt sich das grundlegend. Die Agents sollen Informationen nicht mehr bloß zusammentragen, sondern gezielt Aufgaben übernehmen, etwa die Triage von Alerts in Defender, die Optimierung von Conditional Access in Entra oder das automatisierte Schließen von Schwachstellen in Intune. Gerade diese Automatisierung eröffnet Chancen, wirft aber auch neue Fragen zu Governance und Berechtigungen auf (Quelle).

Die Agents setzen an den Engpässen im Security-Alltag an

Der Alltag im Security Operations Center besteht zu einem großen Teil aus wiederkehrender, oft manueller Arbeit. Phishing-Meldungen wollen bewertet, Alerts nach Dringlichkeit sortiert, Richtlinien optimiert und Schwachstellen priorisiert werden. An genau diesen Engpässen sollen die Agents für Microsoft Security Copilot ansetzen. Sie laufen direkt in den jeweiligen Portalen, beispielsweise als Phishing-Triage-Agent im Defender-Portal, als Agent zur Optimierung von Conditional Access im Microsoft Entra Admin Center, als Remediation-Agent in Intune oder als Insider-Risk-Triage-Agent in Purview (Überblick).

In meinen Projekten wird schnell klar, wo das eigentliche Problem liegt. SecOps- und Compliance-Teams verstehen ihre Aufgaben durchaus, ihnen fehlen schlicht Zeit und Kapazität, um alles gründlich abzuarbeiten. Automatisierte Agents könnten hier viel bewirken, sofern sie zuverlässig vorfiltern, sauber dokumentieren und brauchbare Vorschläge machen. Dafür müssen sie sich allerdings in die bestehenden Freigabe- und Kontrollstrukturen einfügen.

Jeder Agent bekommt eigene Rechte und verbraucht SCUs

Bei Security Copilot Agents kommt es ganz wesentlich auf Identität und Berechtigungen an. Die Agents handeln im Namen der Organisation, greifen auf Security-Daten und administrative Funktionen zu und können je nach Typ auch Aktionen anstoßen. Microsoft hat klargestellt, dass Agents eigene Identitäten und Rechte besitzen und ausdrücklich in der Berechtigungsverwaltung der jeweiligen Plattform erscheinen, also etwa bei den Entra-Rollen, im Intune-RBAC oder bei den Defender-Rollen (Details). Für uns bedeutet das, genau zu prüfen, welche Rechte ein Agent erhält und wie fein sich diese Rechte steuern lassen. Wir befinden uns zwar noch in der Vorschauphase, erste Tests deuten aber darauf hin, dass Agents kein umfassendes Global-Admin-Recht benötigen und sich anwendungsbezogen berechtigen lassen. Außerdem sollte man im Blick behalten, dass Security Copilot Agents über Security Compute Units (SCUs) abgerechnet werden. Es gelten dieselben Limits und Preise wie beim bisherigen Security Copilot. Das gehört in jede Einführungsplanung, vor allem wenn mehrere Agents parallel laufen.

Den Ablauf habe ich in einem einfachen Diagramm skizziert:

flowchart TD
  Benutzer["Security Admin"] --> Agent["Security Copilot Agent"]
  Agent --> Plattform["Defender / Entra / Intune / Purview"]
  Plattform --> Aktion["Agent schlägt Aktion vor"]
  Aktion --> Freigabe["Mensch prüft und bestätigt"]
  Freigabe --> Umsetzung["Aktion wird ausgeführt"]

Abbildung: Ablauf eines Security Copilot Agents mit menschlicher Kontrolle

Auch wenn der Agent vieles automatisiert, bleibt die menschliche Kontrolle an den entscheidenden Stellen Pflicht. Das gilt besonders für Aktionen, die den Tenant verändern.

Die menschliche Freigabe braucht klar definierte Prozesse

In den Ankündigungen wie auch in der Dokumentation betont Microsoft immer wieder, dass Agents als Assistenz gedacht sind und nicht als eigenständige Task-Runner ohne Aufsicht. In der Standardeinstellung muss deshalb jeder entscheidende Schritt von einer berechtigten Person geprüft und freigegeben werden, etwa das Blockieren eines Benutzers, die Anpassung einer Richtlinie oder das Schließen einer Schwachstelle. Von allein läuft das in der Praxis allerdings nicht. Wer Agents ausrollt, muss festlegen, wie Vorschläge geprüft, dokumentiert und bei Bedarf verworfen werden. In Security- und Compliance-Szenarien ist das unverzichtbar, damit es nicht zu Fehlentscheidungen oder ungewollten Automatismen kommt. Für erste Pilotprojekte empfehle ich eine klare Rollentrennung, Freigabe-Workflows und Audit-Logs für sämtliche Agent-Aktionen.

Praxis-Tipp: Richtet für Agents eigene Rollen mit den minimal nötigen Rechten ein und stattet sie nicht pauschal mit „Global Admin“-Berechtigungen aus. Das senkt das Risiko und erleichtert später die Auditierung und Fehleranalyse.

In der Vorschau gehören fünf Punkte auf den Prüfstand

Ab April 2025 werden die Agents als Public Preview ausgerollt. Für mich heißt das, zunächst abzuwarten, nichts überhastet in die Produktivumgebung zu übernehmen und stattdessen gezielt Proofs of Concept aufzusetzen. In den ersten Wochen prüfe ich dabei immer Folgendes:

  • Welche Rechte fordert der Agent tatsächlich an, und sind sie nachvollziehbar?
  • Wie transparent werden die Agent-Aktivitäten protokolliert, etwa im Defender-Portal oder im Entra-Audit-Log?
  • Wie zuverlässig funktionieren die vorgeschlagenen Aktionen? Gibt es Fehlalarme oder unklare Entscheidungen?
  • Lässt sich die menschliche Freigabe flexibel gestalten, also automatisch, abgestuft oder mit mehreren Reviewern?
  • Wie wirkt sich die SCU-Abrechnung im Pilotbetrieb auf die tatsächlichen Kosten aus?

Besonders wichtig ist die Nachvollziehbarkeit im Audit-Log. Wer bereits mit Defender XDR oder Purview arbeitet, kennt das Problem, dass Automatisierungen Schattenentscheidungen treffen, die sich im Nachhinein kaum noch rekonstruieren lassen. Bei den neuen Agents lohnt es sich, hier besonders genau hinzuschauen.

Welche Agent-Aktivitäten aufgezeichnet werden, zeigt eine einfache KQL-Abfrage unter Defender-Portal → Hunting → Advanced hunting. Voraussetzung sind die entsprechende Lizenz und ein aktiviertes Audit-Logging:

DeviceEvents
| where InitiatingProcessAccountName contains "CopilotAgent"
| project Timestamp, DeviceName, ActionType, InitiatingProcessAccountName, ReportId

Automatisierung verlangt Augenmaß und einen schrittweisen Rollout

Security Copilot Agents sind ein folgerichtiger nächster Schritt, eine Plug-and-play-Lösung sind sie aber nicht. Mit der Vorschau ab April 2025 können Admins Automatisierung an den kritischen Schnittstellen zwischen Security, Identity und Compliance praktisch erproben. Wer Agents einsetzen will, braucht die passenden Lizenzen und SCUs, vor allem aber eine klare Governance mit granularer Rechtevergabe, verpflichtender menschlicher Freigabe und nachvollziehbaren Audit-Trails. Ich bin überzeugt, dass die meisten Organisationen mit einem Proof of Concept und einem schrittweisen Rollout am besten fahren. Wer früh testet, kann Richtlinien, Freigaben und Kostenstrukturen anpassen, bevor die Agents fester Bestandteil der Security-Prozesse werden. So behält man die Kontrolle über Automatisierung und Risiken.