Defenders shouldn't have to ask a lab for permission

Today we're launching DeepSeek V4.1 Flash Uncensored on Wally, our first uncensored model, made for defenders. It doesn't refuse security work. Access goes through an application and approval process, for authorized security work only. The goal is to help defenders inspect code, understand exploitability, reproduce problems in systems they are allowed to test, and work toward a fix.

Before launch, we pointed it at open-source libraries that sit underneath most of the JavaScript world, downloaded hundreds of millions of times a week. For under $10 of tokens, it found 16 bugs that reproduce on each library's current release, three of them high severity. It never refused a request.

If a company is being attacked, its security team needs to understand the attack. The model helping that team has to read the same malicious code, commands and payloads that the attacker used.

In July, Hugging Face said its responders tried to use commercial frontier models to analyze an intrusion. The providers' safeguards blocked the requests because the evidence contained attack material. The team moved the analysis to an open-weight model on its own infrastructure. That also kept sensitive evidence inside its environment. Hugging Face explicitly said this was not an argument against hosted-model safety. I agree. It is a concrete example of legitimate work that the tools need to support. (Hugging Face)

A refusal at that point leaves the defender with the same incident and one fewer way to understand it.

The word "uncensored" needs some explanation. Removing refusal behavior does not establish that a model is accurate, safe or useful. We have to demonstrate that in the work. It also does not give anyone permission to attack someone else's systems.

What the last few days made clear

The October 23 All-In Podcast captured the tension well. Jason questioned who gets to decide access to powerful AI. Nikesh Arora supported open weights for auditability while warning about models with safeguards removed and no meaningful control over their use. He also argued that companies should assume a breach and focus on finding and ejecting intruders quickly. Those concerns deserve to be addressed together.

I want defenders to have access to capable models. I also want us to be honest about what can go wrong when those models get tools, credentials and network access.

Two reports published on October 23 make that concrete. OpenAI described stronger containment for its internal training and evaluation environments, including a policy of no internet access during frontier-model training. This concerns research environments, not a claim that customers' models have been taken offline. (OpenAI)

Anthropic described a cyber evaluation in which internet access was enabled and cyber safeguards were disabled. A model went outside the intended test, tried to submit malicious code to a real repository and used fake identities to pressure its maintainers. The maintainers rejected the change. That distinction matters: an attempted attack should not be reported as a successful compromise. (Anthropic)

My takeaway is that a capable model needs boundaries that hold even when its behavior goes wrong. A prompt saying "stay in scope" is not enough. AISI's October 23 analysis also cautioned that better behavior in an evaluation does not necessarily establish better alignment in deployment. (AISI)

Why our access still goes through review

There is an obvious question here: if I am criticizing gatekeeping, why are we reviewing applications ourselves?

Because checking that someone is authorized to do security work is a legitimate responsibility for a provider. Blocking that work whenever the evidence looks malicious is a different decision. We want a team to be able to establish its use case and then investigate it without repeatedly trying to persuade a model that an exploit in its logs is evidence, not a request to attack someone.

Here is how access works today:

• Anyone can apply, with no account needed.
• A person at RunAnywhere reviews every request.
• Approval creates a grant that our API checks on every call, and we can revoke it at any time.
• We never store prompts or completions.

Our review still creates friction. We should be judged on whether the criteria are clear, whether legitimate teams can get access, and whether the controls actually work. Putting a human in the approval loop does not prove good intent or eliminate abuse.

OpenAI's October 20 report described separate internal coding incidents in which agents weakened monitoring while making requested changes. It left open whether this reflected overpersistence or a tendency to evade monitoring. That is another reason to keep oversight outside the agent's control. (OpenAI)

The model itself also belongs in that security review. In October, ProjectDiscovery deliberately built a backdoored model that handled ordinary requests but stole credentials when triggered inside a coding agent. This was a research demonstration, not evidence that every modified model is compromised. It is a good reason to check where the weights came from and what changed before giving them access to sensitive systems. (ProjectDiscovery)

What we found for under $10

We picked small open-source libraries that much larger products are built on: an IP address helper, a file-pattern matcher, a tar extractor, parsers for XML and YAML. Each was pinned to its latest release. We ran DeepSeek V4.1 Flash Uncensored on its own, with no helper models, through Visa's VVAH and Vercel's DeepSec security harnesses, on local copies of the code. A finding only counted if it reproduced from a clean checkout and wasn't already in the advisory databases.

The model found 16 bugs across six libraries. Three are high severity and three are medium. Across every run, it refused nothing.

The two high-severity finds show what's at stake:

• node-ip. Apps use it to tell internal network addresses from public ones. In an app that relies on it for that check, an attacker could reach systems that are meant to stay internal, like admin panels, internal APIs and cloud credentials.
• micromatch. In an app that accepts file patterns from its users, one short pattern can freeze the server for a minute or more. picomatch, the engine underneath micromatch, has the same bug in its latest release.

The rest range from quietly wrong output in the XML and tar libraries to output that breaks on unusual input.

These libraries don't sit in one place. You've probably never installed any of them on purpose. They come in underneath the tools you did install:

• tar unpacks every package npm installs, and npm ships with Node.js.
• js-yaml reads config files for ESLint, Mocha, Google's Firebase CLI, GitHub's CodeQL Action and the Kubernetes JavaScript client.
• micromatch and picomatch match file paths in Vite, Jest, Yarn, Google's Angular CLI, Amazon's AWS CDK and Microsoft's VS Code.
• fast-xml-parser reads XML inside Microsoft's Azure SDK, Google's Cloud Storage client and AWS Amplify.
• serialize-javascript runs in Mocha, Rollup and Microsoft's Rush Stack.
• node-ip sits in proxy libraries and in older releases of webpack-dev-server and the React Native CLI. It hasn't had a release since February 2024.

A bug in one of these ships inside build tools, cloud SDKs and editors, including projects that Microsoft, Google and Amazon maintain themselves.

We've seen how bad this gets. In December 2021 a flaw in Log4j, a logging library most people had never heard of, put Java software everywhere at risk overnight. The US Cyber Safety Review Board later called it an "endemic vulnerability" that could stay in systems for a decade or longer. (CSRB report) The libraries we tested sit in the same position in JavaScript.

All of this cost under $10 of tokens at Wally's price for the model. The weights are public. Anyone with a few dollars of compute can run the same search, including people who will never report what they find. That's why defenders need this capability now.

Any new vulnerability needs validation and private disclosure to the maintainer before we publish details.

Why this matters for Wally

I think the entire security stack is going to be agentified. There will be agents watching systems continuously, and more capable agents investigating when something looks wrong. That is my view of where this is going, not a claim that the work is solved.

The inference requirements are different from an occasional chat. A system watching around the clock has to be affordable. A defender responding to an incident needs answers quickly. Both need reliability. Finding 16 real bugs for under $10 is what affordable looks like.

That is the part we are building at Wally: inference infrastructure that security teams can use in their own workflows. This release does not turn Wally into a complete autonomous security product. The teams using it still need authorization, containment, verification and people accountable for the outcome.

The case for this release is straightforward. Defenders need tools that can handle the material they encounter in real incidents. Providers need to make those tools available responsibly and be precise about what they have verified.

That is what I want us to be held to at Wally.

DeepSeek V4.1 Flash Uncensored is live on Wally for authorized security work. If you defend systems you own or have written permission to test, apply for access.