Defender access: the security work AI models used to refuse

Mend.io now has verified defender access at both Anthropic’s Cyber Verification Program and OpenAI Daybreak Blue. Here is what that changes for our security research.

The refusal wall

Ask a frontier model to pull apart a malware sample and it will often say no. Ask it to work through an exploit path in code you own, and it may decline that too. The model cannot tell a malware analyst from a malware author, so it treats both the same way.

That default makes sense when the model has no idea who is asking. It is a real obstacle when security research is the job. Malicious packages, exploit chains, obfuscated payloads, proof-of-concept code. It all looks adversarial to a classifier.

So both labs built a way to supply that context. You verify who you are and what you do, and the guardrails relax for that specific work.

That verification step is the part worth noticing. Nobody asks you to prove who you are before handing over ordinary software. They ask when the thing they built would serve an attacker just as well as it serves you.

What defender access covers

Neither lab hands out blanket access. You apply for a tier, and the tier decides what the model will do for you. We hold the defensive tier at both.

At Anthropic that is Defense Access under the Cyber Verification Program: security operations, incident response, malware reverse engineering, and vulnerability analysis. At OpenAI it is Daybreak Blue, under Trusted Access for Cyber.

Clearing these programs means meeting real requirements. A named security contact, phishing-resistant multi-factor authentication, incident reporting inside tight windows, and ongoing obligations that do not end at approval. We are not the only security vendor to clear them, and we should not be. What separates one approved team from another is what they do once the refusals stop.

The research behind a true positive

Nearly everything our researchers do with this access comes back to one question: is this finding real?

Answering that properly means taking a vulnerability class apart to see how it behaves in actual code. What triggers it. What makes one instance exploitable and a nearly identical one harmless. Classification is its own problem. Deciding which weakness a finding belongs to gets harder once you are past the obvious cases. So is reachability, because a vulnerable function nobody can call is a finding that wastes a developer’s afternoon.

The malware work sits beside that rather than inside it. Malicious packages, obfuscated payloads, dependencies behaving in ways they should not.

None of this is new research for us. It is work that used to stall every few prompts, and now it does not.

Where our research shows up

What our researchers learn ends up in the detection logic inside the Mend SAST engine. They study a vulnerability class properly. They learn what a true positive looks like and what the convincing false positives share. Then they write that into the engine. That is how our results get better, and it is the path this access feeds.

What does not happen is your scan calling a model on your behalf. This access is for internal research, and both programs require it to stay there. We cannot resell it, proxy it, embed it, or route customer traffic through it.

That is a quieter claim than “powered by frontier AI,” and it is the true one.

Two labs, one method

Our researchers have started running both against our own repositories. Not customer code, ours. The point is to see how each model behaves on code we already understand: what it finds, what it misses, and what it costs to run.

Having both is what makes that worth doing. One model’s output is an answer. Two models on the same code is a comparison, and a comparison is where you learn which findings hold up and which ones depend on who you asked.