In den letzten Wochen habe ich viel mit Agents in Microsoft Copilot Studio gearbeitet. Seit das Model Context Protocol (MCP) integriert ist, hat die Auswahl an externen Tools enorm zugenommen. Agents sprechen jetzt nicht mehr nur Power-Platform-Connectoren an, sondern beliebige Ressourcen, die ein MCP-Server erschließt. Das kann eine interne Service-API sein, eine Datenbank oder ein Drittanbieter-Tool, das das Model Context Protocol implementiert. Wer für Governance und Sicherheit zuständig ist, muss hier zwischen Innovation und Kontrolle abwägen. In vielen Tenants, die ich zu sehen bekomme, fehlt dafür noch ein klarer Fahrplan.

MCP öffnet Copilot-Studio-Agents den Weg zu vielen externen Tools

Über MCP erreicht ein Agent schnell eine wachsende Zahl von Tools, ohne dass für jede Integration eine eigene Schnittstelle entstehen muss. Wichtig dabei: Copilot Studio bindet MCP-Server als benutzerdefinierte Konnektoren ein. Damit gilt das bestehende DLP- und Zugriffsmodell der Power Platform für alle Ressourcen, die darüber erreichbar sind – zumindest auf dem Papier. In der Praxis hat das zwei Seiten. Zum einen lassen sich Governance-Mechanismen nutzen, die sich bei klassischen Low-Code-Anwendungen längst bewährt haben. Zum anderen bringen KI-gesteuerte Agents ihre eigenen Risiken mit, vor allem weil sie externe Tools dynamisch einsetzen.

Das Diagramm zeigt, wie ein Copilot-Studio-Agent ein MCP-Tool aufruft und an welchen Stellen die Governance ansetzt:

flowchart TD
    User["User"] --> Agent["Copilot Studio Agent"]
    Agent --> Connector["MCP Connector"]
    Connector --> MCPServer["MCP Server"]
    MCPServer --> Tool["Externes Tool/API"]
    Connector -->|"DLP-Richtlinien"| Governance["Power Platform Governance"]

Abbildung: Ein Copilot-Studio-Agent ruft ein MCP-Tool auf, die Governance-Kontrolle greift am Connector.

Weil ein Agent beliebige Tools flexibel kombinieren kann, muss genau geregelt sein, welche Aktionen an welcher Stelle erlaubt sind. Das gilt für den Agent und ebenso für den MCP-Server selbst.

Der Custom Connector bindet MCP-Server an DLP-Richtlinien und Authentifizierung

Den größten Hebel für die Governance bietet nach wie vor die Einbindung des MCP-Servers als Custom Connector. Sobald ein Agent einen solchen Connector nutzt, gelten nämlich die DLP-Richtlinien (Data Loss Prevention) der jeweiligen Umgebung. In mehreren Umgebungen habe ich gesehen, wie wichtig es ist, DLP vorher durchdacht aufzusetzen. Andernfalls kombiniert ein Agent womöglich Tools, die auf sensible und weniger sensible Daten zugreifen, munter miteinander. Abhilfe schaffen die bekannten DLP-Policies der Power Platform, die ich im Beitrag Copilot Studio DLP: Agenten und Datenflüsse im Griff beschrieben habe.

Als Zweites kommt die Authentifizierung ins Spiel. Je nach Implementierung unterstützt ein MCP-Server unterschiedliche Verfahren, etwa OAuth2 mit Benutzerkontext, Application Permissions oder einen API-Key. Für die Governance muss feststehen, wie fein sich die Zugriffe steuern lassen und ob der Server jede Aktion sauber protokolliert. Bevor ein MCP-Server produktiv geht, sollte man ihn deshalb gründlich prüfen. Unterstützt er das Prinzip der geringsten Rechte (Least Privilege)? Protokolliert er alle Aktionen nachvollziehbar? Und lässt sich jede Anfrage eindeutig einem Agent und einem Benutzer zuordnen?

MCP bringt Risiken wie Tool Poisoning und Prompt Injection mit

