Microsofts Copilot Studio Hooks laufen jedes Mal, werden aber bei einem Fehler still übersprungen── Regeln in Anweisungen hängen vom Urteilsvermögen des Agenten ab; Hooks feuern jedes Mal, werden aber durchgelassen, wenn sie fehlschlagen, sodass Handlungen, die nicht passieren dürfen, hinter Berechtigungen gehören

Am 6. Oktober 2026 wurde berichtet, dass Microsoft den in Copilot Studio erstellten KI-Agenten "Hooks" hinzugefügt hat. Ein Hook ruft jedes Mal einen ausgewählten Workflow auf, wenn ein definiertes Ereignis eintritt, etwa der Beginn einer Konversation oder ein Tool-Aufruf; die Funktion ist in der Vorschau verfügbar. Wenn man eine Unternehmensregel in die Anweisungen eines KI-Agenten schreibt, befolgt der Agent sie jedes Mal? Nicht unbedingt. Dass eine Regel jedes Mal ausgeführt wird, erfordert einen externen Mechanismus wie Hooks, und eine Aktion auch dann zu stoppen, wenn ein Hook fehlschlägt, erfordert Berechtigungen auf dem System, mit dem sich der Agent verbindet.

01Anweisungen hängen vom Ermessen des Agenten ab; Regeln, die bei jeder Ausführung gelten, erfordern Hooks und Berechtigungen

Microsofts Dokumentation zieht die Grenze zwischen Tools und Hooks in einer einzigen Tabelle. Ein Tool läuft nur, wenn der Agent es für das Gespräch für relevant hält. Ein Hook läuft jedes Mal, wenn sein Ereignis eintritt, ganz gleich, was der Agent davon hält.

Eine in die Anweisungen geschriebene Regel wird auch vom Agenten selbst gelesen und angewendet. Ich lese das so: Sie steht auf der Werkzeug-Seite des Tisches – sie greift erst, nachdem sie das Urteilsvermögen des Agenten durchlaufen hat, nicht davor.

Das unterteilt die Orte, an denen eine Unternehmensregel bestehen kann, in drei. Da sind die Anweisungen, da sind die Hooks, und da sind die Berechtigungen auf den Systemen, mit denen sich der Agent verbindet. Regeln, die jedes Mal gelten müssen, etwa das Anlegen einer Aufzeichnung oder das Prüfen einer Freigabe, sollten aus den Anweisungen heraus und in Hooks verlagert werden. Aktionen, die niemals geschehen dürfen, etwa das Senden einer bestimmten E-Mail oder das Löschen eines Datensatzes, sollten zusätzlich durch Berechtigungen blockiert werden. Ein Hook, der fehlschlägt, wird übersprungen; ein Hook allein reicht also nicht aus.

02Hooks rufen bei sechs Arten von Ereignissen einen Workflow auf, und die Antwort verändert den nächsten Schritt des Agenten

Laut der Dokumentation besteht jeder Hook aus zwei Teilen: einem Ereignis und einer Aktion. Das Ereignis ist der Punkt im Lauf des Agents, auf den der Hook hört. Die Aktion ist das, was an diesem Punkt ausgeführt wird – im Moment ist das immer ein Workflow, eine Abfolge von Schritten, die mit Microsofts Automatisierungstools erstellt wurde.

Es gibt sechs Ereignisse. Eine Sitzung startet. Der Benutzer sendet eine Nachricht. Ein Tool wird in Kürze ausgeführt. Ein Tool ist abgeschlossen. Ein Tool ist fehlgeschlagen. Ein Fehler ist außerhalb eines Toolaufrufs aufgetreten. Wenn eines davon ausgelöst wird, ruft Copilot Studio den gebundenen Workflow auf, übergibt ihm die Details des soeben Geschehenen und liest die Antwort des Workflows zurück in die Unterhaltung.

Jedes Ereignis übergibt dem Workflow dieselben drei Eingaben: den Ereignisnamen, einen Zeitstempel und ein Metadaten-Objekt. Die Metadaten enthalten die Konversations-ID, die ID und den Anzeigenamen des Benutzers, den Kanal und den Namen des Agenten. Die Dokumentation führt als Beispiel das Schreiben eines Audit-Eintrags an, der sowohl den Benutzer als auch den Agenten identifiziert.

