A smaller local security model changes the deployment boundary, not the validation burden
Aikido compressed an open-weight coding model for local security work and published a narrow CVE benchmark. The architecture may reduce data movement, but buyers still need an acceptance test for their own repositories.
What happened
Aikido released Altar, a compressed open-weight model intended for local cybersecurity analysis.
Why it matters
Local execution can change privacy and sovereignty controls without proving vulnerability coverage, exploitability or fix quality.
Belgian security company Aikido released Altar, an open-weight cybersecurity model derived from GLM-5.3. The vendor says it removed 88 of 256 experts and reduced the model to 328 GB, compared with 1,506.7 GB for the full-precision parent. Reuters reported that the design is intended to let customers run the model in their own environment rather than send sensitive code to a remote service.
That architecture changes an important control boundary. Local execution can reduce code movement, support data-residency requirements and give operators more control over logging and access. It does not establish that the model finds the vulnerabilities that matter in a particular codebase.
Read the benchmark literally
Aikido reports a benchmark of 32 known CVEs across 30 open-source repositories, with three runs per case. Altar averaged 60.4% recall and found 23 of 32 vulnerabilities at least once. The quantised parent averaged 61.5% and found the same 23; the full model averaged 65.6% and found 25. The vendor explicitly says the test measures targeted rediscovery of known CVEs, not blind discovery across an entire repository, exploit execution or the quality of proposed fixes.
Those boundaries are valuable. They prevent a narrow recall result from becoming a claim that the system can replace a security review. They also show what an enterprise test must add.
Build an acceptance set
Start with repositories that resemble production in language, framework, size and dependency structure. Include confirmed vulnerabilities, clean code, insecure patterns that are not exploitable, and changes that previously caused false alarms. Measure recall, precision, time to useful evidence, duplicate findings, severity calibration and whether a reviewer can reproduce the path. Test the exact quantisation, prompts, tools and hardware that will be deployed.
Treat local operation as one security control, not the product outcome. Verify model provenance, licence, update process, isolation, access rights and audit logs separately from detection quality. A smaller sovereign model may be the right design for sensitive code, but the purchasing decision should turn on the local workload and failure cost, not on the word “local” or a vendor benchmark alone.