TL;DR: OpenAI’s AI agent team turned 5,034 audit targets in the Linux kernel into 948 unique local privilege escalation exploits for about $1.2 million in API credits, then human researchers reviewed the results. You can copy that shape on code you own: agents scout what’s reachable, analyze it, prove each finding in isolation and draft a fix, and a person approves.
On November 4, 2026, OpenAI published “A thousand fewer paths to root”. The headline is 948 Linux exploits. The lesson for a software team sits underneath it: the result came from specialized agents working in stages, each handing evidence to the next, with a human at the end.
That design doesn’t depend on kernel expertise, so you can point the same structure at your own services. The urgency is real: OpenAI says its pipeline was “net profitable” against public bug bounty payouts. Attackers can do that math too, so start now.
What OpenAI’s AI agent team found
OpenAI ran the pipeline in mid-October 2026 against the latest Linux kernel, using an upcoming cyber model. Targets were isolated VMs running a stock desktop OS with standard protections on.
| Stage | Result | API cost |
|---|---|---|
| Scout | 5,034 audit targets, about 2.8M lines, roughly 7% of the kernel | $3,426 |
| Analyze | 2,308 candidate findings | $316,549 |
| Validate | 1,724 reproduced (about 74.7%) | $73,330 |
| Assess exploitability | 948 unique LPE exploits, 291 information leak PoCs | $820,123 |
| Total | $1,213,430 |
These are OpenAI’s kernel-scale numbers, not an estimate for your repo. OpenAI calls its costs “more an upper bound” because it measured capability, not efficiency.
Keep three limits in mind:
- These are local privilege escalation (LPE) bugs. An attacker needs a local foothold first. They aren’t remote exploits by themselves.
- Many aren’t fixed yet. When the 10-day scan and analysis ended, 61 LPEs were patched upstream, 43 had staging patches and 299 were under public discussion. OpenAI has sent hundreds of reports and patches for critical bugs and is sending the rest gradually with Patch the Planet partners.
- OpenAI’s post doesn’t describe these bugs being exploited in the wild.
OpenAI’s guidance is still blunt. On an OS that isn’t on its latest patches, it says a low-privileged account “should be considered functionally equivalent to root access for a well-resourced threat actor.” So patch, and limit blast radius with isolation such as Firecracker and gVisor.
The five stages of an AI agent security workflow
An AI agent security workflow splits review into stages, where each stage narrows the work and produces evidence for the next. OpenAI’s version has five:
- Discovery. Scout agents pick audit targets by reachability and security relevance. Analyst agents read each target, build a threat model and report candidate findings.
- Dynamic validation. Triage agents write a proof of concept and run it in an isolated VM with KASAN, a kernel memory error detector, refining it until the bug reproduces or the options run out.
- Exploitability assessment. A screening agent filters out findings with no plausible path. ExploitDev agents test the rest.
- Patch generation. Agents draft a patch for each validated bug, following nearby code conventions and checking for variants.
- Human review. Security researchers review the exploit, patch and severity before anything goes to maintainers.
Each handoff carries evidence, not opinion, so the human at the end decides from facts.
How to map each stage to your own repo
Use this workflow only on code you own or are authorized to test. For your repo, drop the exploit-building stage entirely. A failing test proves a defect without producing an attack tool.
| OpenAI stage | Your version | Output |
|---|---|---|
| Scout | List entry points reachable by anonymous or low-privilege users: routes, webhooks, uploads, parsers, queue consumers | Audit list |
| Analyst | One target per run: read the code, write a short threat model, report suspected flaws | Candidate findings |
| Validate | Write a minimal failing test in a disposable environment | Test plus log |
| Assess | Rate impact by the trust boundary crossed | Severity with reasons |
| Patch | Draft the fix as a pull request with the test included | Pull request |
| Human | Review, then merge or reject | Merged fix or closed finding |
Scoping pays for itself. OpenAI’s scouts cost $3,426 and cut the audit to about 7% of the kernel. Start with one service and its public entry points. A task for one finding can be this short:
Title: Validate finding: path traversal in /api/exports/download
Scope: this repository only. Disposable test environment only.
No production credentials, no external network targets.
Goal: write a minimal failing test that proves or disproves the finding.
Evidence: test file, command output, code path from entry point to flaw.
Give up: stop after two approaches with no new evidence. Report what you tried.
Do not: fix the bug here, build an attack payload, or merge anything.
Verify the path, not only the result
In an early run, OpenAI’s exploit stage reported 200 successes. Human review found 20 of them reached root through a different 0-day than the one assigned. The pipeline marked success on the outcome, and the outcome was true for the wrong reason.
OpenAI tightened the task constraints and added an independent check that each exploit used its assigned vulnerability. Its takeaway: verify the path to a result as well as the result.
Your version is familiar: an agent says its test proves the auth flaw, but the test fails on a missing fixture. Add a check agent that didn’t write the test, and ask it one question: does this failure come from the reported code path?
Validate early, because false positives cost the same
OpenAI found that attempting to validate a true positive and a false positive cost about the same. So every bad candidate that reaches validation burns a full run.
Filter before you prove. OpenAI validated findings that a low-privileged user could reach, that needed no special capabilities and that produced measurable evidence. Write equivalent gates for your code, such as “reachable without an admin role.” Findings that fail the gate get closed with a reason.
Then recheck findings against the latest code before you report them, as OpenAI recommends, to avoid duplicate or obsolete reports.
Set a give-up rule before the run starts
Failed attempts were the expensive ones. On LPE candidates, 69 failures averaged $3,922 each, while 1,169 successes averaged $360. By our math, that’s about 6% of attempts taking about 39% of the $691,000 spent on that stage.
OpenAI’s suggested fix is a give-up condition, such as stopping after an hour with no progress. Write that rule into the task, and back it with a hard limit on the run.
In Sharkly, the per-Task timeout lives in an Agent’s Run settings. It’s a time cap, not a progress detector, so keep the “no new evidence” rule in the instructions.
Keep orchestration light as models improve
OpenAI built a layer of 103 exploitation techniques for GPT-5.5 Cyber, which raised its success rate from 76.2% to 88.9%. The same layer added only 1.5 points on GPT-5.6 Cyber, so OpenAI removed it.
Retest your own scaffolding each time you change models. Rescan too: the October run found more than 5x as many novel LPEs as a July run with GPT-5.6 Sol, on code that had three more months of hardening.
Keep human review before anything ships
Agents draft fixes as pull requests. A person merges. OpenAI found first-pass patches could be larger than needed, miss variants or break conventions, and that more passes improved them.
It also recommends using models for adversarial review of both human and AI patches. So have an agent try to bypass the fix, then let a person decide. If review is already your bottleneck, read how to design review for parallel agents before you add a new stream of pull requests.
How to run the workflow as tasks in Sharkly
A Task is the main unit of work in Sharkly. Here’s one way to build this workflow:
- Create a task type. A task type owns one Workflow of ordered statuses. A “Security finding” type could run Candidate, Reproduced, Patch drafted, In review, Closed.
- Create a Crew. A Crew is a reusable group of People and Agents coordinated by one leader Agent. Add scout, analyst, check and patch Agents. The leader starts first and mentions members for specific work.
- Isolate the runs. Use a temporary directory so each Task gets its own worktree, and read our guide to isolated worktrees if you’re fanning out. Leave the Crew’s shared directory off where the check Agent needs independence.
- Automate the handoffs. An Automation with a task-status trigger can start the patch Agent when a Task reaches Reproduced. These runs are unattended and can’t ask questions, and status matching is organization-wide, so have the instructions verify the triggering Task.
- Link the pull requests. With the GitHub integration, a task ID in the branch, title or description links the pull request. Merging doesn’t change task status, so the reviewer closes the Task.
Statuses are shared across the Organization, so add new ones for this workflow instead of renaming existing ones.
One boundary matters here: a worktree stops Tasks from colliding, but it isn’t a security sandbox. Run reproduction tests in a disposable container or VM with no production secrets, and give Agents the least Git access they need.
Sharkly coordinates this work. Claude Code, Codex and similar tools perform the execution, and model usage continues through the subscriptions or API keys configured in those tools. If you’re scaling out, see how to run 10 AI coding agents at once.
For a small repo, assign one Agent to one Task and skip the Crew. Use a Crew when a leader needs to sequence several roles and bring results back into one Task.
Conclusion
OpenAI’s result is a blueprint for your team: narrow the scope, demand evidence at every handoff, check the path, stop losing runs early, and keep a person on the merge button.
Start this week. Pick one service you own, list its public entry points, and file one validation Task per suspected flaw. Sharkly’s quickstart gets your first Agent running on a connected Computer, and sharkly.ai shows how the task and review layer fits around your agents.
FAQ
Did OpenAI’s agents attack live Linux systems?
No. The exploits ran in isolated VMs inside a controlled research environment, and human researchers reviewed results before reporting them.
Are all 948 Linux vulnerabilities patched?
No. Many are still being reported and patched. At the end of the 10-day scan, 61 were patched upstream and 43 had staging patches.
Can these exploits compromise a server remotely?
Not by themselves. They’re local privilege escalation bugs, so an attacker needs a local foothold first. Keep systems patched and isolate untrusted workloads.
What would this workflow cost on my repo?
OpenAI’s figures don’t transfer, because they cover a kernel-scale run. Start with one service, set run limits and measure the cost per validated finding.
Do I need OpenAI’s cyber model?
You can’t use it yet, since OpenAI describes it as upcoming. The stages are model-neutral, so test them with the coding agents your team already runs and judge the output by its evidence.
