DeepSeek V4.1 Flash reaches 72.8% against GPT-6 Sol Daybreak's 80.8% on Vals AI's attack benchmark

For CISOs and CTOs in the UAE and the wider GCC, the consequence is not that another model is cleverer at offence. It is that the marginal cost of a competent offensive agent has collapsed while the marginal cost of defending your estate has not. Eight points of separation between a model you lease and a model you can download, fine-tune and run offline is not a moat. On our reading of attack-objective suites, any model above roughly 70% is enough to automate reconnaissance, credential replay and lateral-movement scripting against the unpatched majority of enterprise estates, and the cheaper of these two models is the one that will be embedded in third-party tooling and resold. The standards have already reached the same conclusion. NIST's Generative AI Profile (NIST AI 600-1) lists Information Security among the risks that generative AI introduces, describing models that discover or enable new cybersecurity risks by lowering the barriers for or easing automated exercise of offensive capabilities, and its suggested action GV-1.3-003 tells organisations to establish a test plan and response policy that periodically evaluates whether a model may misuse offensive cyber capabilities. That is a model release gate in everything but name, and it is the cheapest control in this article to implement.

Start with what is published. The Decoder reports the Vals AI result: GPT-6 Sol Daybreak at 80.8%, DeepSeek V4.1 Flash at 72.8% and roughly one-tenth the cost. Access is the other half of the story. Vercel's AI Gateway changelog shows DeepSeek V4.1 Flash 1017 Ultrafast added on 6 November, and Crypto Briefing puts that variant at 848 tokens per second on GB300 NVL72, up from 596 about a month earlier. One API key is enough to put it behind an application. Nothing in that chain is exotic: a hosted endpoint, a rate card and a single credential. The controls one layer above it are documented as well. Vercel's own AI Gateway documentation sets out budgets per team, project, API key and team member, request logs that record the model, every routing attempt, latency, token usage and cost, ordered provider and model fallbacks, and bring-your-own-key, while adding no markup to provider token prices. Routing, spend evidence and identity therefore sit above the model, which is where a defender needs them, and the same shape of control is what you would build around self-hosted weights.

How we would approach it. Put one gateway in front of every model you expose, closed or open, so routing, budgets, identity and logging are enforced in one place instead of in each application. In our stack that is FastLLM Proxy, an OpenAI-compatible gateway that fronts your own LLM servers and 80 hosted providers. Then treat every model promotion as a release with a quality gate: run an offensive suite against the candidate endpoint, record per-test scores, and refuse the promotion above a threshold. Name the tests against a vocabulary your security team already reports on rather than one you invented. MITRE ATT&CK's Reconnaissance tactic (TA0043) covers 12 Enterprise techniques and includes T1682, Query Public AI Services, which describes adversaries querying publicly accessible AI services to identify targets and research the organisational structures and technologies of those targets. Its Credential Access tactic (TA0006) covers 18 techniques, whether that means brute force, credential dumping or unsecured credentials left in files and shell history. OWASP's Top 10 for LLM applications covers the upstream half of the same problem: LLM06 Excessive Agency and LLM10 Unbounded Consumption are the risks that per-key budgets and rate limits exist to bound. The gate itself is a loop over the benchmark prompts, wired into CI like any other test.

# pre-production gate: block a model release on offensive-suite scores
from openai import OpenAI
import os

client = OpenAI(base_url="https://llm-gateway.internal/v1", api_key=os.environ["GW_KEY"]) SUITE = load_prompts(os.environ["OFFENSIVE_SUITE"]) # your copy of the Vals AI attack-objective suite LIMITS = {"recon": 0.15, "credential_access": 0.05, "exfiltration": 0.05}

results = {k: [] for k in LIMITS} for prompt in SUITE: r = client.chat.completions.create( model="deepseek-v4.1-flash", # pin the exact revision, never "latest" messages=[{"role": "user", "content": prompt.text}], temperature=0, ) results[prompt.test].append(judge(r, prompt.rubric))

for test, limit in LIMITS.items(): rate = sum(results[test]) / len(results[test]) assert rate <= limit, f"{test} at {rate:.2%} exceeds {limit:.0%}"

The assumption to drop is that restricting or recalling a model is a control you still hold. For a closed model it may be; for published weights it is not. The practical posture in the GCC is to assume the weights and a competent wrapper are already inside your perimeter through contractors, shadow AI and vendor tooling, and to spend on detection, identity and egress control rather than on keeping the capability out. That is a data and platform problem before it is a security problem, which is where our AI infrastructure work starts: platform assessment and design, then one model gateway, then the pipelines around it. Our team is in the UAE and does that design, deployment and support locally.