OpenAI Files Patent for an AI That Checks Every Code Change for Security Holes
Every time a developer saves a change to an app, this OpenAI patent application has an AI write a custom security checklist, review the change against it, and then try to run the bug to prove it's real.
What OpenAI's code-change security checker does
Every time a programmer saves a change to an app, that change could accidentally open a door for hackers. Big software projects pile up hundreds of these changes, and checking each one by hand is slow. Older automated scanners often re-read the whole project every time, or only work for one programming language.
OpenAI's filing describes a different approach. An AI first looks at what kind of software it is dealing with, such as a website backend or a command-line tool, and writes a tailored checklist of the weak spots hackers usually go after. A second AI then reads the new change with that checklist in hand and writes up anything risky, including how serious it is and a suggested fix.
The filing also describes a final check: the system can rebuild the code in a sealed test area and try to reproduce the problem. If it can't, the alert gets muted instead of bothering a human.
… generating, utilizing a large language model of the generative AI system, a threat model comprising a structured data object defining vulnerability parameters of computer code corresponding to the computer application; …
Translation: The AI uses a language model to build a security profile detailing potential software weaknesses.
How the AI builds a checklist, then tests the bug
Developers save each edit to their code as a commit (a saved snapshot in the project's version history). The system retrieves one commit, or a range of them, and first asks a large language model to build a threat model. That is a structured data object (a machine-readable checklist) listing likely attack surfaces (such as web endpoints), vulnerability classes (such as SQL injection, where an attacker slips database commands into a form), and weights for what to prioritize. It tailors the list to the program type: web service, command-line tool, library or kernel module. Users can edit the list.
A generative threat analysis agent (an AI agent built on a language model) then reads the commit and the threat model together, inside an isolated container that limits what code it can see and keeps it away from the system's control code. Along the way:
- The AI maps which functions call which, building a directed graph (a map of arrows between functions) using tightly scoped prompts.
- It tags functions with taint attributes, meaning whether each one reads untrusted input or writes to sensitive places.
- It scores the risk of the commit, and the riskiest functions go to a fresh agent for deeper review.
The result is a threat object: a description, severity, location, patch status and recommended fix, often as a JSON file (a standard data format). In one described option, the system clones the commit into a runtime environment, runs it, and issues a validated threat object only if the bug reproduces. It can also resolve merge commits (changes that combine two branches) by walking back through their parent commits.
Why catching bugs per code change could save time
The apps you use get updated constantly, and every update is a chance to introduce a security hole. A reviewer that checks each change as it is saved, instead of rescanning an entire project, could flag problems before they ship. The filing says that targeted approach reduces repeated work and lets the analysis run in parallel across many isolated containers.
The run-it-to-confirm step matters for the people who receive the alerts. Security teams can drown in false alarms, and the filing says unconfirmed findings can be muted or deprioritized. As a patent application, this shows what OpenAI describes, not a released product. The description does name project areas such as Sora and ChatGPT as examples of what the system could examine.
OpenAI's tenth filing we've tracked in our AI guardrails race watchlist since September adds to a run that includes a self-testing bug finder and a topic-triggered rulebook.
Claim 1 is short and wide. It covers three steps: retrieve a saved code change, have a language model write a structured list of what to watch for in that app, and have an AI agent read the change and that list together to produce a security finding.
Notice what claim 1 leaves out. The sealed container, the map of which functions call which, the risk score and the run-it-to-prove-it step all appear only in later claims, so they add detail on top of the core idea. Anyone building an AI code reviewer that writes its own checklist first and then judges each change against it would sit close to the first claim's wording, whatever extras they add.
A claim this wide could change before any grant. If it holds, the sandbox and proof-by-running details may carry more weight than they look like they do now. The most useful idea for you is simple: a security reviewer that sizes up the app before it reads the change.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time OpenAI patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
12 drawing sheets from US 2026/0350179 A1 · click any drawing to enlarge
Show the other 4 sheets
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in