Two Consortia Filed for Korea’s National Security-AI Programme. There Used to Be More.

On 26 August the submission window closed for Korea's Cybersecurity-Specialised AI Foundation Model programme. Two consortia filed: SK Telecom and Naver Cloud. The interesting part is that the number of teams preparing was never two.

The deadline slipped by five days

The original close was 21 August. It moved to the 26th, and in those five days the field settled. KT ultimately did not file. What remains is an SK Telecom consortium and a Naver Cloud consortium.

From the outside this reads as a two-horse race. What actually happened looks less like competition and more like consolidation.

Separate preparations converged

VIDRAFT was preparing for this programme too. We had formed our own consortium, recruited members, and were building out the proposal structure.

Then we changed our judgement. A security foundation model is not the kind of problem one team wins by being good at it. So we joined the Naver Cloud consortium together with the partners who had been preparing alongside us. Instead of filing under our own name, we put what we had built into the larger effort.

And just before the deadline, the LG consortium joined the Naver Cloud consortium as well.

With three separate preparations converging into one, the Naver Cloud consortium became an alliance of more than thirty organisations — carriers, cloud, specialist security firms, universities, research institutes, and public agencies inside a single proposal.

Why consolidating is the rational move

A security model does not get built when the data is scattered.

A general language model can cover a great deal of ground with public web text. Security cannot. Real intrusion logs, malware samples, vulnerability analyses, SOC histories — none of that is public, and no single company holds all of it. If each party builds a model from its own fragment, you get three partial models.

Splitting the consortium is splitting the data. That is why we judged the merged result better than holding onto our own bid.

What we brought

Our role in the alliance is not to make the model bigger. It is to verify that the model, once built, actually is what it claims to be.

Two days ago we published The Mask Is Not the Model (arXiv:2608.22876) — a method for determining whether a released model is reading the future.

An autoregressive model is only meaningful under one constraint: the representation at position t depends on positions ≤ t and nothing else. The industry has checked this by inspecting the attention mask. But modern stacks interleave attention with state-space scans, recurrences, and convolutions. A scan has no mask.

Our audit is two forward passes. Feed two inputs that differ only at the final position, hook every layer, and see where the earlier representations start to diverge. The first layer that moves is where the future leaks in. No training, no gradients, no accelerator — it runs on a CPU in seconds.

Run against released checkpoints, it found real leakage on the PyTorch execution path of NVIDIA's Nemotron-H and Zyphra's Zamba2. The onset length matched each model's declared chunk size exactly — 128 and 256. The cause was a single reduction over the wrong tensor axis.

Why this matters more in security

Causal leakage does not crash.

When information from position t+1 reaches position t, next-token prediction gets artificially easier. Training loss goes down. Perplexity goes down. Benchmark scores go up. Every needle on the dashboard reads "better."

So the defect inflates the very numbers you use to choose a model. Among candidates, the broken one looks like the safer bet.

In a security model the failure changes character. A slightly lower benchmark score is one thing. A system that emits confident, plausible, well-scored judgements about threat posture while computing something other than what its architecture declares is a different category of incident.

That is why our diagnostic system, AX-RAY, holds one line and does not negotiate it:

A causal-leakage finding cannot be overridden by a good benchmark score.

Not "weighed against." A correctness failure is a gate, not a term in a weighted sum. If the implementation is not causal, the benchmark number describing it is not a measurement of anything usable.

Capability and correctness are two different claims. The industry has built enormous machinery for the first and almost none for the second.

What's left

Selection results are not out. What we know ends here: preparations that were scattered came together, and the seat we took inside that is not "build a good model" but "prove the model is right."

Two forward passes. Seconds on a CPU. There is no cost argument against it.

Nobody has been asking, that's all.

Paper arXiv:2608.22876 · AX-RAY huggingface.co/spaces/FINAL-Bench/AX-RAY · VIDRAFT vidraft.net