Zero Trust für KI-Agenten, Teil 2: Agenten bauen mit Copilot Studio und Microsoft Foundry

In Teil 1 haben wir gesehen, warum KI-Agenten ein neues Risiko sind. Bevor es um Identitäten und Daten geht, schauen wir uns jetzt die Orte an, an denen Agenten entstehen. Bei Microsoft sind das vor allem zwei Plattformen: Copilot Studio für Fachabteilungen und Power-Platform-Teams, Microsoft Foundry für Entwicklerinnen und Entwickler. Beide bringen eigene Sicherheitsfunktionen mit – allerdings nicht alle davon sind standardmäßig so eingestellt, wie wir es empfehlen würden.

Zwei Plattformen, zwei Zielgruppen

	Copilot Studio	Microsoft Foundry
Wer baut?	Fachabteilungen, Power-Platform-Maker, Low-Code-Teams	Entwicklerteams, Data Scientists
Wie?	Grafisch, mit Wissensquellen, Konnektoren, Abläufen	Mit Code, SDKs, eigenen Modellen und Werkzeugen
Verwaltet in	Power Platform Admin Center	Azure-Portal und Foundry-Portal
Wichtigste Hebel	Umgebungen, Datenrichtlinien, Authentifizierung	Agenten-Identität, RBAC, Leitplanken, Netzwerk
Typisches Risiko	Wildwuchs, öffentliche Agenten, zu breite Konnektoren	Überberechtigte Identitäten, ungeprüfte Werkzeuge

Zusätzlich gibt es den Agent Builder in Microsoft 365 Copilot. Er richtet sich an alle Mitarbeitenden und ist bewusst einfach gehalten. Agenten aus dem Agent Builder lassen sich bei Bedarf nach Copilot Studio übernehmen und unterliegen dann dessen Governance.

Copilot Studio sicher aufstellen

Copilot Studio basiert auf der Power Platform. Deshalb laufen fast alle Sicherheitseinstellungen über Umgebungen und Datenrichtlinien im Power Platform Admin Center. Microsoft empfiehlt dafür eine zonierte Governance: eine klare Trennung zwischen Experimentieren und Produktion.

1. Umgebungen trennen

Jeder neue Maker landet zunächst in der Standardumgebung. Dort sollten keine produktiven Agenten entstehen, denn sie ist für alle zugänglich und schwer zu kontrollieren. Stattdessen empfiehlt Microsoft:

• Umgebungsrouting aktivieren, damit neue Maker automatisch in einer eigenen, abgegrenzten Entwicklungsumgebung landen.
• Für produktive Agenten eine eigene, nicht standardmäßige Produktionsumgebung nutzen.
• Den Zugriff auf Umgebungen über Entra-Sicherheitsgruppen steuern – nur Maker und Admins, die ihn wirklich brauchen.
• Änderungen über einen geprüften Freigabeprozess von Entwicklung über Test nach Produktion bringen, idealerweise mit Pipelines und Git-Integration.

2. Datenrichtlinien setzen

Mit Datenrichtlinien (früher DLP-Richtlinien) legt ihr fest, was Agenten überhaupt dürfen. Sie wirken auf Mandanten- oder Umgebungsebene und steuern unter anderem:

• welche Konnektoren erlaubt, blockiert oder nur getrennt nutzbar sind,
• welche Wissensquellen zulässig sind – etwa SharePoint, hochgeladene Dateien oder öffentliche Webseiten,
• auf welchen Kanälen Agenten veröffentlicht werden dürfen,
• ob HTTP-Anfragen und Trigger für autonome Agenten erlaubt sind,
• ob Agenten ohne Anmeldung nutzbar sein dürfen.

Unser Rat: Blockiert in der Standardumgebung alles, was nicht gebraucht wird, und gebt Konnektoren in Produktionsumgebungen gezielt frei.

3. Authentifizierung erzwingen

Ein Agent ohne Anmeldung ist eine offene Tür: Jeder, der den Link kennt, kann ihn nutzen – mitsamt seinen Wissensquellen und Werkzeugen. Im Power Platform Admin Center könnt ihr deshalb unter Sicherheit > Identität und Zugriff > Authentifizierung für Agenten festlegen, dass Agenten in einer Umgebung Microsoft-Entra-Authentifizierung verlangen. Ist die Einstellung aktiv, werden bereits veröffentlichte Agenten, die nicht passen, blockiert, bis ihre Einstellungen stimmen.

Genauso wichtig ist die Frage, mit wessen Rechten ein Agent auf Konnektoren zugreift. Nutzt er die Anmeldedaten des Makers, kann jeder Benutzer über den Agenten auf das zugreifen, was der Maker sehen darf. Mit der Einstellung Maker-Anmeldedaten steuern erzwingt ihr, dass Werkzeuge mit den Rechten des jeweiligen Benutzers laufen.

4. Eingebaute Schutzfunktionen nutzen

Copilot Studio bringt einiges von Haus aus mit:

