15. Mai 2026 | Artikel drucken |

Copilot Cowork handelt allein, das SOC sieht es nicht

7 Min. Lesezeit

Microsoft hat mit Copilot Cowork in der Wave 3 einen Modus eingeführt, der eigenständig handelt: E-Mails verschicken, Termine planen, Dokumente ändern, über mehrere Schritte hinweg und im Hintergrund. Das ist kein Chatbot mehr, das ist ein Akteur mit den Rechten seines Nutzers. Für Security-Teams verschiebt sich damit die Frage. Sie lautet nicht mehr, was der Nutzer tippt, sondern was der Agent in seinem Namen auslöst. Und ob das SOC es überhaupt sieht.

Das Wichtigste in Kürze

  • Cowork handelt, antwortet nicht mehr nur. Der Wave-3-Modus führt mehrstufige Aufgaben autonom im Hintergrund aus und nimmt dabei echte Aktionen vor, mit den Berechtigungen des jeweiligen Nutzers.
  • Prompt-Injection wird zur Aktionskette. Eine manipulierte Mail oder ein präpariertes Dokument, das der Agent mitten in der Aufgabe liest, kann die folgenden Schritte umlenken.
  • Das Stopp-Gate ist optional. Cowork lässt sich überprüfen, lenken und anhalten. Ohne gesetzte Freigabe-Schwelle sieht der Mensch die folgenreiche Aktion erst danach.
  • Die Audit-Spur ist nicht automatisch da. Cowork-Ereignisse sind protokollierbar, aber das Purview-Logging muss eigens dafür konfiguriert werden. Ohne diesen Schritt hat das SOC keine Telemetrie.

Verwandt:Selbst-Replikation: KI-Agenten von 6 auf 81 Prozent  /  AI-Phishing: Mail-Filter werden blind

Was ist Copilot Cowork? Cowork ist der zentrale neue Modus aus Microsofts Copilot Wave 3, vorgestellt am 9. März 2026 und in Zusammenarbeit mit Anthropic gebaut. Anders als der dialogbasierte Copilot führt Cowork lang laufende, mehrstufige Aufgaben aus und nimmt dabei echte Aktionen vor: Termine planen, E-Mails senden, Dokumente bearbeiten. Die Aufgabe läuft im Hintergrund, während der Nutzer an anderem arbeitet. Cowork startet als Research Preview mit ausgewählten Kunden und läuft über das Frontier-Programm.

Vom Assistenten zum Akteur

Der sicherheitsrelevante Bruch liegt nicht in der KI selbst, sondern im Übergang vom Vorschlag zur Handlung. Ein dialogbasierter Copilot formuliert einen Mailentwurf, den ein Mensch liest, prüft und absendet. Cowork sendet die Mail selbst, weil das Senden Teil der beauftragten Aufgabe ist. Zwischen Absicht und Wirkung steht kein menschlicher Klick mehr.

Microsoft beschreibt Cowork bewusst mit Kontrollvokabular. Die Arbeit sei beobachtbar, die Aktionen transparent, der Fortschritt lasse sich überprüfen, lenken und stoppen. Alles laufe innerhalb des Sicherheits-, Identitäts- und Governance-Rahmens von Microsoft 365. Das stimmt. Es ist trotzdem nur die halbe Aussage. Beobachtbar heißt nicht beobachtet. Stoppbar heißt nicht gestoppt. Die Fähigkeiten existieren, ihr Wirksamwerden hängt an Konfiguration und Prozess.

Für ein Security-Team ist das die entscheidende Unterscheidung. Cowork handelt mit der Identität und den Berechtigungen des Nutzers, der die Aufgabe gestartet hat. Ein Agent, der für eine Führungskraft im Vertrieb läuft, kann auf deren Postfach, deren Dokumente und deren Kontakte zugreifen. Wird dieser Agent in eine falsche Richtung gelenkt, handelt er nicht als anonymes Skript, sondern als diese Führungskraft.

Prompt-Injection wird zur Aktionskette

Prompt-Injection ist als Angriffsmuster bekannt. Neu ist die Hebelwirkung, wenn das Ziel kein Chatfenster ist, sondern eine laufende Aktionskette. Ein Beispiel aus der Incident-Perspektive: Cowork bekommt die Aufgabe, eingehende Lieferantenmails zu sichten und Rückfragen zu beantworten. In einer dieser Mails steht, unsichtbar im Fließtext oder in weißer Schrift, eine Anweisung an den Agenten. Sie fordert ihn auf, eine Weiterleitungsregel zu setzen oder eine bestimmte Datei an eine externe Adresse zu schicken.

