Copilot‑Studio-Agents mit DLP- und Compliance-Controls absichern

Worin unterscheiden sich Copilot Studio Agents von dem, was wir üblicherweise als „KI“ bezeichnen? Wir sind daran gewöhnt, dass KI in Form eines gesprächigen Assistenten auftritt: eine minimalistische Oberfläche, vertraute Gesprächsmuster, und am Ende jeder Antwort ein kleiner Cliffhanger, der uns bei der Stange hält. 

Copilot Studio Agents können deutlich mehr. Sie können Unternehmensdaten abfragen, abrufen und sogar verändern. Sie lassen sich mit Dataverse, Dynamics 365, Microsoft Graph und Custom APIs integrieren und innerhalb dieser Umgebungen autonom agieren. Damit wächst allerdings auch die Verantwortung. Wenn ein KI-Agent Zugriff auf sensible Daten erhält, entstehen neue Risiken, von unbeabsichtigten Datenlecks bis hin zu gezielten Prompt Injections. Und da es sich hierbei um eine noch junge Technologie handelt, greifen klassische Sicherheitsmodelle nur bedingt. 

In diesem Artikel beleuchten wir reale Risikoszenarien aus der Praxis und zeigen konkrete Maßnahmen, die Sie bereits heute umsetzen können. Außerdem gehen wir auf Compliance-Aspekte und Monitoring-Strategien ein, um sichere und nachvollziehbare KI-Lösungen zu betreiben. Abschließend fassen wir zentrale Design Best Practices zusammen und liefern eine Checklist für die Production Readiness. Los geht’s.  

Highlights

• Reale Risikoszenarien für KI in der Power Platform verstehen
• Starke Identitäten mit Entra ID durchsetzen
• Least‑Privilege-Zugriffe über Umgebungen hinweg anwenden
• Connector Scoping zur Kontrolle der Datenexponierung nutzen
• Power Platform DLP (Data Loss Prevention) als zentrale Guardrails einsetzen
• Compliance-Anforderungen adressieren (DSGVO, Data Residency, Audit Logs)
• Monitoring mit Purview, Sentinel und Defender for Cloud umsetzen
• Sichere, transparente und auditierbare KI-Prozesse schaffen

Risikomanagement und Mitigationsmaßnahmen

Wie bereits erwähnt, sind KI-Technologien im Massenmarkt noch vergleichsweise neu. Unternehmen integrieren sie aktiv in ihre Prozesse und testen, wie sie für ihre jeweiligen Anwendungsfälle am besten funktionieren. Und wie bei jeder neuen, sich schnell entwickelnden Technologie können AI Agents auf unerwartete Weise missbraucht oder falsch konfiguriert werden. Die folgende Übersicht fasst typische Missbrauchsszenarien zusammen, inklusive konkreter präventiver Maßnahmen: 

Alle genannten Mitigations lassen sich bereits heute mit integrierten Features der Power Platform oder Microsoft‑Security‑Tools umsetzen. In den folgenden Abschnitten zeigen wir im Detail, wie diese Maßnahmen implementiert werden, von Identity‑Controls über DLP‑Policies bis hin zu Monitoring.  

1. Identity & Access Control

• Entra‑ID‑Identitäten erzwingen. Copilot Studio Agents laufen unter Identitäten, die in Azure AD (Microsoft Entra ID) verwaltet werden. Dabei handelt es sich um „Non‑Human Identities“, die Microsoft Graph und Konnektoren aufrufen. Diese sollten wie Service Accounts behandelt werden: mit streng kontrollierten Lebenszyklen. Copilot Studio kann z. B. automatisch eine Federated Identity Credential pro Agent erstellen (keine gespeicherten Secrets, kurzlebige Tokens). Stellen Sie sicher, dass nur autorisierte Admins Agents publizieren dürfen, und beschränken Sie tenantweit, wer Agents erstellen und deployen kann. 

• Microsoft‑Authentifizierung erzwingen. Standardmäßig ist bei neuen Agents „Authenticate with Microsoft“ aktiviert. Das bedeutet: Zugriff nur nach Microsoft‑Entra‑ID‑Anmeldung. Maker können dies jedoch auf „No authentication“ ändern, wodurch der Agent öffentlich wird. Um das zu verhindern, erstellen Sie eine Power‑Platform‑Data‑Policy, die den Connector „Chat without Microsoft Entra ID authentication“ blockiert. Ist diese Policy aktiv, muss jeder Agent eine Microsoft‑Anmeldung erzwingen (z. B. über Teams, SharePoint oder Power Apps). 