• Schutz vor Prompt Injection: Agenten blockieren direkte Angriffe (UPIA) und indirekte Angriffe über Inhalte (XPIA) standardmäßig.
• Sicherheitsprüfung vor der Veröffentlichung: Maker sehen Warnungen, wenn sie sichere Standardeinstellungen verändern, und eine laufend aktualisierte Risikobewertung für Wissensquellen und Werkzeuge.
• Schutzstatus: Auf der Agenten-Seite zeigt eine Spalte, ob ein Agent als Geschützt, Überprüfung erforderlich oder Unbekannt gilt.
• Vertraulichkeitsbezeichnungen: Antworten aus SharePoint-Quellen zeigen die höchste Bezeichnung der verwendeten Dokumente an.
• Protokollierung: Maker-Aktivitäten landen im Purview-Überwachungsprotokoll und lassen sich in Microsoft Sentinel auswerten.

Microsoft Foundry sicher aufstellen

Foundry ist die Entwicklungsplattform für Agenten mit eigenem Code. Hier entstehen oft die mächtigeren Agenten – mit Zugriff auf Datenbanken, Speicherkonten und interne APIs. Entsprechend wichtig sind Identität, Leitplanken und Netzwerk.

1. Agenten-Identitäten bewusst einsetzen

Foundry legt für Agenten automatisch Identitäten in Microsoft Entra an. Dabei gilt ein wichtiges Detail:

• Unveröffentlichte Agenten in einem Projekt teilen sich eine gemeinsame Projekt-Identität. Das ist praktisch beim Entwickeln, hat aber einen größeren Wirkungsradius.
• Veröffentlichte Agenten erhalten eine eigene Identität. Ihre Berechtigungen müsst ihr nach dem Veröffentlichen neu vergeben.

Vergebt Rechte deshalb so eng wie möglich – auf ein Speicherkonto statt auf das ganze Abonnement – und veröffentlicht Agenten mit eigenen Anforderungen, damit sie eine eigene Identität und eigene Protokolle bekommen. Ein weiterer Punkt aus den Empfehlungen von Defender for Cloud: Verbindungen zu Speicherkonten und Datenquellen sollten Entra ID statt Zugriffsschlüsseln nutzen.

2. Leitplanken an allen vier Stellen

Foundry nennt seine Schutzmechanismen Guardrails (Leitplanken). Eine Leitplanke besteht aus Kontrollen, die an bis zu vier Stellen greifen:

1. Benutzereingabe – die Anfrage an den Agenten.
2. Werkzeugaufruf – was der Agent an ein Werkzeug senden will (Vorschau).
3. Werkzeugantwort – was vom Werkzeug zurückkommt (Vorschau). Hier fangt ihr indirekte Prompt Injection ab.
4. Ausgabe – die finale Antwort an den Benutzer.

Wichtig: Wird einem Agenten eine eigene Leitplanke zugewiesen, ersetzt sie die des Modells vollständig. Prüft also, ob eure Agenten-Leitplanke auch alle Kontrollen enthält, die ihr beim Modell gesetzt hattet.

3. Netzwerk und Werkzeuge kontrollieren

• Netzwerkisolation: Foundry-Agenten lassen sich in virtuelle Netzwerke einbinden und mit eigenen Ressourcen betreiben – etwa eigenem Speicher, Azure AI Search und Cosmos DB.
• Ausgehende Verbindungen: Für gehostete Agenten gibt es Regeln für ausgehenden Datenverkehr (Vorschau). Mit „Standardmäßig verweigern“ erreicht ein Agent nur Ziele, die ihr ausdrücklich erlaubt.
• Mensch in der Schleife: Defender for Cloud empfiehlt ausdrücklich, für Aktionen über MCP-Werkzeuge eine Bestätigung durch den Benutzer zu verlangen, wenn ein Agent für indirekte Prompt Injection anfällig ist.
• Werkzeuge prüfen: Bindet nur geprüfte MCP-Server ein und behaltet deren Versionen im Blick.

Die wichtigsten Einstellungen auf einen Blick

Plattform	Einstellung	Warum
Copilot Studio	Umgebungsrouting und eigene Produktionsumgebung	Trennt Experimente von produktiven Agenten
Copilot Studio	Datenrichtlinien für Konnektoren und Wissensquellen	Verhindert ungewollten Datenabfluss
Copilot Studio	Entra-Authentifizierung erzwingen	Keine anonymen Agenten
Copilot Studio	Werkzeuge mit Benutzer-Anmeldedaten	Keine Rechteausweitung über den Maker
Foundry	Eigene Identität für veröffentlichte Agenten, enge RBAC-Rollen	Kleiner Wirkungsradius, eigene Protokolle
Foundry	Leitplanken für Werkzeugaufrufe und -antworten	Schutz vor indirekter Prompt Injection
Foundry	Entra ID statt Schlüsseln, Netzwerkisolation	Keine gestohlenen Schlüssel, kein offener Zugang
Beide	Freigabeprozess und Inventar	Kein Agenten-Wildwuchs

Wie es weitergeht

Beide Plattformen erzeugen Agenten-Identitäten in Microsoft Entra. Diese Identitäten absichern – mit Conditional Access, Risikoerkennung und Governance –, darum geht es in Teil 3.

Offizielle Microsoft-Quellen

• Sicherheit und Governance in Copilot Studio
• Zonierte Governance für Copilot Studio
• Authentifizierung für Agenten konfigurieren
• Agenten-Identitäten in Microsoft Foundry
• Leitplanken in Microsoft Foundry
• Sicherheitsempfehlungen für KI in Defender for Cloud