An AI code audit can find real bugs in code you own. Two things can stall it before the method matters: a general model can block defensive security work, and the programs that lift those blocks mean applying first. When a patch day hits, as our PHP2Shell report shows, you need help that day. Where your unpatched code goes is the other question this guide answers.
Will AI models refuse to help with defensive security work?
Sometimes, depending on the provider. Anthropic says its generally available models "have conservative cyber safeguards that block most cyber work," while still allowing code review, patching known issues and vulnerability finding in owned source code, and its verification program reduces those blocks for qualifying security professionals.1
I've hit this myself: during a defensive review of my own code, Claude stopped the work under its cybersecurity safeguards, while GLM-5.3 and DeepSeek on Maple handled the same review without a problem.
Real incident work can hit those blocks. When commercial APIs blocked its forensic analysis of attack payloads, Hugging Face ran the work on the open model GLM-5.2 on its own infrastructure2 and noted:
This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.
Open models aren't unlimited: they carry their own trained-in limits, so expect some refusals there too. The checkable difference is the gate: on Maple there's no cyber-verification program to apply to, and the models on your plan are the models you use.
For defensive work on your own code where even an open model's trained-in refusals get in the way, we offer an abliterated DeepSeek V4.1 Flash on request: a version modified to reduce refusals by removing an internal direction associated with refusal. Ask our team for access at [email protected].
It runs in the same attested enclave setup as Maple's other models, so Maple cannot see your chats with it either. It's for authorized work on code you own, and it won't make every answer right, so a person still checks what it finds.
Can you get AI security help the moment you need it?
Only if it's already in place when the advisory lands. When a patch day hits, as it did with PHP2Shell, you need a capable model on your own code that day, and Anthropic's and OpenAI's programs for more permissive cyber access mean applying first.
Anthropic verifies every applicant to its Cyber Verification Program and aims to answer defensive applications "within a few days"; it expects red-team applications "to take a few weeks to review."1 OpenAI's trusted access for cyber relies on "strong KYC and identity verification" to decide who gets its more permissive capabilities.3 Both are reasonable for dual-use tools, and both mean applying before you need the access. The help you need on patch day is the help you can open right now.
In Maple Research, the models are in the picker on your plan, with nothing to apply for. GPT-OSS 120B is on every plan, including Free, and GLM-5.3, GLM-5.3 Flash, DeepSeek V4.1 Flash, Kimi K3 and Gemma 4 31B are on Pro, Max and Team. These are starting points, not rankings; we haven't benchmarked any model on code audits:
| Job | Model to try first | Why |
|---|---|---|
| Review a large codebase in scoped passes | DeepSeek V4.1 Flash | 1,048,576-token window, shared by input, history, reasoning and output; DeepSeek reports stronger agentic coding results for its October build |
| Deep review of one module, agent work | GLM-5.3 | Z.ai's flagship, worth evaluating for complex coding and agent work |
| Cheaper passes over many files | GLM-5.3 Flash | Lower API rates than GLM-5.3 and a 1,048,576-token window |
| A second reviewer from another family | Kimi K3 | Moonshot AI's model, a different lineage from GLM and DeepSeek |
| Explain a finding, on Free | GPT-OSS 120B | OpenAI's open-weight reasoning model, 131,072-token window |
| Run it on one GPU you own | Gemma 4 31B | Maple's sizing estimate suggests a suitable 4-bit build can fit one 32K-context conversation on a 24 GB GPU; verify the engine's cache allocation and overhead |
One more model is available on request rather than in the picker: the abliterated DeepSeek V4.1 Flash (model ID deepseek-v4-1-flash-1017-uncensored), for security work on your own code where refusals get in the way; email [email protected].
To use them from your own tools, Maple Proxy exposes the same models with tool calls (model list); Proxy API access requires a paid plan, even for GPT-OSS 120B. The model library lists the rest.
Is it safe to paste your code into ChatGPT?
It depends on the plan, and on three questions that are easy to blur: whether the service may train on your code, how long it keeps it, and who can read it. OpenAI says it may use content from individual ChatGPT plans for training unless you opt out or use Temporary Chat, and that it doesn't train on business or API data by default.4 Neither answer tells you who can read the conversation.
That matters more for an audit than for anything else you send. Your unpatched code is the last thing you want to hand over: the vulnerable code, the stack details around it and the findings themselves are a map to your weakest point until the fix ships.
Selected terms from OpenAI's and Anthropic's own pages, plus the two open-model routes (not a complete account of either company's terms):
| Route | Trained on? | Kept and readable? |
|---|---|---|
| ChatGPT, individual plans | May be used unless you opt out, which covers new ordinary conversations. Feedback you submit can still be used, and temporary chats aren't used while they stay temporary; saving one makes it a regular chat5 | Kept under the plan's terms (not summarized here) |
| Claude Free, Pro and Max, including Claude Code on those accounts | May be used when you enable model improvement or otherwise opt in. Flagged conversations may be used to improve policy enforcement, including Safeguards models. Incognito chats are excluded from model improvement. Feedback you submit may be used for training6 | Deleted chats are normally removed from back-end storage within 30 days. With model improvement on, de-identified data from new or resumed chats can be kept up to five years. Separate retention applies to flagged chats and submitted feedback, and chats may be kept as required by law, to resolve disputes or to enforce policy7 |
| OpenAI API | Not by default; API customers can opt in | Abuse-monitoring logs, which can contain prompts and responses, are kept up to 30 days by default, longer where law or harm prevention requires. Zero data retention needs prior approval and acceptance of additional requirements, and some features still store state. OpenAI can, with written notice, make specific models ineligible for zero data retention for a customer to investigate or prevent severe risk activity8 |
| Anthropic API and commercial plans | Not by default, unless you submit feedback or bug reports or otherwise allow it9 | API inputs and outputs are deleted within 30 days by default, with listed exceptions; commercial chat products keep saved conversations.10 Zero data retention, for eligible API products and Claude Code for Enterprise, is subject to Anthropic's approval, has legal, misuse and harm exceptions, and still keeps safety-classifier results; Covered Models need limited retention and review11 |
| Vetted cyber programs | Check the underlying product's training terms; the cyber-program announcements do not establish a separate training rule | Anthropic's October 6 announcement requires retention for enrolled organizations to monitor misuse, except those already on zero data retention for Claude Fable 5.1 or Mythos 5.1, and describes customer-controlled storage through Enterprise Frontier Safeguards as coming later. OpenAI says its permissive cyber models may have zero-data-retention limits1, 3 |
| Open model on your own hardware | No provider involved | Stays on your machines, unless a connected tool sends it elsewhere |
| Open model on Maple | We do not train on your conversations | Chat history is stored encrypted; Maple cannot see your chats |
The strongest retention terms at both companies need approval. Anthropic's zero data retention is subject to its approval, is requested through its Sales Team and covers eligible API products and Claude Code for Enterprise, not Claude Free, Pro or Max. OpenAI's requires prior approval and acceptance of additional requirements, and it directs customers to sales to ask about eligibility.
A retention agreement governs what a provider stores afterward; the provider still processes your code to answer you. Running an open model on your own hardware keeps the code on your machines, but OpenAI's recipe for GPT-OSS 120B asks for at least 60 GB of VRAM, and the serving recipes for GLM-5.3 and DeepSeek V4.1 Flash include multi-GPU configurations.
Running a local LLM isn't the only private route: Maple hosts open models such as GLM-5.3 and DeepSeek V4.1 Flash, and Maple cannot see your chats, on every plan. You get the capability without the hardware.
Whichever route you use, send the least the task needs. Our guide to whether ChatGPT is private covers OpenAI's plans in more detail, and how to use AI privately covers your connection and identity.
| Material | Send it? | Why |
|---|---|---|
| The file or function under review, and the code that calls it | Yes | The model can't judge a path it can't see |
| Build errors, failing test output, stack traces | Yes, after removing hostnames, tokens and user data | Sanitized output helps explain the failure; review it for remaining sensitive details |
| Dependency manifests and lockfiles | Yes | They tell the model which versions you inherit |
.env files, API keys, passwords, private keys | No | A key in a chat is a key outside your vault; if one slips in, rotate it |
| Customer data and production logs with personal data | No | Use synthetic fixtures that preserve the values and edge cases needed to reproduce the behavior |
| A step-by-step reproduction of an unpatched bug | Only in a restricted space | Keep it in restricted channels while you coordinate disclosure |
How do you run an AI code audit?
Run an AI security code review as a short loop in a coding agent that can open the repository and run commands, on a disposable copy of the code with test credentials only, in a VM or container if you can. The model finds candidates; a person confirms each one and reviews any fix before it's merged. The eight steps, one line each:
- Isolate. Open a disposable copy of the repository, with a working build and test credentials only, in a coding agent such as Maple Agent.
- Map and scan. Have the agent map the entry points and run the build, the tests and the checks you already use, including a dependency audit.
- Scope. Pick one area and answer the Threat Modeling Manifesto's four questions for it: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job,12 then choose the relevant OWASP ASVS 5.0 requirements to check.13
- Review. Ask for findings in a fixed format with evidence, two or three times in fresh sessions.
- Triage. Group findings by root cause, rank them by impact and reachability, and record every decision, parking what you can't trace yet.
- Confirm. Where practical, turn each real finding into a failing test, or have a qualified reviewer confirm the code path, then stop.
- Fix. Close the root cause, keep the test, and have the code's owner approve the change.
- Verify. Check the fix, search for the same mistake elsewhere, and have a model from another family review the diff.
Which tool should run it?
The main path we suggest is Maple Agent, the Maple desktop app, which is in early access. You open a project folder, and it reads and edits files and runs the commands it needs in that folder, such as builds, tests and scanners; it also reads your AGENTS.md or CLAUDE.md and your skills.
Already use OpenCode or Goose? Connect them to Maple's models through Maple Proxy with our OpenCode or Goose guide. Traffic between your tool and the proxy is plaintext, so keep it on 127.0.0.1.
Whichever agent you use, a rule in a prompt and a disposable checkout aren't the same as enforced isolation: set file, command and network limits in a sandbox or container.
Four prompts to start with
Set the rules at the start of every session; in Maple Agent, you can put them in the checkout's AGENTS.md:
Rules for this session: work only on this repository. Do not write exploit
code, attack payloads or steps to attack a running system. If confirming a
finding would need one, stop and tell me what a person should check instead.
Then the review, in a fixed format:
Review the code in scope against the threat model. For each finding, give:
- the file and line
- the input that reaches it, and the path it takes
- why it is a problem, in one or two sentences
- severity (high, medium or low) against the threat model, and the CWE
- your confidence (high, medium or low) and what would confirm it
- a minimal fix
Report only issues you can trace from an input to the line. If you find
nothing in a category, say so. Don't write attack payloads.
Confirm each real finding with a test:
For finding 2, write a unit test that should fail on the current code
because of this bug and pass once it is fixed. Use only the test framework
this repository already uses, local fixtures and no network access. Make the
test fail because the security invariant is violated; explain the path to
the vulnerable code, rule out unrelated failures, and say what the test
proves and what it doesn't.
And verify the fix and look for variants:
You are reviewing a security fix, not writing one. Here are the finding, the
diff and the test. Does the diff close the path in the finding for every
input that reaches it, or only for the case in the test? List any input
classes or conditions that remain insufficiently checked, without writing
attack payloads, and any behavior the change breaks. Then search the
repository and its git history for the same root cause and, if the pattern
can be expressed reliably, draft a Semgrep or CodeQL rule with vulnerable
and fixed examples to test it.
What the steps leave out
Your code is one layer. PHP2Shell sat in the runtime: PHP says the risk is highest with Apache mod_php, where an unauthenticated request can trigger the attack before any application code runs.14 A review of your repository can't establish what's running, so keep a dependency scanner in CI and check the running versions against vendor advisories.
If the bug is in someone else's project, report it privately and coordinate disclosure. A person should confirm it, write the report in their own words and say AI was used; curl, for one, requires that you "reveal this fact in your report."15
OpenSSF says "90 days is the longest embargo period entertained by various groups as a default; many default embargo periods are shorter," and calls it "inappropriate" to omit credit to a reporter who wants it.16 Agree on a timeline with the maintainers: circumstances can justify more or less time, and disclosure can happen without a patch.
If a model saw a secret, treat it as compromised as a conservative rule: revoke it with the provider, rotate it and update what uses it, then check the logs for access while it was exposed. GitHub calls revoking "the most important remediation step," and suggests switching to a new secret first if revoking at once would cause downtime.17
How we built this guide
We adapted the eight steps for small teams from NIST's Secure Software Development Framework (SP 800-218 version 1.1: tasks PW.7.2, PW.8.2 and RV.3.3),18 the Threat Modeling Manifesto, OWASP's ASVS 5.013 and OpenSSF's disclosure guide. They support individual practices; none of them prescribes this sequence or these prompts.
The isolation advice follows OWASP's Top 10 for Agentic Applications, which says to "Run tool or code execution in isolated sandboxes."19 The repeated review passes follow Google Project Zero's Naptime research on exploring "multiple hypotheses through multiple independent trajectories."20
Three choices are our recommendations, not consensus: stopping at a failing test rather than an exploit, two or three review passes, and a reviewer from a different model family. Stopping before an exploit limits the scope of the work; it doesn't add assurance.
Sources
- Anthropic, Expanding the Cyber Verification Program, October 6, 2026. Supported uses of the general models, safeguards, program retention and its exception, dual use.
- Hugging Face, Security incident disclosure — July 2026, July 16, 2026.
- OpenAI, Trusted access for the next era of cyber defense, April 14, 2026.
- OpenAI, How your data is used to improve model performance. Training on individual and business plans.
- OpenAI, How your data is used to improve model performance (Help Center). Opt-out scope, feedback and temporary chats.
- Anthropic, Is my data used for model training? (consumer products), March 16, 2026.
- Anthropic, How long do you store my data?. Consumer deletion and retention.
- OpenAI, Data controls in the OpenAI platform. Abuse-monitoring logs and zero data retention.
- Anthropic, Is my data used for model training? (commercial products), August 18, 2026.
- Anthropic, How long do you store my organization's data?, July 1, 2026. Commercial and API retention.
- Anthropic, I have a zero data retention agreement with Anthropic. What products does it apply to?.
- Threat Modeling Manifesto working group, Threat Modeling Manifesto.
- OWASP, Application Security Verification Standard 5.0.0, May 30, 2025.
- PHP, Security advisory: Critical remote code execution vulnerabilities, update now, October 21, 2026.
- The curl project, Contributing to the curl project: On AI use in curl.
- OpenSSF, Guide to implementing a coordinated vulnerability disclosure process for open source projects.
- GitHub Docs, Remediating a leaked secret in your repository.
- National Institute of Standards and Technology, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, February 2022. Tasks PW.7.2, PW.8.2 and RV.3.3.
- OWASP Gen AI Security Project, OWASP Top 10 for Agentic Applications for 2026, December 2025. ASI01 and ASI02.
- Google Project Zero, Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models, June 20, 2024.