• Berechtigungen pro Agent prüfen. Braucht der Agent wirklich alle Graph‑Scopes (Mail.Read, User.ReadWrite usw.)? Beschränken Sie diese streng auf das Notwendige. Gleiches gilt für Custom Konnektoren oder API‑Calls: nur die benötigten OAuth‑Scopes hinzufügen. Ein Agent sollte nur das sehen und tun können, was für seine Aufgabe erforderlich ist. Beispiel: Aktualisiert ein Agent ausschließlich Dynamics‑365‑Datensätze, braucht er keinen SharePoint‑Read‑Zugriff. 

• Identity Governance nutzen. Verwenden Sie Entra ID Identity Governance für die Verwaltung dieser Non‑Human Identities. Prüfen Sie App Registrations regelmäßig, rotieren Sie Secrets bzw. Federated Credentials und legen Sie ungenutzte Agents still. Kurz: Vermeiden Sie Non‑Human‑Identity‑Sprawl. Auditieren Sie regelmäßig die von Copilot erstellten Service Principals, entfernen Sie veraltete Tokens und weisen Sie Ownership neu zu, wenn Maker das Unternehmen verlassen. 

Kurzfassung: Behandeln Sie Agents wie Apps. Beschränken Sie, wer sie publizieren darf, erzwingen Sie Azure‑AD‑Sign‑in für Nutzer und halten Sie Berechtigungen so klein wie möglich (Security Roles und Environment Roles).

2. Datenzugriff & Abgrenzung

Nachdem die Identität abgesichert ist, müssen die Datenzugriffe sauber begrenzt werden:

• Dataverse‑Tabellen‑ und Record‑Security. Copilot Agents nutzen häufig Dataverse als Wissens‑ oder Workflow‑Quelle. Dataverse bietet ein feingranulares rollenbasiertes Sicherheitsmodell. Weisen Sie Security Roles zu, um festzulegen, welche Tabellen (Entities) der Agent lesen oder schreiben darf. Benötigt er nur Reports, reicht Read‑Only‑Zugriff. Schreibrechte sollten ausschließlich für konkret benötigte Tabellen vergeben werden. 

• Row‑Level‑Security. Wenn zusätzliche Datensegmentierung nötig ist, nutzen Sie hierarchische oder feldbasierte Security in Dataverse. Beispiel: Der Agent darf nur Datensätze bearbeiten, die einem bestimmten Team gehören. Dazu legen Sie ein Team an, ordnen die Agent‑Identität zu und begrenzen die Rolle auf dieses Team oder eine Business Unit. 

• Environment‑Trennung. Copilot Studio Agents laufen in Power‑Platform‑Environments. Nutzen Sie diese konsequent für Dev, Test und Production. Im Power Platform Admin Center können Sie steuern, wer Environments anlegen darf und welche Daten dort verfügbar sind. So bleibt ein fehlkonfigurierter Agent auf ein nicht‑kritisches Environment beschränkt. 

• Connector‑Scoping. Begrenzen Sie die Nutzung des Dataverse‑Connectors auf bestimmte Tabellen (z. B. über Solutions oder Endpoint Filtering). Nicht‑Microsoft‑Konnektoren (Salesforce, HTTP usw.) erfordern besondere Vorsicht. Neue oder Custom Konnektoren landen standardmäßig in der Gruppe „Non‑business“, die durch DLP blockiert sein kann. Vertrauen Sie einem Connector nur nach bewusster Freigabe („Business“) – andernfalls sperren oder überwachen Sie ihn. 

Kurz gesagt: Ziehen Sie klare Daten‑Grenzen um den Agent. Nutzen Sie Dataverse‑RBAC (Tabellen, Rollen, Business Units), getrennte Environments für Lebenszyklus‑Phasen und restriktives Connector‑Scoping.

3. Connector Governance

Konnektoren sind zugleich das mächtigste und riskanteste Werkzeug eines Agents. Sie definieren externe Aktionen und Datenflüsse und müssen daher strikt geregelt werden: 

• Zertifizierte Konnektoren bevorzugen. Microsoft‑zertifizierte Konnektoren (Graph, Outlook, SharePoint, Dataverse usw.) sind sicherheitsgeprüft. Custom Konnektoren können beliebige APIs ansprechen und benötigen daher erhöhte Aufmerksamkeit. 

• Scopes und Endpoints begrenzen. Selbst innerhalb eines Connectors sollten Sie einschränken. Beispiel SharePoint: Benötigt der Agent nur eine bestimmte Site, whitelisteten Sie ausschließlich diese per Endpoint Filtering. Blockieren Sie breite Konnektoren wie „public websites“ oder „documents“, sofern sie nicht zwingend erforderlich sind. 