Der Agent unterscheidet zwischen Daten und Anweisung schlechter als ein Mensch. Liest er die manipulierte Mail mitten in einer mehrstufigen Aufgabe, kann der eingeschleuste Befehl die folgenden Schritte umformen. Der Nutzer hat eine harmlose Aufgabe beauftragt. Der Agent führt am Ende eine zusätzliche aus, die nie autorisiert wurde. Weil beides in derselben Sitzung und unter derselben Identität passiert, sieht es im Protokoll aus wie eine zusammenhängende, gewollte Handlung.

Das ist der Unterschied zur klassischen Injection. Früher endete der Angriff bei einer falschen Antwort im Chat. Jetzt endet er bei einer ausgeführten Aktion mit realer Wirkung, eingebettet in eine Kette legitimer Schritte. Die Kette ist die Tarnung.

Wo das Human-in-the-Loop-Gate fehlt

Microsoft hat die Kontrollpunkte vorgesehen. Cowork lässt sich überprüfen, lenken und anhalten. Die offene Frage ist, an welcher Stelle der Mensch zwingend eingreifen muss, bevor eine folgenreiche Aktion ausgeführt wird. Genau hier entscheidet die Konfiguration über das Risiko.

Ohne eine definierte Freigabe-Schwelle gilt die Standardlogik: Der Agent arbeitet durch, der Mensch kann zusehen. Wer nicht zusieht, sieht das Ergebnis. Für eine Aufgabe wie das Zusammenfassen interner Notizen ist das vertretbar. Für eine Aufgabe, die in einem Schritt eine Mail nach außen schickt oder ein freigegebenes Dokument ändert, ist es das nicht. Diese Aktionen gehören hinter ein Gate, das eine menschliche Bestätigung erzwingt.

Security-Teams sollten Cowork-Aufgaben deshalb nicht pauschal erlauben oder verbieten, sondern nach Wirkung klassifizieren. Aktionen ohne Außenwirkung laufen durch. Aktionen mit Außenwirkung oder mit Schreibzugriff auf geteilte Inhalte brauchen einen Bestätigungsschritt. Diese Klassifizierung ist Handarbeit. Sie ist der wirksamste einzelne Hebel, den ein Unternehmen vor dem Rollout ziehen kann.

Die Detection-Lücke im SOC

Der gefährlichste Punkt ist der unscheinbarste. Microsoft hält fest, dass jede Cowork-Aktion auditierbar ist. Im selben Atemzug steht die Bedingung: Organisationen müssen das Purview-Audit-Logging eigens für Cowork-Ereignisse konfigurieren, um die Compliance zu wahren. Auditierbar und auditiert sind zwei verschiedene Zustände.

Was offen bleibt

  • Cowork-Ereignisse ohne konfiguriertes Purview-Logging erzeugen keine SOC-Telemetrie
  • Agenten-Aktionen laufen unter Nutzer-Identität und fallen in Standard-Logs nicht auf
  • Kein Gate vor folgenreichen Aktionen, wenn keine Freigabe-Schwelle gesetzt ist
  • Prompt-Injection in Aktionsketten hinterlässt eine scheinbar legitime Schritt-Folge

Was vor dem Rollout trägt

  • Purview-Audit-Logging für Cowork-Ereignisse explizit aktivieren
  • Cowork-Aufgaben nach Außenwirkung klassifizieren und Gates setzen
  • Detection-Regeln für anomale Agenten-Aktionen im SOC ergänzen
  • Cowork-Berechtigungen auf einen Pilotkreis begrenzen, nicht flächig freigeben

Ein Unternehmen, das Cowork freigibt, ohne das Logging dafür einzuschalten, hat einen autonomen Akteur im Netz, dessen Handlungen im Standard-Auditpfad nicht erscheinen. Im Incident-Fall fehlt damit genau die Spur, die zeigt, was der Agent wann getan hat. Die Forensik beginnt dann nicht bei den Logs, sondern bei einer Lücke.

Hinzu kommt das Identitätsproblem. Weil Cowork unter der Identität des beauftragenden Nutzers handelt, lösen seine Aktionen in SIEM und EDR keine offensichtlichen Anomalien aus. Eine Mail, die ein Nutzer-Account verschickt, ist erst einmal normal. Dass dahinter ein Agent stand, der durch eine manipulierte Eingabe umgelenkt wurde, steht in keinem Standard-Alert. Detection für Agenten-Aktivität ist eine eigene Aufgabe, kein Nebenprodukt vorhandener Regeln.

