In den vergangenen Monaten habe ich in einigen Microsoft-365-Tenants miterlebt, wie Copilot-Studio-Agenten vom Pilotbetrieb in den Produktivbetrieb wechselten. Sicherheit ist bei Copilot Studio alles andere als ein Nebenschauplatz. Trotzdem gehen Agenten viel zu oft mit Standardeinstellungen und ungeklärten Berechtigungen live. Sobald eigene Wissensquellen, Aktionen oder externe Konnektoren dazukommen, kann es schnell heikel werden. Wer vorher nicht prüft, welche Identitäten und Rechte tatsächlich beteiligt sind, riskiert Datenabfluss und Ärger mit der Compliance. Im Folgenden stelle ich meine Checkliste vor, mit der ich Copilot-Studio-Agenten vor dem Start systematisch auf Sicherheit abklopfe. Außerdem zeige ich, was im Oktober 2025 bei Governance und Logging bereits möglich ist.

Die Authentifizierung entscheidet, unter welcher Identität ein Agent handelt

Ob ein Agent sicher ist, hängt zuerst an der Authentifizierung. Wer darf ihn nutzen, und unter welcher Identität laufen seine Aktionen? In der Praxis begegnen mir oft Agenten, die für „Jeder im Tenant“ freigegeben sind oder überhaupt keine Zugriffsbeschränkung haben. Besser arbeitet man hier immer gezielt mit Gruppen oder Entra-ID-Rollen. Noch kritischer wird es, sobald Aktionen hinzukommen, etwa über Power-Automate-Flows oder Konnektoren. Dann stellt sich die Frage, ob der Agent mit den Berechtigungen der Endnutzerin arbeitet oder mit den Anmeldeinformationen des Makers, die oft viel zu weit reichen. Die Unterscheidung zwischen „User“- und „Maker“-Kontext ist in Copilot Studio zentral, denn Aktionen mit Maker-Credentials öffnen den Zugang zu Systemen, die normale Nutzer nie erreichen sollten. Wer hier nachbessern möchte, findet die Details im offiziellen Leitfaden zu Security und Governance.

Wissensquellen bekommen nur so viele Rechte wie unbedingt nötig

Eigene Wissensquellen (SharePoint, OneDrive, Azure SQL, …) machen Agenten erst wirklich nützlich. Sind die Zugriffsrechte falsch gesetzt, laden sie allerdings zum Oversharing ein. Ich rate deshalb immer dazu, die Berechtigungen der eingebundenen Quellen zu dokumentieren und regelmäßig zu kontrollieren. Wer darf überhaupt auf die Knowledge Sources zugreifen? Gelten die Links für alle Nutzer des Agenten, oder erweitert im Hintergrund ein Mechanismus die Rechte? Vor allem bei SharePoint zeigt sich schnell, wie heikel das wird, wenn ein Agent auf Team-Sites zugreifen darf, die eigentlich dem HR-Team vorbehalten sind. Im Zweifel startet man lieber restriktiv und öffnet später gezielt. Mehr zur Berechtigungslogik bei Wissensquellen habe ich im Beitrag Copilot-Studio-Wissensquellen und Berechtigungen im Griff zusammengetragen.

Bei Aktionen und Konnektoren gilt konsequent Least Privilege

Produktiv werden Copilot-Studio-Agenten erst durch Aktionen und Konnektoren. Zugleich steckt in jedem „Stell mal diese Datei ein“, „Ändere diesen Datensatz“ oder „Starte diesen Workflow“ ein mögliches Risiko. In Projekten mit vielen aktivierten Standardkonnektoren führt an einer Least-Privilege-Strategie kein Weg vorbei. Welche Aktionen müssen tatsächlich im Namen der Nutzer laufen, wo genügt Lesezugriff, und was sollte gar nicht automatisiert werden? Auch als Maker hinterlegt man besser keinen „allmächtigen“ Service Principal mit Owner-Rechten. Die neuen Governance-Funktionen für das Model Context Protocol (MCP) erlauben es bereits jetzt, Kontexte und Berechtigungen für Agenten sauber festzulegen. Der Security Scan deckt außerdem gefährliche Überberechtigungen auf, bevor ein Agent veröffentlicht wird.