• Keine „God‑Mode“-Konnektoren. Der Agent sollte nicht als Universal‑Proxy für beliebige Systeme fungieren. Stattdessen nur klar definierte Aktionen freigeben, etwa „Create record in X“ oder „Send email via Graph“. Beispiel: Muss der Agent nur Datensätze anlegen, darf er keine Dataverse Solutions erstellen oder löschen. 

Grundregel: Jeder Connector, der Daten außerhalb des Tenants senden kann (public web, externe APIs), gilt zunächst als nicht vertrauenswürdig. Power‑Platform‑DLP‑Policies helfen, diese Regeln tenantweit über Agents und Flows durchzusetzen.

4. Data Loss Prevention (DLP)

Data Policies in der Power Platform sind Ihre zentralen AI‑Guardrails. Sie verhindern, dass Daten an unautorisierte Konnektoren fließen oder Organisationsgrenzen überschreiten. Copilot Studio setzt diese Policies in Echtzeit durch: Greift ein Agent auf einen gesperrten Connector zu, schlägt die Aktion fehl. Zentrale Schritte für ein sicheres Setup:

• Connector‑Gruppen definieren. Im Power Platform Admin Center unter Security → Data policies ordnen Sie jeden Connector (inkl. Copilot‑Konnektoren) einer Kategorie zu: Business, Non‑business oder Blocked. Beispiel: SharePoint, Dynamics, Teams → Business; generisches HTTP oder „public websites“ → Non‑business oder Blocked. Regel: Konnektoren aus unterschiedlichen Gruppen dürfen keine Daten austauschen. 

• Non‑business standardmäßig blockieren. Viele Tenants blockieren alle Non‑business‑Konnektoren automatisch. Neue oder unbekannte Konnektoren sind damit zunächst gesperrt, bis ein Admin sie explizit freigibt. Copilot Studio respektiert diese Einstellung vollständig. 

• Authentifizierung per DLP erzwingen. Blockieren Sie den Connector „Chat without Microsoft Entra ID authentication“. Ebenso lassen sich ChatGPT‑ oder andere unregulierte Kanäle sperren. 

• Cross‑Tenant‑Flows verhindern. Nutzen Sie DLP, um Datenflüsse zwischen Environments oder Tenants zu unterbinden. Beispiel: Interner Dataverse‑Zugriff darf keine Daten an externe REST‑APIs weitergeben. 

• Business‑/Non‑business‑Isolation beachten. Business‑Konnektoren dürfen nur mit anderen Business‑Konnektoren kombiniert werden. Beispiel: Teams und Graph → beide Business. Ein externer Salesforce‑Connector in Non‑business kann nicht mit Dataverse kombiniert werden. 

Fazit: DLP ist kein „Nice‑to‑have“, sondern Pflicht. Es verhindert versehentliche oder absichtliche Datenexfiltration und stellt sicher, dass Copilot Agents keine Daten aus kritischen Systemen an nicht genehmigte Ziele weitergeben.

5. Compliance- und regulatorische Aspekte

AI Agents entbinden nicht von GDPR, HIPAA oder ähnlichen Regeln – sie erweitern vielmehr die Datenverarbeitung. Microsoft unterstützt Compliance für Copilot Agents, die Verantwortung für die korrekte Konfiguration liegt jedoch bei Ihnen:

• DSGVO & Betroffenenrechte. Copilot Studio ist DSGVO‑konform ausgelegt: Daten können regional begrenzt werden, Betroffenenanfragen lassen sich umsetzen. Verarbeitet ein Agent personenbezogene Daten, gelten auch Chatverläufe als personenbezogene Daten. Stellen Sie sicher, dass Logs und Transkripte auf Anfrage gelöscht werden können, und führen Sie DPIAs für risikoreiche Agents durch. 

• Data Residency. Sie wählen die Azure‑Region für Ihre Tenant‑Daten. Für EU‑Kunden stellt die EU Data Boundary sicher, dass Daten in EU/EFTA‑Regionen bleiben. Cross‑Region‑Moves können bei Bedarf deaktiviert werden. 

• Regionale Durchsetzung. Microsoft bietet einen Schalter, um Datenbewegungen über geografische Regionen hinweg für generative Copilot‑Features zu unterbinden. Wenn Ihre Compliance‑Vorgaben vorschreiben, dass Daten Europa nicht verlassen dürfen, sollte diese Option aktiviert werden. 

• Sensitivity Labels & Purview‑Klassifizierung. Nutzen Sie Microsoft Purview DLP oder Information Protection, lassen sich diese Labels auch auf Copilot anwenden. Beispiel: Nutzt ein Agent SharePoint‑Quellen, können die dort gesetzten Sensitivity Labels steuern, welche Inhalte der Agent ausgeben darf. 

