MCP

MCP Events: Wenn ein Abonnement zu einer Anmeldeinformation wird, die sich nicht widerrufen lässt

Von IdeaBosqueZuletzt aktualisiert: 2026年10月3日

Die wichtigsten Erkenntnisse

MCP Events fügt einen dritten Aufweck-Trigger für Agenten hinzu — jenseits von Cron-Zeitplänen und menschlichen Nachrichten kann ein MCP-Server jetzt einen signierten Webhook an ChatGPT senden, wenn sich in einer verbundenen App etwas ändert.
Das Abo überlebt den Zugriffstoken, der es erzeugt hat — ttlMs: null fordert ein Abo ohne Ablauf an, und das Tupel, das es identifiziert, enthält keinen Token, keine Scopes und kein Ablaufdatum.
ChatGPT unterstützt den Webhook-Zustellungsmodus, nicht aber den terminated-Widerrufsumschlag des Entwurfs — das einzige verbleibende Widerrufssignal ist ein fehlgeschlagener Refresh, der -32012 Forbidden zurückgibt.
Das eigene Erfolgskriterium der Working Group — ein eingereichter SEP — wurde nicht ausgeliefert — die Chartern-Tabelle zeigt weiterhin „Ideating“ mit Champion „TBD“ und einem einzigen Changelog-Eintrag vom 24. März 2026.
WorkOS rahmt das Abo als Anmeldeinformation — ein dauerhafter Datensatz, erstellt unter dem Zugriffstoken eines Benutzers, der Ihren Server autorisiert, die Daten dieses Benutzers lange nach Ablauf des Tokens an einen Agenten zu senden.

Bisher wachte ein KI-Agent aus einem von zwei Gründen auf: Ein Cron-Zeitplan wurde ausgelöst, oder ein Mensch tippte eine Nachricht. Am 29. September 2026, auf der DevDay, kündigte OpenAI an, den vorgeschlagenen MCP-Events-Standard zu unterstützen, sodass Plugins Automatisierungen starten können, wenn in einer verbundenen App etwas passiert. Die Dokumentation beschreibt, wie ein MCP-Server Updates an ChatGPT senden kann — ein message.created-Ereignis, nach Kanal gefiltert, oder ein comment.created, nach Dokument gefiltert — sodass ein Agent handelt, wenn ein Fehlerbericht eintrifft oder ein Review-Kommentar gepostet wird, nicht erst, wenn Sie daran denken zu fragen. Nathan Baschez, der bei Notion an Produktdesign arbeitet, postete am 3. Oktober, er habe so wenig Begeisterung dazu noch nie gesehen: „Ereignisgesteuerte Trigger sind eine riesige Sache.“

Dieser Artikel kartiert, was MCP Events tatsächlich implementiert, die Anmeldeinformations-Lebensdauerdücke in seinem Zentrum und was ein Produktions-MCP-Server speichern und verifizieren muss, bevor er einen Webhook ausliefert. Er baut auf MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments auf, das den zustandslosen Kern behandelte; hier konzentrieren wir uns auf die ereignisgesteuerte Erweiterung und auf das Abo-Lebenszyklus-Problem, das die Working Group nicht fertig spezifiziert hat.

Was ChatGPT tatsächlich implementiert

Die Charta der MCP Triggers and Events Working Group listet genau ein aktives Arbeitsprogramm: „SEP: Events in MCP v1 RFC“, Status „Ideating“, Zieldatum „End April“, Champion „TBD“. Die Charta hat einen einzigen Changelog-Eintrag, datiert 2026-03-24: „Initial charter“. Die Working Group wird von Clare Liguori (AWS) und Peter Alexander (Anthropic) geführt.

Das Inkubations-Repository erzählt eine andere Geschichte. Es enthält einen Design-Sketch, markiert „Status: Draft proposal“, verfasst von Peter Alexander, datiert 2026-02-19. Das README ist unmissverständlich: Die Inhalte sind explorativ und „stellen keine offiziellen MCP-Spezifikationen oder -Empfehlungen dar“. Implementierer reichen bereits Feldberichte dazu ein. Was es nicht gibt, ist ein eingereichter SEP — das eigene, erklärte Erfolgskriterium der Charta: „Ein akzeptierter SEP, der den Trigger/Callback-Mechanismus und seinen Abo-Lebenszyklus definiert.“

ChatGPT implementiert einen Ausschnitt dieses unfertigen Dokuments. OpenAIs MCP-Events-Anleitung verlangt MCP 2.0, Protokollversion 2026-07-28, und unterstützt Webhook-Zustellung sowie Callback-Verifikation aus dem Entwurf. Polling, Streaming und die gap- und terminated-Steuerbenachrichtigungen des Entwurfs werden nicht unterstützt. Letzteres ist entscheidend.

