Microsofts Defender Security Research Team hat im Februar 2026 eine Top-10-Liste der häufigsten Copilot Studio Agent-Sicherheitsrisiken veröffentlicht. Die zentrale Erkenntnis: Keines der zehn Risiken ist ein exotischer Zero-Day-Exploit. Jedes einzelne ist eine Fehlkonfiguration. Agents ohne Authentifizierung. Agents, die mit den Rechten des Erstellers laufen statt mit denen des Nutzers. Agents, die E-Mails an beliebige Empfänger senden, weil das LLM zur Laufzeit entscheidet. Das sind die Standardeinstellungen und Abkürzungen, mit denen Agents in Produktion gehen, ohne dass jemand die Lücken bemerkt.

Zu jedem Risiko liefert Microsoft eine Defender Advanced Hunting Query. Das macht diese Veröffentlichung zu einer der wenigen Vendor-Advisories, die das Erkennungswerkzeug direkt mitliefern. Wer Copilot Studio im Einsatz hat, hat hier seine Checkliste.

Weiterlesen: OWASP Top 10 für agentische Anwendungen: Alle Risiken mit realen Angriffen erklärt

Zugriff und Authentifizierung

Drei der zehn Risiken betreffen direkt, wer auf Agents zugreifen kann und welche Anmeldedaten diese zur Laufzeit verwenden.

Agents ohne Authentifizierung

Das kritischste Risiko auf der Liste. Wenn die Authentifizierung zum Testen deaktiviert und danach nie wieder aktiviert wurde, oder wenn der Standardzustand beibehalten wird, weil der Ersteller annahm, dass sich jemand anderes darum kümmert, wird der Agent zu einem öffentlichen Einstiegspunkt in die Organisationsdaten. Jeder mit der URL kann mit ihm interagieren. Microsoft formuliert es deutlich: Der Agent “verhält sich wie ein öffentlicher Zugangspunkt zu Organisationsdaten oder -logik.”

Die zugehörige Defender Advanced Hunting Query heißt “AI Agents: No Authentication Required” und ist in Microsofts Community Hunting Queries Repository verfügbar. Wer Ergebnisse bekommt, sollte diese Agents sofort isolieren.

Ersteller-Authentifizierung statt Nutzer-Authentifizierung

Dieses Risiko ist subtil und wird häufig übersehen. Wenn ein Copilot Studio Agent mit “Author Authentication” konfiguriert ist, verbindet er sich mit Backend-Diensten über die Anmeldedaten des Erstellers, nicht die des aufrufenden Nutzers. Jeder Nutzer des Agents arbeitet damit effektiv mit den Berechtigungen des Erstellers. Ist der Ersteller ein Senior Admin, hat jeder Agent-Nutzer Senior-Admin-Zugriff auf die angebundenen Systeme.

Die Lösung: Nutzer-Authentifizierung über die Power Platform Admin-Einstellungen erzwingen. Für autonome Agents dedizierte Service-Identitäten mit minimalen Rechten einrichten.

Zu breite Freigabe

Einen Agent für die gesamte Organisation freizugeben klingt praktisch, bis man bedenkt, dass auch kompromittierte Konten dessen Aktionen auslösen können. Ein breit freigegebener Agent mit Zugriff auf sensible Datenspeicher oder Schreibrechten auf Produktionssysteme ist funktional gleichbedeutend mit einem Service-Account für alle Mitarbeitenden.

Microsoft empfiehlt, die Freigabe auf rollenbasierte Sicherheitsgruppen zu beschränken und numerische Grenzen pro Umgebung festzulegen.

Datenabfluss-Vektoren

Zwei Risiken adressieren, wie Agents zu Datenabfluss-Kanälen werden können, insbesondere über E-Mail und zu breit konfigurierte Wissensquellen.

E-Mail-basierter Datenabfluss

Agents, die generative Orchestrierung zum E-Mail-Versand nutzen, sind inhärent riskant, weil das LLM Empfänger und Inhalt zur Laufzeit bestimmt. Bei einem erfolgreichen Indirect Prompt Injection Angriff kann ein Angreifer den Agent anweisen, interne Daten an eine externe Adresse weiterzuleiten. Die Angriffsfläche vergrößert sich, wenn Agents externe Eingaben verarbeiten: ein manipuliertes Dokument in SharePoint, eine präparierte E-Mail oder ein Kalendereintrag können den Injection-Payload tragen.

Die Gegenmaßnahme ist direkt: E-Mail-Empfänger auf genehmigte Domain-Allowlists beschränken. Den Orchestrator nicht frei über Empfänger entscheiden lassen, bis richtlinienbasierte Kontrollen ausgereift sind.

Zu breit konfigurierte Wissensquellen

Wenn die Wissensquellen eines Agents zu breit oder schlecht kuratiert sind, kann er Daten weit über seine eigentliche Aufgabe hinaus abrufen und ausgeben. Ein Angreifer, der über Prompt-Manipulation mit dem Agent interagiert, kann sensible Informationen aus diesen überbreiten Wissensdatenbanken extrahieren. Das entspricht ASI07 (RAG Poisoning) im OWASP-Framework, allerdings von der Konfigurationsseite statt der Daten-Poisoning-Seite.

Wissensquellen auf das Minimum beschränken, das der Agent tatsächlich braucht. Prüfen, auf welche Daten jeder Agent zugreifen kann, nicht nur, was er verwenden soll.

Weiterlesen: KI Agent Security: Die Governance-Lücke, die 88% der Unternehmen bereits spüren

Infrastruktur und Credentials

Drei Risiken zielen auf die technische Grundlage: wie Agents sich mit externen Diensten verbinden, welche Anmeldedaten sie mitführen und welche Tools sie exponieren.

Unsichere HTTP-Requests

Copilot Studios HttpRequestAction erlaubt Agents, direkte HTTP-Aufrufe zu machen. Wenn ein Ersteller während des Testens einen Beispiel-Request kopiert oder einen internen Endpunkt für schnelle Tests ansteuert, kann dieses Muster in die Produktion gelangen. Sicherheitsforscher von Tenable haben gezeigt, dass diese HTTP-Actions SSRF-Schutzmaßnahmen umgehen und Cloud-Instanz-Metadaten (IMDS) abrufen konnten. In einem Fall führte das zu Tokens mit Lese-/Schreibzugriff auf interne Cosmos DB-Ressourcen.

Gegenmaßnahme: HTTPS auf allen Endpunkten erzwingen, nicht-standardisierte Ports blockieren und eingebaute Connectors (die Identitätsvalidierung und Throttling bieten) gegenüber rohen HTTP-Requests bevorzugen.

Hart kodierte Credentials

API-Keys, Tokens und Connection Strings, die direkt in Agent-Topic-Definitionen oder Action-Konfigurationen eingebettet sind. Die Detection Query sucht nach Literal-Secrets in Agent-Definitionen. Die Lösung ist Standard-Secret-Management: alles nach Azure Key Vault migrieren, umgebungsreferenzierte Variablen verwenden und Rotationsrichtlinien implementieren.

Unkontrollierte MCP-Tools

Model Context Protocol (MCP)-Tools geben Agents benutzerdefinierte Zugriffspfade zwischen dem Modellkontext und externen Systemen. Weil MCP-Tools relativ neu und potenziell undokumentiert sind, können sie verborgene Aktionskanäle außerhalb der erwarteten Governance-Kontrollen schaffen. Microsofts Position: alle MCP-Tool-Deployments mit einem Security Review gaten, explizite Dokumentation von Tool-Verhalten und -Berechtigungen verlangen und die “MCP Tool Configured” Hunting Query ausführen, um den Bestand zu inventarisieren.

Weiterlesen: MCP unter Beschuss: CVEs, Tool Poisoning und wie Sie Ihre KI-Agent-Integrationen absichern

Lifecycle und Orchestrierung

Die letzten zwei Risiken betreffen vergessene Agents und fehlende operative Leitplanken.

