ChatGPT adds MCP Events support so servers can push updates by webhook, but the draft spec never says when to recheck subscription permissions

OpenAI announced at its DevDay on September 29 that ChatGPT now supports the draft MCP Events specification. Until now, MCP servers responded only when an agent called them. Servers can now also use webhooks to report events that happen on their side. With this change, agents can wait for changes in the outside world and act on them, and that mechanism now runs on a standard protocol.

The draft specification has a gap, however. It does not say when a user's permissions should be rechecked after a subscription has been created. Once created, a subscription lasts longer than the token of the user who created it. Data belonging to people whose access has been revoked, or data addressed to them, could therefore keep flowing. This article looks first at what the new feature does and then at the permissions gap that remains in the specification.

From answering calls to sending notifications

OpenAI's developer documentation describes the feature as follows.

Until now, an MCP server responded only when an agent called one of its tools. To find out whether a new message had arrived, a document had been edited or a job had finished, the agent had to go and ask. With subscriptions, the server can notify ChatGPT as soon as a change happens. Features that let ChatGPT start working automatically when something happens, commonly called automations, will be built on this. Some reports have said that this gives agents a complete set of communication patterns.

ChatGPT supports only a narrow part of the specification. ChatGPT's release notes for September 28 to October 2 list the following conditions.

MCP 2.0 is required, and webhooks are the only delivery method. The polling and streaming options in the draft specification are not available. For server developers, this settles the model: ChatGPT provides an endpoint for incoming notifications, and their servers send events to it. The specification is still a draft, but a widely used product has already picked one method, so server implementations across companies are likely to follow it.

A subscription becomes a long-lived credential

The problem is how subscriptions are handled. In an October 1 blog post, identity infrastructure company WorkOS argued that subscriptions should be treated as credentials. The author, Maria Paktiti, wrote:

In an ordinary tool call, the user's access token is sent with every call, so the server can check permissions each time. If the token expires or an administrator revokes the user's access, the next call fails. A subscription works differently. It is registered under the token that was valid when it was created and then stays on the server as a record. The user does not present a token again each time a notification is sent. As a result, the permission granted at creation outlives the token.

Here is an example of what could happen. Suppose an employee who has since left the company, or someone who has been removed from a project, had earlier used ChatGPT to subscribe to updates from internal chats or documents. If the server does not recheck permissions before sending, new messages and document changes will keep arriving in that person's ChatGPT.

Only the word "periodically"

The draft specification does mention the issue. According to Paktiti, it includes a sentence saying that permissions should be rechecked "periodically." That wording is weak.

In a specification, a rule that is not marked "MUST" is only a recommendation that implementers are free to ignore. Because no interval is set, checking every minute and checking once a month both comply with the specification. And because there is no conformance test, a server that never rechecks permissions can still connect to ChatGPT.

As a result, how well revocation works depends on how long the subscription lasts.

If a subscription lasts one week, data could keep arriving for up to a week after access is revoked. The only way to close this gap is to recheck the user's current permissions every time a notification is sent. The draft specification does not require this.

MCP's handling of permissions faces a new test with notifications

MCP authorization has already run into a different problem this week. As previously reported, a flaw was found in the official Python SDK that let a malicious server redirect where OAuth tokens were sent. That flaw was in how tokens are obtained. The subscription issue arises after a token has been obtained. Weaknesses in the part of the specification that decides who can read what, and when, have now appeared in two different places in a row.

Adopting Enterprise-Managed Authorization, which manages access at the organization level, does not close this gap by itself. Even if an administrator revokes access, notifications will not stop unless the subscriptions stored on the server check for that change.

For now, server developers have to set their own rules outside the specification. For example:

・Each time a notification is sent, check the current permissions of the user who created the subscription.
・Keep subscription lifetimes short, and require authorization again each time one is renewed.
・When a user's access is revoked or their token is revoked, delete all of that user's subscriptions at once.
・In Agent Observability logs, record each subscription's destination and the token it was created with.

OpenAI's documentation and release notes do not explain how ChatGPT handles permissions for the notifications it receives. The next question is whether the specification, before it is finalized, will make rechecking a MUST, set an interval and add a conformance test. Until then, server notifications will be more convenient, but they could also stay open after access has been revoked.