Die Mechanik ist geradlinig. Ein Server kündigt eine events-Fähigkeit in seiner server/discover-Antwort an. Der Nutzer sagt ChatGPT, was es überwachen und wie es antworten soll. ChatGPT ruft events/subscribe mit Ereignisname, Filterargumenten, Callback-URL und Signatur-Secret auf. Der Server verifiziert den Callback mit einer Einmal-Challenge, speichert das Abo und sendet passende Ereignisse als signierte Webhooks. Drei Methoden — events/list, events/subscribe, events/unsubscribe — laufen auf demselben authentifizierten Endpunkt wie die Tools.

Das Abo ist eine Anmeldeinformation

Der Teil, der Aufmerksamkeit verdient, ist das, was der Entwurf Ihren Server speichern lässt. Wie WorkOS' Analyse es rahmt, ist ein Ereignis-Abo eine Anmeldeinformation: ein dauerhafter Datensatz, erstellt unter dem Zugriffstoken eines Benutzers, der Ihren MCP-Server autorisiert, die Daten dieses Benutzers lange nach dem Ablauf des Tokens, der ihn erzeugt hat, an einen Agenten zu senden.

Vergleichen Sie das Abo mit dem Token, der den Aufruf autorisiert hat. Nach der Autorisierungsspezifikation 2026-07-28 müssen Server validieren, dass Zugriffstoken speziell für sie ausgestellt wurden, die Autorisierung muss in jeder HTTP-Anfrage enthalten sein, und ungültige oder abgelaufene Token müssen einen 401 erhalten. Kurzlebig, schmal im Scope, bei jeder Anfrage neu geprüft. Das Abo erbt nichts davon. Der Design-Sketch keypt ein Webhook-Abo auf das Tupel (principal, delivery.url, name, arguments) — der Principal ist der kanonische Identifikator des authentifizierten Subjekts serverseitig. Das Tupel enthält weder den Token selbst, noch seine Scopes, noch seine Laufzeit. Und die Lebensdauer ist bis zum Unendlichen verhandelbar: ttlMs: null fordert ein Abo ohne Ablauf an, und ein Server, der das gewährt, gibt refreshBefore: null zurück.

	Zugriffstoken	Ereignis-Abo
Lebensdauer	Kurz, fester Ablauf	Der TTL, den Sie gewähren, bis hin zu keinem Ablauf (`ttlMs: null`)
Gebunden an	Ihren Server als Zielgruppe, plus Scopes	`(principal, url, name, arguments)` — kein Token, keine Scopes, kein Ablauf
Geprüft	Bei jeder HTTP-Anfrage, 401 bei Ablauf	MUSS bei der Subscription; SOLLTE danach „periodisch“, ohne Intervall
Endet wenn	Er läuft ab oder der Auth-Server widerruft ihn	Der TTL verstreicht, der Client abonniert ab, oder Ihr Server beendet ihn

Der Zugriffstoken läuft ab. Das Abo, das er erzeugte, liefert weiter.

Der Widerruf ist in ChatGPT asymmetrisch

Der Entwurf ist klar bei der Pflicht und vage bei der Kadenz. Bei der Subscription muss der Principal authentifiziert und autorisiert sein. Zur Zustellungszeit: „Der Server SOLLTE periodisch die Berechtigungen neu verifizieren. Wird der Zugriff des Benutzers widerrufen (z. B. aus einem Slack-Kanal entfernt),“ beendet der Server das Abo. OpenAIs Anleitung wiederholt dieselbe Pflicht: „Überprüfen Sie den Zugriff des Benutzers während der Lebensdauer des Abos erneut und stoppen Sie die Zustellung, wenn der Zugriff widerrufen wurde.“

„Periodisch“ leistet in diesem Satz viel Arbeit. Es gibt kein Intervall, kein MUSS, und keinen Konformitätstest dahinter.

Dann ist da das Signal selbst. Im Entwurf hat jeder Zustellungsmodus seine eigene Art, „Stopp“ zu sagen. Bei Webhooks ist es ein signierter {"type":"terminated"}-Umschlag, per POST an die Callback-URL gesendet. Danach existiert das Abo nicht mehr, ein späterer Refresh gibt daher -32012 Forbidden zurück, wenn der Beendigungsgrund fortbesteht. Dieser Umschlag ist die Art des Protokolls, dem Agenten zu sagen „das hier wurde gestoppt, und zwar aus diesem Grund“. Es ist auch eine der beiden Steuerbenachrichtigungen, die die ChatGPT-Integration nicht unterstützt.

Zustellungsmodus	Wie der Entwurf „Stopp“ sagt	In ChatGPT
Poll	Ein Fehler bei der nächsten Abfrage	Modus nicht unterstützt
Push-Stream	`notifications/events/terminated`	Modus nicht unterstützt
Webhook	Signierter `terminated`-Umschlag per POST an den Callback	Modus unterstützt, Umschlag nicht unterstützt
Jeder Modus	Der nächste Refresh schlägt mit `-32012 Forbidden` fehl	Das einzige verbleibende Signal

