Wer eigene Copilot-Studio-Agenten entwickelt, kennt das: Die eigentliche Arbeit fängt erst nach dem Bauen an, nämlich beim Testen. Gerade in produktiven Umgebungen erlebe ich immer wieder, dass Agenten zu früh veröffentlicht werden. Ihre Antworten passen dann nicht zum Unternehmenskontext oder geben sogar Informationen preis, die niemand herausgeben wollte. Bevor ein Agent bei den Nutzern landet, braucht es deshalb einen soliden Testprozess. Das gilt umso mehr, wenn sensible Datenquellen oder Schnittstellen für Actions angebunden sind.

Im integrierten Testbereich beginnt die Prüfung jedes Agenten

Zum Glück bringt Copilot Studio von Anfang an mehrere Werkzeuge mit, um Agenten gründlich zu prüfen. Ausgangspunkt ist der integrierte Testbereich, der im Authoring-Canvas jederzeit gut sichtbar bleibt. Dort lässt sich Schritt für Schritt nachvollziehen, wie der Agent auf typische Anwenderfragen reagiert. Mir ist dabei wichtig, nicht bei Standardfragen stehen zu bleiben, sondern gezielt Grenzfälle und „böswillige“ Prompts auszuprobieren. Wie reagiert der Agent, wenn jemand einen Jailbreak versucht oder ausdrücklich nach vertraulichen Informationen fragt? Ich lege mir dafür eine eigene Liste mit adversarialen Testfragen an und gehe sie nach jedem Update erneut durch. Auf diese Weise fallen Schwächen beim Prompt Grounding, beim Umgang mit Berechtigungen oder beim Zugriff auf Wissensquellen auf.

Mein Tipp: Testet nicht nur mit eurer eigenen Identität als Ersteller, sondern unbedingt auch mit verschiedenen Nutzerkonten, die unterschiedliche Berechtigungen haben. Erst dann sieht man, ob die Zugriffssteuerung sauber greift oder ob der Agent zu viel verrät.

Sehr wertvoll ist übrigens die Activity Map, die sich im Testbereich einblenden lässt. Sie zeigt, welche Wissensquellen und Actions der Agent jeweils anspricht. Bei komplexeren Agenten entdeckt man damit unerwartete Datenzugriffe oder fehlerhafte Tool-Aufrufe in kürzester Zeit.

flowchart TD
    A["Testfrage stellen"] --> B["Agent verarbeitet Prompt"]
    B --> C["Zugriff auf Wissensquelle"]
    B --> D["Aufruf einer Action"]
    C --> E["Antwort generieren"]
    D --> E
    E --> F["Antwort prüfen"]

Abbildung: So läuft der Test eines Copilot-Studio-Agenten ab, von der Frage bis zur Prüfung der Antwort.

Die Testfragen gehören in drei Kategorien

In der Praxis kommt es darauf an, dass die eigenen Testfälle über Standarddialoge hinausgehen. Bewährt hat sich bei mir, Testfragen in drei Kategorien zu sammeln:

  • Out-of-Scope: Fragen, die bewusst außerhalb des vorgesehenen Wissensbereichs liegen
  • Jailbreak-Versuche: manipulative oder trickreiche Prompts, die Sicherheitsmechanismen aushebeln sollen
  • Vertrauliche Daten: Fragen nach sensiblen oder besonders geschützten Inhalten

Bei Out-of-Scope-Fragen muss der Agent klar und nachvollziehbar ablehnen, statt sich etwas auszudenken oder „halluzinierte“ Antworten zu liefern. Jailbreak-Prompts legen Schwächen in den System-Prompts oder bei der Tool-Integration offen. Und wer gezielt nach vertraulichen Daten fragt, merkt schnell, ob Labels und Berechtigungen durchgängig wirken. Wer noch einen Schritt weitergehen will, prüft außerdem, ob der Agent bei Anfragen auf Daten zugreift, die er eigentlich gar nicht kennt, etwa weil sie (noch) nicht in der Wissensquelle liegen. Bei SharePoint oder eigenen Custom Actions ist das besonders relevant.

Worauf es bei der Prüfung vor dem Produktivgang ankommt, habe ich in meinem Sicherheits-Check für Agenten zusammengestellt.

Jede Antwort muss sich auf eine Wissensquelle zurückführen lassen

Die Antworten des Agenten vergleiche ich gern direkt mit den Wissensquellen, auf denen sie beruhen. Lässt sich jede Aussage nachverfolgen? Greift der Agent wirklich nur auf freigegebene Daten zu? Auch hier hilft die Activity Map, denn sie macht sichtbar, ob versehentlich falsche oder zu weit gefasste Quellen abgefragt werden. Mit einem separaten Testkonto, das nur minimale Rechte hat, erkennt man sehr schnell, ob die Sicherheitslogik im Agenten und in Copilot Studio lückenlos umgesetzt ist.

Eine solide Grundlage dafür bietet die Dokumentation zum Testen und Debuggen in Copilot Studio. Meine Erfahrung zeigt allerdings, dass nichts das Durchspielen echter und auch ungewöhnlicher Dialoge ersetzt.

Nach der Veröffentlichung liefern Analytics und Feedback die wichtigsten Hinweise

Mit dem Go-Live ist das Testen nicht abgeschlossen. Im Menü von Copilot Studio gibt es unter „Analytics“ eine eigene Auswertung zum Verhalten des Agenten. Dort erkenne ich auf einen Blick, welche Prompts häufig vorkommen, wie oft der Agent Wissensquellen oder Actions genutzt hat und ob sich Fehlermuster abzeichnen. Wer Copilot Studio mit „Copilot credits“ produktiv einsetzt, bekommt dort zugleich einen Überblick über die tatsächliche Nutzung (siehe Analytics-Übersicht).

Auf die Feedbackschleife möchte ich nicht verzichten. Wer die Analytics regelmäßig auswertet und daraus gezielte Verbesserungen ableitet, steigert die Qualität des Agenten. Gleichzeitig erspart man sich unangenehme Überraschungen nach einem Update oder einer Änderung an den Wissensquellen.

Nur echte Tests bringen die echten Schwächen ans Licht

In vielen Tenants, die ich begleite, sehe ich immer wieder dasselbe: Ob ein Copilot-Studio-Agent bloß ordentlich funktioniert oder tatsächlich sicher und verlässlich ist, entscheidet sich beim Testen. Wer sich auf Standarddialoge verlässt, muss damit rechnen, dass es spätestens im Produktivbetrieb Probleme gibt, von halluzinierten Antworten bis hin zu Datenlecks. Für alle, die Copilot-Studio-Agenten 2026 sicher betreiben wollen, führt deshalb kein Weg an einem strukturierten, wiederholbaren Testprozess vorbei, der gezielte adversariale Fragen mit kontinuierlichem Feedback aus den Analytics verbindet.