Auch die Grenzen sind wichtig. Die Seite beginnt damit, sich selbst als Vorab-Dokumentation zu bezeichnen, die sich noch ändern kann. Die Funktion gilt für Agenten und Workflows, die von dem angetrieben werden, was Microsoft den GitHub Copilot harness nennt, die zugrunde liegende Schicht, die den Agenten ausführt. Das Erstellen, Testen und Verwenden solcher Agenten wird nach Nutzung abgerechnet und kann Copilot Credits verbrauchen.

03Für elektronische Aufzeichnungen in der Pharmabranche verlangt eine US-Regel von 1997 bereits systemseitig erzwungene Protokolle und Reihenfolge

Die Dokumentation nennt vier Verwendungszwecke für Hooks. Kontext zu Beginn einer Sitzung hinzufügen, etwa die Nutzerregion oder offene Fälle. Einen Tool-Aufruf vor der Ausführung prüfen und blockieren, wenn er eine Geschäftsregel verletzt. Sensible Werte aus dem Ergebnis eines Tools schwärzen oder nach der Ausführung einen Audit-Eintrag schreiben. Entscheiden, ob bei einem Fehlschlag wiederholt, übersprungen oder abgebrochen wird.

Zwei dieser Verwendungen – die Aufzeichnung jedes Vorgangs und das Blockieren außer der Reihe ausgeführter Schritte – werden in mindestens einem regulierten Bereich seit Langem von Systemen verlangt, nicht von menschlicher Aufmerksamkeit: elektronische Aufzeichnungen in der Pharmaindustrie. Die US-Regel 21 CFR Part 11 regelt elektronische Aufzeichnungen und elektronische Signaturen und wurde 1997 veröffentlicht. Ihr Abschnitt 11.10 legt Kontrollen für alle fest, die Aufzeichnungen in einem geschlossenen System aufbewahren.

Die beiden Spalten beschreiben dieselben Tätigkeiten in der Sprache unterschiedlicher Jahrzehnte. Ich habe nicht geklärt, ob Part 11 auf KI-Agents als solche anwendbar ist, und dieser Essay behauptet das auch nicht. Der engere Punkt ist dieser: Die Vorstellung, dass die Aufzeichnung jedes Vorgangs und eine erzwungene Reihenfolge nicht davon abhängen dürfen, dass sich jemand daran erinnert, ist seit 1997 in der Regulierung der Pharmaindustrie verankert.

Der Einsatzbereich ist nicht auf die Medizin beschränkt. Microsofts eigene Beispiele sind ein Service Desk, der dem Agenten zu Beginn eines Chats die offenen Fälle eines Kunden übergibt, und ein interner Assistent, der sensible Werte in seinen Antworten maskiert. Beides sind Wege, etwas zuverlässig geschehen zu lassen, woran ein sorgfältiger Mitarbeiter sich normalerweise, aber nicht immer, erinnern würde.

04Ob ein Tool ausgeführt wird, entscheidet der Agent von Gespräch zu Gespräch anhand seines Namens und seiner Beschreibung

Part 11 wollte die Aufzeichnungsführung nicht der menschlichen Aufmerksamkeit überlassen. Bei einem KI-Agenten entscheidet eine Komponente, die Microsoft den Orchestrator nennt, ob ein Tool ausgeführt wird. Die Tools-Dokumentation von Copilot Studio besagt, dass der Orchestrator jede Benutzernachricht auswertet und entscheidet, ob ein Tool benötigt wird. Als Beweisgrundlage dienen ihm der Name und die Beschreibung des Tools, die die Dokumentation als kritisch bezeichnet.

Wenn man einen Aufzeichnungs-Workflow als Tool einsetzt, entscheidet der Orchestrator also auch, ob der Datensatz aufgezeichnet wird. Je nachdem, wie das Gespräch verläuft und wie die Beschreibung formuliert ist, gibt es Runden, in denen er aufgerufen wird, und Runden, in denen nicht. Bindet man denselben Workflow an einen Hook, wandert die Entscheidung über seine Ausführung vom Agenten zum Ereignis.