In der ChatGPT-Integration ist das einzige verbleibende Widerrufssignal ein fehlgeschlagener Refresh. Wird der Zugriff eines Benutzers widerrufen und Ihr Server stoppt die Zustellung, erfährt der Agent es erst, wenn der TTL des Abos verstreicht und der Refresh fehlschlägt. Haben Sie ttlMs: null gewährt, erfährt der Agent es nie.

Was Ihr Server verifizieren muss

Entwurf und OpenAI-Anleitung spezifizieren zusammen eine echte Sicherheitsoberfläche. Die nicht verhandelbaren Teile:

Fordern Sie einen authentifizierten Principal. events/subscribe und events/unsubscribe müssen mit einem authentifizierten Principal aufgerufen werden; Aufrufe, die die Autorisierung bestehen nicht, erhalten -32012 Forbidden.
Verifizieren Sie den Endpunkt vor der ersten echten Zustellung. HMAC stoppt Fälschung, nicht Flutung. Der Server darf mit der Zustellung an eine Callback-URL nicht beginnen, bevor die Absicht des Endpunkts, Zustellungen zu empfangen, bestätigt ist — eine Challenge-Handshake, eine Allowlist oder eine vorherige Out-of-Band-Verifikation.
Führen Sie SSRF-Prüfungen zur Zustellungszeit durch. Callback-URLs müssen HTTPS verwenden. Lösen und validieren Sie die Zieladresse bei jeder Verbindung, blockieren Sie private und lokale Bereiche, folgen Sie niemals Redirects — und wenden Sie all das auf Verifizierungsanfragen genauso an wie auf Zustellungen.
Halten Sie Payloads minimal. Ereignis-Payloads tragen dasselbe Injektionsrisiko wie Tool-Ergebnisse. OpenAIs Anleitung besagt, eine Zusammenfassung zu senden und ein Lesetool für den vollständigen Datensatz offenzulegen, benutzergenerierten Text als Daten zu behandeln und keine Anweisungen hinzuzufügen, die dem Modell im Payload vorschreiben, wie es sich verhält.
Machen Sie Schreibvorgänge idempotent. Ereignisse können in falscher Reihenfolge eintreffen, wiederholte Aufrufe dürfen Änderungen daher nicht duplizieren. Zustellungen deckeln bei 256 KiB, und 410- und 413-Antworten werden nicht wiederholt.
Autorisieren Sie zur Aktionszeit, nicht zum Empfangszeitpunkt. Der Empfang eines Ereignisses stellt keine Handlungsberechtigung dar. Der Tool-Aufruf, den der Agent als Antwort ausführt, geht durch Ihre normalen Prüfungen — dieselben, die MCP-Tool-Aufrufe über OAuth-Scopes hinaus kontrollieren.

Das gesamte Vorstehende steht in den Dokumenten. Die zwei Dinge, die dort nicht stehen: wie oft Sie den Zugriff neu prüfen, und wie ein Benutzer oder Administrator sieht, was sein Konto sendet.

Drei Entscheidungen, die Sie selbst treffen müssen

Der Abo-Lebenszyklus ist genau das, was die Working Group per Charta zu spezifizieren sich vorgenommen hat und wofür sie noch keinen SEP ausgeliefert hat. Bis dahin sind drei Entscheidungen Ihre, und die Defaults entscheiden sie schlecht.

Erstens: Gewähren Sie kurze endliche TTLs und lehnen Sie ttlMs: null ab. Der TTL ist das Intervall, in dem ein widerrufenes Abo für den Client sichtbar wird. Ein Abo ohne Ablauf ist eine OAuth-Genehmigung, die niemand sehen kann.

Zweitens: Verifizieren Sie den Zugriff nach einem Zeitplan, den Sie in einem Satz formulieren können — nicht „periodisch“. Wenn Sie nicht sagen können „wir prüfen alle 15 Minuten neu“ und auf den Job verweisen, der es tut, verlassen Sie sich auf ein SOLLTE ohne Intervall und ohne Konformitätstest.

Drittens: Führen Sie einen per-User-Abonnement-Index. Ohne ihn bedeutet das Offboarding eines Benutzers, anzunehmen, dass seine Abos gestorben sind, statt es zu bestätigen. Scheidet ein Mitarbeiter aus, lautet die Widerrufsfrage nicht „ist sein Token abgelaufen“ — sondern „wurde jeder Webhook gestoppt, den er autorisiert hat“.

MCP Events ändert das Trigger-Modell für Agenten, und das ist die eigentliche architektonische Verschiebung. Aber die Anmeldeinformations-Lebensdauerdücke ist der Teil, der Produktionsdeployments zuerst beißt. Das Protokoll machte den Server zustandslos; die Events-Erweiterung machte den Server wieder zustandsbehaftet — und der Zustand, den er hält, ist eine Anmeldeinformation ohne spezifizierte Widerrufskadenz.Das folgende Diagramm kartiert den Abo-Lebenszyklus, die Anmeldeinformations-Lebensdauerdücke und die asymmetrische Widerrufsfläche: