Inference.net Unlocks DeepSeek V4.1 Flash for Security Teams Behind Gated Access

Inference.net has placed a refusal-removed DeepSeek model behind a team-level approval process that it describes as know-your-customer verification. The release, deepseek-v4.1-flash-1017-cyber, is the first entry in its Cyber catalog, which gives approved teams hosted access for authorized security research, safety testing, and trust-and-safety work.

The release combines an existing open checkpoint with production hosting, human-reviewed access, US infrastructure, and contractual restrictions. Its reduced refusal behavior allows tasks such as exploit development and phishing simulations that commercial model APIs often block, even when users have authorization to test the target systems.

An open checkpoint, managed

The model uses the October 2026 DeepSeek V4.1 Flash checkpoint with its refusal behavior removed. Its weights come from the open mrfakename/DeepSeek-V4.1-Flash-1017-abliterated release on Hugging Face. Inference.net supplies the hosted service, access review, and usage controls.

Approved developers retain the underlying model’s multimodal input, tool-calling support, long context window, and OpenAI-compatible API. Existing clients can select the Cyber release through the API’s model field after the associated team receives approval.

At-cost pricing, team-level approval

Pricing matches the standard DeepSeek V4.1 Flash 1017 service. Inference.net describes the Cyber tier as being served at cost.

Each team must submit a request and receive human approval before calling the model. Unapproved requests return HTTP 403, decisions arrive by email, and granted access reaches the API within 45 seconds, according to the Privileged Access documentation.

Approval applies to one team and one model. Access to this release does not carry forward automatically to later Cyber models, so organizations will need separate approval for each checkpoint.

Four permitted use cases

Inference.net permits the model for four categories of work, each subject to ownership, authorization, consent, and applicable law:

• Red-team and safety evaluation: Generate adversarial prompts and harmful examples to test AI systems that the team owns or is authorized to assess.
• Defensive security research: Write exploit code, phishing simulations, and attack tooling for systems the team owns or has written permission to test.
• Trust-and-safety development: Produce labeled abusive, hateful, or violent examples for moderation systems and classifiers.
• Dark or mature fiction: Create fictional adult material, including explicit sexual content, when it involves consenting, non-real adults and is distributed only to adults where lawful.

Approval never grants permission to probe third-party systems. Teams remain responsible for obtaining written authorization and limiting generated tooling to the approved environment.

The Privileged Access Terms prohibit several categories regardless of approval:

• Child sexual abuse material
• Assistance that increases a user’s ability to create or deploy weapons of mass destruction
• Sexual content involving real people
• Deepfakes

How abliteration suppresses refusals

Abliteration is a weight-editing technique that identifies internal activation patterns associated with refusals and removes or suppresses them. The resulting model becomes less likely to answer with stock refusals such as “I can’t help with that,” without requiring a conventional fine-tuning run.

The method is inexpensive and has circulated through open-model repositories for years. Inference.net’s contribution is a managed deployment with formal access controls, contractual limits, and SOC 2 Type II infrastructure.

Benchmarks remain an open question

Inference.net has not published separate benchmarks for the modified weights and points users to results from the underlying DeepSeek V4.1 Flash 1017 model. Weight edits can introduce subtle changes in reasoning, instruction following, tool use, and output reliability, even when broad benchmark scores appear stable.

Teams evaluating the model for automated security work should test it against representative internal tasks before deployment. Useful checks include:

• Exploit correctness and reproducibility
• Hallucinated dependencies, APIs, and vulnerabilities
• Tool-call accuracy and argument formatting
• Instruction following across long contexts
• Refusal rates on authorized tasks
• Compliance with prohibited-use boundaries
• Latency and cost under expected workloads

Why hosted access changes the equation

Commercial model APIs often reject the prompts that make an exploit-development assistant or phishing simulator useful. Self-hosting open weights can restore that capability, but a 552-billion-parameter Mixture-of-Experts model with a 1-million-token context window requires substantial infrastructure and operational expertise.

Serving the checkpoint through an OpenAI-compatible API removes much of that infrastructure burden. The approval process, US hosting, default Zero Data Retention, and model-specific permissions give security teams a controlled route to capabilities already available through open weights.

Inference.net says additional Cyber releases will arrive over the next several weeks, positioning the service as a continuing product line. The product announcement suggests that future checkpoints will use the same combination of reduced refusal behavior and team-level access review.