Was Security-Teams jetzt tun

Cowork ist über das Frontier-Programm und als Research Preview im Anlauf. Das ist das richtige Zeitfenster, um die Kontrollen zu setzen, bevor der breite Rollout kommt. Vier Schritte gehören vorgezogen.

Erstens das Logging. Purview-Audit-Logging für Cowork-Ereignisse aktivieren, bevor der erste produktive Agent läuft. Ohne diesen Schritt ist jede weitere Maßnahme blind.

Zweitens die Klassifizierung. Cowork-Aufgaben nach Außenwirkung sortieren. Aktionen, die nach außen senden oder geteilte Inhalte ändern, bekommen eine erzwungene menschliche Bestätigung. Aktionen ohne Außenwirkung dürfen durchlaufen.

Drittens die Detection. Das SOC braucht Regeln für anomales Agenten-Verhalten: ungewöhnliche Weiterleitungsregeln, Massen-Dateizugriffe in kurzer Zeit, Außenkommunikation außerhalb des üblichen Musters. Diese Regeln entstehen nicht von selbst.

Viertens der Pilotkreis. Cowork startet auf einer begrenzten Nutzergruppe, nicht auf der ganzen Belegschaft. Der Pilot liefert die realen Aktionsmuster, gegen die sich Detection-Regeln überhaupt erst kalibrieren lassen.

Die Einordnung ist nüchtern. Cowork ist kein unbeherrschbares Risiko. Microsoft hat die Werkzeuge zur Kontrolle mitgeliefert. Der Fehler wäre, die Werkzeuge für die Kontrolle selbst zu halten. Ein Agent, der eigenständig handelt, ist genau so sicher wie die Gates und Logs, die ein Security-Team vor dem Rollout gesetzt hat. Danach ist es Aufräumarbeit.

Häufige Fragen

Was ist Copilot Cowork?

Cowork ist der neue autonome Modus aus Microsofts Copilot Wave 3, vorgestellt am 9. März 2026. Er führt lang laufende, mehrstufige Aufgaben im Hintergrund aus und nimmt dabei echte Aktionen vor, etwa Termine planen, E-Mails senden und Dokumente bearbeiten. Cowork wurde in Zusammenarbeit mit Anthropic entwickelt und startet als Research Preview über das Frontier-Programm.

Warum ist Cowork ein Security-Thema?

Weil Cowork nicht nur Text vorschlägt, sondern Aktionen ausführt – mit der Identität und den Berechtigungen des beauftragenden Nutzers. Zwischen Absicht und Wirkung steht kein menschlicher Klick mehr. Wird der Agent durch eine manipulierte Eingabe umgelenkt, handelt er als dieser Nutzer, ohne dass es im Standard-Protokoll auffällt.

Wie funktioniert Prompt-Injection bei einem autonomen Agenten?

Der Agent liest während einer Aufgabe Inhalte wie Mails oder Dokumente. Enthält ein solcher Inhalt eine versteckte Anweisung, kann der Agent sie als Befehl statt als Daten behandeln. In einer mehrstufigen Aufgabe lenkt das die folgenden Schritte um. Das Ergebnis ist eine ausgeführte, nicht autorisierte Aktion, eingebettet in eine sonst legitime Schritt-Folge.

Sind Cowork-Aktionen nachvollziehbar?

Sie sind auditierbar, aber nicht automatisch protokolliert. Organisationen müssen das Purview-Audit-Logging eigens für Cowork-Ereignisse konfigurieren. Ohne diesen Schritt erzeugen die Aktionen keine SOC-Telemetrie. Im Incident-Fall fehlt die Spur, was der Agent wann getan hat.

Was sollten Security-Teams vor dem Rollout tun?

Vier Dinge: das Purview-Audit-Logging für Cowork aktivieren, Cowork-Aufgaben nach Außenwirkung klassifizieren und Freigabe-Gates setzen, Detection-Regeln für anomale Agenten-Aktionen im SOC ergänzen und Cowork zunächst auf einen Pilotkreis begrenzen statt flächig freizugeben.

Lesetipps der Redaktion

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Mai 2026)

Alec Chizhik

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor

Auch verfügbar in

FrançaisEspañolEnglish
Ein Magazin der Evernine Media GmbH