MCP Events in ChatGPT: Why Subscriptions Are Credentials

What OpenAI shipped

At DevDay on September 29, OpenAI announced that ChatGPT would support the proposed MCP Events specification. The feature lets plugins start automations when something happens in a connected app, so an agent can react to activity instead of waiting for a user prompt 1. According to one developer walkthrough, the support covers all ChatGPT plans and targets the MCP 2.0 protocol revision dated 2026-07-28 2.

The developer obligations are concrete. A server must implement three methods, events/list, events/subscribe and events/unsubscribe, on the same authenticated endpoint as its tools. It must also advertise an events capability during server/discover, pass a callback verification step, and sign every delivery using Standard Webhooks HMAC-SHA256 2. Deliveries carry webhook-id, webhook-timestamp, webhook-signature and X-MCP-Subscription-Id headers. They are signed with a ChatGPT-issued secret that uses a whsec_ prefix and decodes to 24–64 bytes 2.

A spec that barely exists yet

The sources agree that ChatGPT is implementing something that has not been ratified. OpenAI's own announcement links to the charter of the MCP Triggers and Events working group. That charter lists the "Events in MCP v1 RFC" as still in the ideating stage, with an end-of-April target date and no named champion 1. The group's changelog contains one entry, "Initial charter," dated March 24, 2026 1. A separate analysis likewise describes the working group as chartered in March 2026, with its events proposal still at the ideation stage 3.

ChatGPT also implements only part of that draft. It accepts webhook delivery and nothing else. There is no polling, no streaming, and no handling of gap or termination notifications 23. That gap matters in practice. Without gap notifications, neither side has a protocol-level way to signal that events were missed. Without termination notices, a subscription has no built-in way to announce that it has ended.

WorkOS notes that implementations often run ahead of ratification, and that this is usually healthy 1. The risk is not the early shipping itself. The risk is that real production behavior settles around one vendor's subset before the standard has worked through its hard problems.

The subscription is the credential

The sharpest argument comes from WorkOS. An event subscription is a durable record created under one user's access token. Once it exists, it authorizes the MCP server to keep pushing that user's data to an agent, even after the original token has expired 1. Functionally, that is a credential, although the draft never calls it one.

WorkOS identifies the open question as revalidation. Neither the draft nor ChatGPT's integration specifies how often a server should check that a subscription is still legitimate 1. A user might revoke access, leave an organization, or have permissions narrowed. The subscription could still go on delivering events unless the server owner builds their own checks.

This reading fits the webhook-only design described by the other sources. Under that model, ChatGPT hands out a signing secret and the server holds a subscription record 2. That pairing looks much like an API key plus a standing grant, but without the expiry and rotation rules that usually govern API keys. The missing termination signal points the same way 23. If the protocol has no clean way to say a subscription is over, it falls to server authors to decide when it should be.

The wider compliance picture

One analysis places the Events rollout alongside another DevDay caveat. The Agents API's computer-use capability launched with US-only data residency and no Zero Data Retention option 3. That is a real constraint for EU and enterprise teams weighing OpenAI's managed-infrastructure pitch 3. The two issues are technically separate. Together, though, they suggest that OpenAI's agent features are arriving faster than the governance controls around them.

Our read

MCP Events is a useful primitive, and the webhook contract ChatGPT expects is specific enough to build against today 2. Teams that do so should treat it as security-sensitive infrastructure, not a convenience feature:

• Model subscriptions as credentials. Give each one an owner, a scope, an expiry, and a revocation path.
• Re-check authorization on a schedule. Do not assume a grant remains valid indefinitely.
• Tie subscriptions to user deprovisioning flows. When access is removed, the subscription should go with it.

The working group may eventually define lifecycle rules for subscriptions, but its formal proposal has not progressed past ideation 13. Until it does, governing these standing grants is the responsibility of whoever runs the server.