Verwaiste und inaktive Agents

Inaktive Agents sind veröffentlichte Agents, die seit 30+ Tagen nicht genutzt oder überprüft wurden. Verwaiste Agents gehören Mitarbeitenden, die das Unternehmen verlassen haben oder deren Konten deaktiviert wurden. Beide sind Schatten-IT in ihrer gefährlichsten Form: Sie behalten aktive Berechtigungen, verbundene Credentials und Netzwerkzugriff, aber niemand überwacht sie. Die “Published Dormant 30d” und “Orphaned Agents with Disabled Owners” Advanced Hunting Queries decken diese Artefakte auf.

Das Behebungsmuster: benannte Ownership für jeden Agent erzwingen, vierteljährliche Zertifizierungsreviews durchführen und Agents automatisch isolieren, wenn das Konto des Owners deaktiviert wird.

Generative Orchestrierung ohne Anweisungen

Wenn ein Copilot Studio Agent generative Orchestrierung nutzt, aber keine expliziten Anweisungen hat, hat das LLM maximale Freiheit und minimale Leitplanken. Ohne Einschränkungen kann der Orchestrator seinen Ausgabebereich nicht begrenzen, was den Agent deutlich anfälliger für Prompt Injection und unbeabsichtigtes Verhalten macht. Das ist vergleichbar mit dem Deployment eines Agents mit leerem System Prompt: technisch funktionsfähig, praktisch unkontrollierbar.

Jede Orchestrierung muss klare, explizite Anweisungen enthalten, die definieren, was der Agent darf und was nicht, wen er kontaktieren kann und auf welche Daten er zugreifen darf.

Zuordnung zum OWASP-Framework

Microsofts Top 10 ist kein Konkurrenzprodukt zum OWASP Top 10 for Agentic Applications. Es ist eine plattformspezifische Umsetzungshilfe, die sich natürlich auf die OWASP-Kategorien abbilden lässt. Fehlende Authentifizierung und Ersteller-Authentifizierung entsprechen ASI03 (Identity Abuse). E-Mail-Exfiltration bildet sich auf ASI01 (Agent Goal Hijack) ab, wenn durch Prompt Injection ausgelöst. Überbreite Wissensquellen korrespondieren mit ASI07 (RAG Poisoning). Der Mehrwert von Microsofts Liste ist die Konkretheit: statt abstrakter Risikokategorien bekommt man “führe diese Query aus, prüfe diese Einstellung, ändere diese Konfiguration.”

Der CoPhish-Angriff zeigt genau, warum plattformspezifische Guidance wichtig ist. Forscher nutzten öffentlich zugängliche Copilot Studio Agents auf vertrauenswürdigen Microsoft-Domains, um über OAuth-Flows Nutzer-Access-Tokens abzugreifen. Das ermöglichte Zugriff auf E-Mails, Chats, Kalender und OneNote-Daten. Die Agents waren standardmäßig öffentlich. Allgemeine Sicherheitsempfehlungen würden sagen “Authentifizierung erzwingen.” Microsofts spezifische Guidance sagt, welche Admin-Einstellung zu ändern ist und welche Defender-Query jede betroffene Instanz findet.

Für Unternehmen im DACH-Raum kommt ein zusätzlicher Aspekt hinzu: Der EU AI Act verpflichtet Betreiber von KI-Systemen ab August 2026 zu Risikobewertungen und Dokumentation. Agents ohne Authentifizierung oder mit überbordenden Berechtigungen dürften die Anforderungen an technische Robustheit nach Artikel 15 kaum erfüllen. Wer Microsofts Checkliste jetzt abarbeitet, schafft gleichzeitig eine solide Grundlage für die DSGVO-Folgenabschätzung und die EU-AI-Act-Konformitätsprüfung.

Weiterlesen: Microsoft Cyber Pulse: 80% der Fortune 500 betreiben aktive KI-Agents, die meisten ohne Einblick

Priorisierte Reihenfolge zur Behebung

