# OpenAI Patch the Planet: How the New Disclosure Framework Works

OpenAI is proposing a coordination process for AI-assisted security findings, with the difficult work happening after a bug is found.

By Paras Madan | 2026-10-21


OpenAI published a proposed vulnerability-response framework on October 21, 2026, under Patch the Planet. It describes how maintainers, providers and other defenders could coordinate fixes before public disclosure, then help operators deploy them. The useful question is how much work this removes from the people responsible for the software.

Patch the Planet itself is not new. The [initiative launched on June 22](https://openai.com/index/patch-the-planet/) with Trail of Bits, combining AI-assisted research with human review, patches and tests for critical open-source projects. Today's announcement concerns the wider response process.

## What the proposed framework covers

The [October 21 proposal](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/) describes five stages: validate and fix upstream, give relevant organizations preparation time, coordinate with government partners protecting critical systems, prepare downstream updates, and publish guidance while supporting deployment.

Maintainers decide who receives advance notice. The proposed criteria include an organization's protective role, preparation time and ability to handle sensitive information. Disclosure timing should be reassessed if exploitation, leaks, revealing patches or stalled remediation change the risk.

This remains a proposal seeking feedback, rather than a binding industry standard or a generally available security API.

## Why a fix needs a distribution plan

Consider an open-source library used inside a hosted application. A maintainer can correct the library, but that does not automatically replace the copy running inside the application. Someone still needs to identify the dependency, build a compatible release, test it and deploy it.

There can also be several reasonable owners. The application team owns its release, a provider owns the managed runtime, and a platform team owns the container image. Asking whether the patch exists leaves those boundaries unresolved.

A useful coordination process should therefore produce more than a release announcement. It should make the next action clear to each participant: which component to replace, who can authorize that replacement, and what evidence establishes that the updated version is actually running.

**Discovery throughput and remediation throughput are different things.** Increasing the first without improving the second can leave maintainers with a longer review queue rather than users with safer software. This is the operational problem worth evaluating, regardless of which model found the issue.

## What maintainers can apply for

The current [Trail of Bits application page](https://trailofbits.com/patch-the-planet/) offers selected maintainers a week of dedicated security engineering, including review and submitted fixes. It also lists six months of ChatGPT Pro from OpenAI, with conditional Codex security access.

Selection and conditional access matter. This is not a promise that every applicant receives an audit or unrestricted model access. Those support terms should also not be confused with newly announced benefits on October 21.

For a small project, the practical value of outside help depends on what remains afterward. A proposed patch that nobody can maintain creates a different burden from a regression test that fits the project's existing workflow.

Before applying, maintainers could prepare a short account of supported versions, test coverage and release ownership. That gives an external engineer a way to spend limited time on work the project can actually merge and sustain.

## Early notice needs a defined purpose

There is an unavoidable tradeoff in involving more organizations before disclosure. Additional participants may prepare useful updates, but they also increase the number of people handling sensitive information.

The question for each participant should be concrete: what protective action can this organization complete that would otherwise be delayed? A team preparing a compatible update has a clearer purpose than a team receiving information only to stay informed.

That is also a useful limit on coordination overhead. Meetings and notifications should serve a specific deployment or protection decision. Otherwise, the process can become another task for an already busy maintainer.

## What would demonstrate that this works

I would look for evidence beyond the number of findings: how much maintainer review time each accepted fix required, how often proposed changes survived compatibility testing, and how quickly supported downstream versions received usable updates.

Those are evaluation criteria, not results established by this announcement. They would help distinguish a program that generates technically interesting reports from one that reliably reduces unfinished security work.

The next meaningful improvement may be a less dramatic one than a new discovery benchmark: making it easier for the person running the software to know that the fix reached their system.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn complex AI launches and engineering work into clear stories that developers and decision-makers can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min)