• Allgemeine Compliance. Copilot Studio erfüllt zahlreiche Standards (ISO, SOC usw.), analog zur restlichen Power Platform. Prüfen Sie hierzu das Microsoft Trust Center. Wichtig: Compliance wird nicht „mitgeliefert“. Sie entsteht durch korrekte Konfiguration. 

6. Monitoring, Auditing & Observability

Was man nicht sieht, kann man nicht absichern. Bauen Sie daher eine Observability‑Schicht für Ihre Agents auf:

• Audit Logs (Purview). Copilot Studio protokolliert Admin‑ und User‑Aktionen in Microsoft Purview: Veröffentlichung von Agents, Permission‑Änderungen, User‑Interaktionen. Überprüfen Sie diese Logs regelmäßig, richten Sie Alerts ein oder exportieren Sie sie in ein SIEM. Kritische Events sind u. a. Agent‑Erstellung/-Löschung, Permission Changes und auffällige Nutzungsmuster. 

• Integration mit Microsoft Sentinel. Microsoft empfiehlt, Copilot‑Audit‑Logs nach Sentinel zu streamen. Dort lassen sich Analytics Rules definieren, z. B. „Agent wurde außerhalb eines Change Windows publiziert“ oder „ungewöhnlich viele Datensätze pro Tag durch einen Agent“. 

• Purview DSPM (Data Security Posture Management). Für tiefere Chat‑Analysen kann Purview DSPM for AI Gesprächsverläufe rekonstruieren und Policy‑Verletzungen identifizieren (z. B. sensible Inhalte). 

• Datenzugriffe protokollieren. Loggen Sie möglichst genau, welche Daten ein Agent abgefragt oder verändert hat. Praktisch bedeutet das: Aktivieren Sie Power‑Platform‑Logging für Konnektoren (z. B. Application Insights) und Auditing. 

• Retention & Privacy. Logging muss mit Datenschutz in Balance stehen. Löschen Sie Chat‑Transkripte, wenn sie nicht mehr benötigt werden. Nutzen Sie Retention Labels oder Policies in Purview und dokumentieren Sie Ihre Aufbewahrungsregeln für Audits. 

Zusammenfassung: Sammeln Sie Logs auf allen Ebenen und führen Sie sie in Ihr zentrales Monitoring. Erst diese Transparenz macht Agent‑Actions zu einem auditierbaren Governance‑Artefakt.

Best Practices für das Design sicherer Agents 

Neben Infrastruktur‑Controls sollten Sie Ihre Agents von Anfang an mit Security im Blick entwerfen. Die folgenden kompakten Do’s und Don’ts helfen dabei:

Alle genannten Mitigations lassen sich bereits heute mit Bordmitteln der Power Platform oder Microsoft‑Security‑Tools umsetzen. In den folgenden Abschnitten zeigen wir im Detail, wie das funktioniert, von Identity‑Controls über DLP‑Policies bis hin zu Monitoring. 

Nutzen Sie folgende Design‑Checklist für Production Readiness:

• Identity: Agent‑Identität ist in Azure AD (Microsoft Entra ID) registriert, die Credentials geprüft (keine hardcodierten Secrets) 
• Authentication 
  • User‑Sign‑in über Entra ID erforderlich 
  • „NoAuth“ per Policy blockiert 
• Permissions 
  • Azure‑AD‑Rollen und Dataverse‑Rollen des Agents sind zweckgebunden begrenzt 
  • Permissions wurden vom Security‑Team geprüft 
• Environment 
  • Agent ist im richtigen Environment deployt 
• Data Policies 
  • Passende DLP‑Policies zugewiesen 
  • Konnektoren klassifiziert und bei Bedarf blockiert 
• Security Scan 
  • In Copilot Studio integrierter Security Scan genutzt 
  • Hinweise auf riskante Konfigurationen regelmäßig behoben 
• Logging 
  • Purview Audit Logging aktiviert 
  • Logs werden an das Security‑Monitoring exportiert 
  • Application Insights aktiviert 
• Approval 
  • Finale Freigabe durch IT‑ und Security‑Teams 
  • Dokumentierte Liste der Datenquellen und des beabsichtigten Einsatzzwecks 

Fazit

Benötigt Ihre Organisation Unterstützung dabei, Copilot Agents sicher und kontrolliert einzusetzen? proMX verfügt über erfahrene Microsoft‑Spezialisten und MVPs, die Ihr Setup prüfen, Security‑ und DLP‑Policies definieren und AI‑Projekte mit Ihren Compliance‑Vorgaben in Einklang bringen. Gemeinsam helfen wir Ihnen dabei, autonome Agents von einem Risiko zu einem verlässlichen Bestandteil Ihrer Enterprise‑IT zu machen.