Bei aller Leistungsfähigkeit schafft MCP auch neue Angriffsflächen. Ein bekanntes Szenario ist „Tool Poisoning“. Ist ein angebundenes Tool oder seine API kompromittiert oder liefert sie falsche Daten, zieht der Agent daraus womöglich falsche Schlüsse oder führt sogar schädliche Aktionen aus. Ebenso bleibt „Prompt Injection“ ein Thema, wenn ein Tool gezielt manipulierte Antworten zurückgibt, die der Agent weiterverarbeitet. Heikel wird es vor allem bei Tools mit weitreichenden oder administrativen Befugnissen, die zum Beispiel Datenbanken löschen, E-Mails versenden oder Berechtigungen ändern können.

Bevor Sie einen MCP-Server einbinden, sollten Sie daher unbedingt Folgendes klären:

  • Welche Tools und Aktionen stellt der Server tatsächlich bereit?
  • Wie sind Authentifizierung und Autorisierung technisch gelöst?
  • Lassen sich alle Requests umfassend protokollieren?
  • Wie sind Monitoring und Alerting für auffällige Zugriffe organisiert?
  • Werden DLP-Policies und die Trennung der Environments konsequent eingehalten?

Mein Tipp aus der Praxis: Binden Sie MCP-Server immer zuerst in einer eigenen, restriktiven Umgebung ein und testen Sie sie dort mit einem eigenen DLP-Policy-Set. Erst danach geht es in die produktiven Umgebungen.

Ohne saubere Trennung von Entwicklungs-, Test- und Produktivumgebung landen versehentlich freigegebene Tools schnell im Echtbetrieb.

Getrennte Umgebungen und lückenloses Logging gehören vor jede Freigabe

In Copilot Studio bleibt die Trennung der Umgebungen (Environments) das wichtigste Mittel zur Isolation. Häufig beobachte ich, dass Agents samt ihren Konnektoren zu früh in produktive Umgebungen wandern, ohne die Governance-Prüfungen durchlaufen zu haben. Besser ist es, einen neuen MCP-Server zunächst in einer eigenen Umgebung mit restriktiven DLP-Policies in Betrieb zu nehmen. Die Logs gehen dabei zentral an einen SIEM-Dienst wie Microsoft Sentinel, und anfangs dürfen nur ausgewählte Agents den Server nutzen.

Admins sollten die verbundenen Custom Connectors und die zugehörigen Agents regelmäßig kontrollieren. In der Ansicht „Agents“ im Copilot Studio Admin Center sehen Sie auf einen Blick, welcher Agent welchen Connector verwendet. Mehr dazu steht in meinem Beitrag Copilot Agents verwalten: Kontrolle, Freigaben, Kosten.

Praktisch ist außerdem, dass sich über das Power Platform Admin Center Audit- und Nutzungslogs exportieren lassen. Missbrauch und Fehlkonfigurationen fallen so schneller auf. Bewährt hat sich bei mir dieser Ablauf:

  1. MCP-Server als Custom Connector anlegen
  2. DLP-Policy für Connector und Umgebung prüfen und bei Bedarf anpassen
  3. Authentifizierung kontrollieren (OAuth, App-Token usw.)
  4. Logging testen (SIEM-Anbindung, Audit-Logs, Fehlermeldungen)
  5. Erst danach Agents mit dem Connector produktiv schalten

MCP ist ein Governance-Auftrag und kein Selbstläufer

Seit MCP in Copilot Studio allgemein verfügbar (GA) ist, können viele Unternehmen wirklich leistungsfähige KI-Agents bauen, die dynamisch agieren. Damit wachsen allerdings auch die Risiken. Governance beschränkt sich nicht mehr auf das Design des Agents, sie betrifft jedes angebundene Tool und jeden Konnektor. Das Rückgrat für einen sicheren Betrieb bilden vor allem DLP-Richtlinien und Environment-Trennung. Wer offene Baustellen aus der Power-Platform-Governance übergeht, muss mit Wildwuchs und Kontrollverlust rechnen. MCP muss keine Black Box bleiben, vorausgesetzt, man setzt jetzt die passenden Leitplanken.