flowchart TD
  Nutzer["Nutzer greift auf Agent zu"] --> Auth["Authentifizierung (Entra ID)"]
  Auth --> Agent["Copilot Studio Agent"]
  Agent --> Wissen["Zugriff auf Wissenquellen"]
  Agent --> Aktionen["Ausführen von Aktionen/Konnektoren"]
  Aktionen --> Rechte["Prüfung der Berechtigungen (User vs. Maker)"]

Abbildung: Sicherheitsrelevante Abläufe bei Copilot-Studio-Agenten.

Gegen Prompt Injection wie bei EchoLeak helfen Content Moderation und XPIA

Content Moderation ist mittlerweile fest in Copilot Studio eingebaut, wird im Alltag aber häufig unterschätzt. Längst nicht jeder Prompt ist harmlos, und spätestens seit EchoLeak ist Prompt Injection ein reales Problem. Microsoft rollt derzeit das Cross-Product Injection Assessment (XPIA) aus, das gängige Schwachstellen im Dialogverhalten aufspürt. Dessen Ergebnisse sollte man vor dem Go-live trotzdem noch einmal kritisch durchgehen. Auch das EchoLeak-Szenario, in dem Agenten vertrauliche Informationen ausplaudern, ist nicht vom Tisch. Konkrete Beispiele aus der Praxis stehen im Artikel EchoLeak Copilot: Was wir aus CVE-2025-32711 lernen.

Praxis-Tipp: Testet vor der Veröffentlichung sämtliche Dialoge des Agenten mit typischen Angriffsprompts und Rollenspielen. Was passiert, wenn jemand den Agenten auffordert, interne Informationen preiszugeben oder systemfremde Befehle einzuschleusen? Content Moderation und XPIA ersetzen weder saubere Berechtigungen noch den gesunden Menschenverstand.

Security Scan, Audit-Log und klare Ownership gehören vor jede Veröffentlichung

Vor jedem Go-live schaue ich mir inzwischen die Ergebnisse des Security Scans in der Agentenliste an. Copilot Studio zeigt dort den aktuellen Sicherheitsstatus und warnt vor möglichen Schwachstellen oder zu weit gefassten Berechtigungen. Gerade bei Agenten, die Wissensquellen und Aktionen kombinieren, erkennt man so auf einen Blick, wo noch etwas zu tun ist (Dokumentation zum Security Scan). Die Audit-Funktionen sind mittlerweile in Microsoft Purview angekommen. Änderungen am Agenten, Veröffentlichungen und auch Nutzerinteraktionen landen im Audit-Log. Die dafür nötigen Audit-Log-Einstellungen in Purview sollte man allerdings nicht vergessen. Welche Felder im Einzelnen erfasst werden, beschreibt der Logging-Leitfaden (Admin Logging). Gern übersehen wird die Ownership des Agenten. Sie gehört klar dokumentiert und regelmäßig überprüft, sonst fühlt sich im Ernstfall niemand zuständig.

Umgebungen und DLP-Richtlinien bilden das Schutznetz für Agenten

Technisch leben Copilot-Studio-Agenten in einer Power-Platform-Umgebung, und trotzdem kommt die Governance der Umgebungen oft zu kurz. Wer Agenten in die Produktion bringt, sollte eindeutig festlegen, wo sie laufen dürfen, zum Beispiel nur in einer eigenen „Production“-Umgebung mit restriktiven DLP-Richtlinien. Diese Richtlinien verhindern, dass sensible Daten über unsichere Konnektoren abfließen oder den Tenant verlassen. Wie man sie einrichtet und welche Fallstricke dabei typisch sind, habe ich bereits im Beitrag Copilot-Studio-Governance: Risiken und Kontrollen 2024 beschrieben.

Sicherheit in Copilot Studio entsteht aus dem Zusammenspiel von technischen Einstellungen, Rechtekonzept und sinnvollen Kontrollen. Wer eine strukturierte Checkliste abarbeitet, gerät nicht so leicht ins Governance-Chaos und kann seine Agenten mit gutem Gewissen produktiv schalten.