Es wurde gemessen, dass das Verteilen einer Aufgabe über viele Runden die Qualität der Modellausgabe selbst senkt. Im Jahr 2025 verglichen Laban und Kollegen führende offene und geschlossene große Sprachmodelle bei Aufgaben, die entweder auf einmal oder über viele Runden verteilt gestellt wurden. Jedes getestete Modell schnitt in Mehr-Runden-Gesprächen deutlich schlechter ab, mit einem durchschnittlichen Rückgang von 39% über sechs Generierungsaufgaben hinweg.

Diese 39% sind keine Quote verpasster Toolaufrufe. Sie misst, um wie viel die Qualität der generierten Ausgaben bei Schreib- und Programmieraufgaben gesunken ist. Trotzdem zeigt sie, dass das Modellverhalten instabiler wird, je länger eine Konversation dauert. Ein Design, das darauf angewiesen ist, dass der Agent sich die Regel jedes Mal merkt, akzeptiert diese Instabilität, ohne dass der Nutzer geprüft hat, ob sie bis zu den Toolaufrufen durchschlägt.

05Nur das Pre-Tool-Ereignis kann eine Aktion blockieren, und ein fehlgeschlagener Hook wird einfach übersprungen

Hooks laufen nicht durch das Urteilsvermögen des Agenten. Dennoch nennt Microsofts Dokumentation zwei Grenzen ganz klar.

Das Erste ist, dass nur ein einziges Ereignis die Macht hat, irgendetwas zu stoppen. Ein Hook am Pre-Tool-Ereignis kann deny zurückgeben und den Aufruf blockieren. Die Dokumentation besagt, dass dies das einzige Ereignis ist, das eine Aktion blockieren kann. Die anderen fünf können Kontext hinzufügen oder Werte ändern, können den Agenten aber nicht stoppen.

Die zweite Grenze betrifft das, was passiert, wenn der Hook selbst fehlschlägt. Schlägt der Workflow fehl oder läuft er in ein Timeout, macht der Agent weiter, als hätte der Hook nichts zurückgegeben. Dasselbe gilt, wenn der Workflow etwas zurückgibt, das der Agent nicht lesen kann. Ein fehlgeschlagener Pre-Tool-Hook lässt daher genau den Aufruf durch, den er stoppen sollte.

Die Dokumentation warnt die Leserschaft davor, sich bei einer geschäftskritischen Regel allein auf einen Hook zu verlassen. Microsoft selbst stellt Hooks nicht als einzige Absicherung für eine Regel dar.

Es gibt auch einen Ablaufpunkt, der leicht übersehen wird. Ein Workflow, der gespeichert, aber nicht veröffentlicht wurde, läuft nicht. Ein Hook, der zu einem Agenten hinzugefügt wurde, wirkt für Benutzer nicht, bevor der Agent gespeichert und veröffentlicht wurde. Zu sehen, dass ein Hook im Testbereich funktioniert, und zu sehen, dass er in Live-Unterhaltungen funktioniert, sind zwei getrennte Prüfungen.

06Immer greifende Regeln außerhalb des Ermessens des Agenten ansiedeln, blockierende Regeln in den Berechtigungen verankern und die Eingaben prüfen, die Hooks erhalten

Nur das Pre-Tool-Ereignis kann blockieren, und ein fehlgeschlagener Hook wird übersprungen. Zusammen genommen bedeuten diese beiden Fakten, dass jede Regel bewusst platziert werden muss, statt sie einmal niederzuschreiben und ihr zu vertrauen.

Wenn eine Dokumentationspflicht in den Anweisungen verankert ist, kann es Turns geben, in denen die Aufzeichnung fehlt. Tools laufen nur, wenn der Agent sie für relevant hält, und laut Messungen senken lange Konversationen die Aufgabenleistung im Durchschnitt um 39%. Diese 39% sind keine Quote verpasster Aufrufe, zeigen aber, dass die Teile, die dem Urteil des Modells überlassen bleiben, von unterschiedlicher Qualität sind. Alles, dessen Fehlen schaden würde, gehört in einen Hook, den das Ereignis aufruft. Das erspart auch die Mühe, eine Lücke erst hinterher zu entdecken.

