OpenAI Files Patent for AI That Hunts Security Holes in Finished Software
OpenAI's patent application describes an AI that reads the compiled code inside a finished app, flags the pieces that look dangerous, and writes up how an attacker could break in through each one.
What OpenAI's code-checking AI actually does
Ever tried to proofread a library with millions of pages, hunting for the one typo that could cause a disaster? That is roughly the job facing security teams checking finished software, where the code has already been converted into the machine-readable form your phone or laptop actually runs. Nobody can read all of it.
OpenAI's patent application describes a way to hand that job to AI. First, a standard code-analysis tool quickly scores each chunk by how risky it looks and sets aside the boring bits. Then an AI writes a short briefing on what attackers would likely go after in this particular app. Finally, AI reviewers read the riskiest chunks with that briefing in hand and report what they find.
Each report includes a plain-language attack story showing how someone could actually get in, plus a suggested fix. A separate check can then try to reproduce the problem to confirm it is real.
… determining, utilizing a reverse-engineering platform to perform an initial threat analysis of the binary function, a threat ranking for the binary function; generating, utilizing a large language model of the generative AI system, a threat model comprising a structured data object defining threat parameters corresponding to the computer application; …
Translation: The system uses reverse engineering and AI to rank software risks and build a structured threat model.
How the system ranks risky code, then digs in
The system starts with a binary repository, the collection of compiled program pieces (called binary functions) that make up an app. A reverse-engineering platform (the filing names Ghidra, a code-analysis toolkit) lists every function, drops trivial ones like tiny wrapper stubs, and builds a call graph, a map of which functions call which.
Next it computes a fast first-pass score, the threat ranking, from cheap signals such as risky memory-copy calls. Only the top slice (the filing's example is 500 functions) gets expensive treatment. Separately, an AI agent writes a threat model, a structured data file listing likely attack surfaces (network ports, file inputs), vulnerability classes (such as buffer overflows) and how to weigh them. Users can edit it.
Then an AI agent reads the high-ranked functions, 5 to 20 at a time in one example, together with the threat model. It produces a threat object: a summary, a severity, an exploitation narrative tracing user input to the weak spot, and a recommended fix.
- Every stage runs in a short-lived isolated container with no access to the orchestration software, to block hostile code from tampering with the AI's instructions.
- Results are saved in a content-addressable store (storage keyed by a fingerprint of the content), so jobs can pause and resume without redoing work.
The present disclosure relates to systems, non-transitory computer-readable media, and methods for improving the security analysis of computer code. In particular, the disclosed systems can retrieve a binary function from a binary repository of a computer application.
Translation: This patent describes methods for making automated code security analysis much better by pulling compiled functions from software.
Why security teams may care about this filing
If software gets checked faster, holes get fixed sooner, and the apps and services you use are harder to break into. The filing's pitch is that existing scanners either rescan everything on every run or struggle when code mixes languages and chip types. A tool that works on finished code and picks its targets could save security teams real time.
The filing names no product, and it describes a pipeline for security teams rather than something you would use directly. Results can be posted to a chat channel or a web page with a recommended fix attached. People can also edit the threat model, so a team can tell the AI what matters most for their own app.
OpenAI's seventh filing we've tracked in our AI guardrails race watchlist since September adds to a run that includes one letting replies start early and one blocking voice mimicry.
Finding security holes in finished software is a huge and costly chore. A single app can hold millions of functions, and the filing says older tools rescan everything on each run, burning time and computing power. One missed hole can be all an attacker needs.
The approach fits the size of that problem. Ranking first and spending the expensive AI time on the riskiest slice mirrors how a human expert sorts a mountain of work. Saving progress and running each step in a sandbox deal with the practical headaches of long jobs and untrusted code.
The open question is accuracy, and the filing offers no numbers on how often the AI is right. Its best answer is the validation step that tries to reproduce each bug and mutes the ones it cannot confirm. On paper, it is a sensible plan for a problem this big.
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
13 drawing sheets from US 2026/0352690 A1 · click any drawing to enlarge
Show the other 5 sheets
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in