Wer vor dieser Liste steht und sich fragt, wo anfangen: Microsofts implizite Priorisierung ergibt sich aus der Schwere der einzelnen Risiken:

  1. Agents ohne Authentifizierung zuerst. Das sind internet-exponierte Angriffsflächen. Die Detection Query heute ausführen.
  2. Agents mit Ersteller-Authentifizierung. Jeder davon ist ein Privilege-Escalation-Pfad.
  3. Verwaiste Agents. Wenn der Owner weg ist, fällt niemandem auf, wenn der Agent kompromittiert wird.
  4. E-Mail-fähige Agents mit uneingeschränkten Empfängern. Das sind Datenabfluss-Kanäle, die auf eine Prompt Injection warten.
  5. HTTP Request Actions. Die Tenable-SSRF-Forschung beweist, dass diese ausnutzbar sind.
  6. Alles andere. Breite Freigabe, hart kodierte Credentials, MCP-Tools, Orchestrierung ohne Anweisungen und überbreite Wissensquellen.

Das übergeordnete Muster: Agent-Security dreht sich nicht um die Abwehr ausgefeilter Angriffe. Es geht darum, Konfigurationen zu fixen, die nie so in Produktion hätten gehen dürfen.

Source

Häufig gestellte Fragen

Was sind die größten Copilot Studio Agent-Sicherheitsrisiken?

Microsoft hat 10 Copilot Studio Agent-Fehlkonfigurationen identifiziert: fehlende Authentifizierung, zu breite Freigabe, Ersteller-Authentifizierung statt Nutzer-Authentifizierung, unsichere HTTP-Requests, E-Mail-basierter Datenabfluss, hart kodierte Credentials, unkontrollierte MCP-Tools, fehlende Orchestrierungsanweisungen, inaktive Agents und verwaiste Agents ohne aktive Owner.

Wie erkennt man Copilot Studio Agent-Fehlkonfigurationen?

Microsoft stellt für jedes der 10 Risiken Advanced Hunting Queries in Microsoft Defender bereit. Wichtige Queries sind “AI Agents: No Authentication Required” für Agents ohne Authentifizierung, “Published Dormant 30d” für inaktive Agents und “Orphaned Agents with Disabled Owners” für verwaiste Agents. Diese sind im Community Hunting Queries Repository von Microsoft verfügbar.

Was ist Ersteller-Authentifizierung in Copilot Studio und warum ist sie gefährlich?

Bei “Author Authentication” verbindet sich ein Copilot Studio Agent mit Backend-Diensten über die Anmeldedaten des Erstellers statt die des aufrufenden Nutzers. Jeder Nutzer erbt damit die Berechtigungsstufe des Erstellers. Hat der Ersteller Admin-Rechte, hat jeder Agent-Nutzer Admin-Zugriff. Die Lösung ist die Erzwingung von Nutzer-Authentifizierung über Power Platform Admin-Einstellungen.

Wie verhält sich die Copilot Studio Top 10 zum OWASP Top 10 für agentische Anwendungen?

Microsofts Liste ist plattformspezifisch statt eine generische Taxonomie. Sie bildet sich auf OWASP-Kategorien ab (fehlende Authentifizierung auf ASI03 Identity Abuse, E-Mail-Exfiltration auf ASI01 Agent Goal Hijack, überbreite Wissensquellen auf ASI07 RAG Poisoning), liefert aber konkrete Detection Queries und Behebungsschritte speziell für Copilot Studio und Microsoft Defender.

Welche Bedeutung hat die Copilot Studio Top 10 für den EU AI Act?

Der EU AI Act verpflichtet Betreiber von KI-Systemen ab August 2026 zu Risikobewertungen und Dokumentation. Agents ohne Authentifizierung oder mit überbordenden Berechtigungen dürften die Anforderungen an technische Robustheit nach Artikel 15 kaum erfüllen. Microsofts Checkliste liefert eine praktische Grundlage für die DSGVO-Folgenabschätzung und EU-AI-Act-Konformitätsprüfung.