Regeln, die Aktionen stoppen, gehören sowohl in Hooks als auch in Berechtigungen. Die Dokumentation von Microsoft sagt, dass ein Hook nicht die einzige Sicherung sein sollte. OWASP, die gemeinnützige Security-Community, führt Least-Privilege-Zugriff und menschliche Freigabe für Hochrisiko-Aktionen unter seinen Gegenmaßnahmen gegen Angriffe auf Sprachmodelle auf. Wenn die Verbindung des Agenten nie Schreibrechte erhalten hat, findet kein Schreibvorgang statt, selbst in dem Turn, in dem der Hook fehlschlägt.

Die dritte Sorge betrifft das, was in einen Hook einfließt. Nutzer-Prompts, Tool-Ergebnisse und Fehlermeldungen können Text enthalten, den der Agent nicht selbst erzeugt hat. Die Dokumentation rät Entwicklern, diese Eingaben als nicht vertrauenswürdig zu behandeln und sie zu validieren, bevor sie darauf reagieren. OWASP zufolge ist unklar, ob narrensichere Methoden existieren, um Prompt Injection zu verhindern, den Angriff, bei dem versteckter Text in einer Eingabe das Verhalten eines Modells kapert. Ein Prüf-Workflow, der seine Eingabe für bare Münze nimmt, kann in seinem eigenen Urteil gesteuert werden.

07Die Ausfallraten von Hooks sind noch nicht öffentlich, daher ist das Aktivitätsprotokoll der einzige Nachweis für den Nutzer

Auch wenn die Regeln auf drei Stellen verteilt sind, kann niemand außerhalb von Microsoft sehen, wie oft Hooks tatsächlich übersprungen werden. Microsoft hat keine Fehlerraten veröffentlicht. Die Dokumentation ist ein Vorschau-Dokument und besagt, dass sich das Verhalten ändern kann.

Dasselbe Design findet sich im Produkt eines anderen Unternehmens. Der Coding-Agent von Anthropic, Claude Code, verfügt über Hooks, die an festen Punkten seines Lebenszyklus ausgeführt werden. Laut seiner Dokumentation bietet dies deterministische Kontrolle, da bestimmte Aktionen immer stattfinden, statt sich darauf zu verlassen, dass das Modell sie auswählt. Wie die Hooks von Copilot Studio verlagert dies die immer wiederkehrende Arbeit außerhalb des Ermessens der KI. Ob sich das Muster weiter verbreiten wird, lässt sich aus den vorliegenden Quellen nicht ablesen.

Was ein Nutzer überprüfen kann, ist die Aufzeichnung. Copilot Studio bietet eine Aktivitätsverfolgung, um nachzuvollziehen, was ein Agent getan hat, und die Dokumentation verweist Entwickler zur Fehlerbehebung darauf. Vor der Veröffentlichung eine Testkonversation ausführen und prüfen, ob der Aufruf des Hooks und sein Urteil in dieser Aktivitätsverfolgung erscheinen.

Wenn ich so etwas einsetzen würde, würde ich einen Pre-Tool-Hook einmal absichtlich fehlschlagen lassen. Zu sehen, wie der Aufruf, den er stoppen sollte, ungehindert durchgeht, liefert einen konkreten Grund — einen, dem ein Manager oder Prüfer folgen kann —, die Aktion zusätzlich auch über Berechtigungen zu blockieren. Solange keine Fehlerquoten veröffentlicht sind, ist dieser Testnachweis der Weg, auf dem ein Betreiber sehen kann, was durchkommt, wenn ein Hook fehlschlägt.

Eine in den Anweisungen festgehaltene Regel wird durch das eigene Urteilsvermögen des Agenten angewendet. Regeln, die jedes Mal gelten müssen, kommen in Hooks, und Handlungen, die nicht passieren dürfen, werden zusätzlich durch Berechtigungen blockiert. So überlebt die Regel sogar in dem Turn, in dem ein Hook übersprungen wird.

Anders als Anweisungen und Tools lösen Hooks jedes Mal eine Regel aus, ohne dass das Urteilsvermögen des Agenten dazwischengeschaltet wird. Doch Microsofts eigene Dokumentation rät Entwicklern, sich nicht allein auf sie zu verlassen. Immer wenn eine Regel festgeschrieben wird, muss die Person, die den Agenten einsetzt, zwei Fragen stellen: Wird sie jedes Mal benötigt, und muss sie etwas unterbinden? Dieser Aufwand ist die Verantwortung, die mit der Übergabe von Arbeit an einen Agenten einhergeht.