# Introducing Aikido Altar: the model that makes sovereign security intelligence possible > Source: > Published: 2026-09-21 13:30:00+00:00 Today, we’re introducing Altar, our first open-weight security model, built to bring frontier-grade defensive security into infrastructure you control. We took our first step toward sovereign security intelligence with our autonomous pentesting appliance Aikido Machine, which runs entirely inside a customer’s own infrastructure, including fully air-gapped environments. Teams with strict rules about keeping code in-house can continually detect, exploit, and validate vulnerabilities across their attack surface without breaking those rules. Altar provides Aikido Machine with advanced AI that defends, without sending an organization’s most sensitive context to a third-party inference service. To do this, we needed to bridge the deployment gap. Most capable open-weight models remain difficult to deploy at production scale while retaining the reasoning quality of frontier-grade models. We started with GLM-5.3, one of the strongest models in our [security evaluations](https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026). The full model occupies 1.51 TB; quantization brings that down to 488 GB, and our expert-pruning process reduces it further to 328 GB, all while preserving most of the reasoning quality of the parent model. ## The gap between frontier and open-weights models explained ### **Closed frontier models run on somebody else’s infrastructure** Using one means your source code, your internal architecture documentation, and your unremediated findings leave your network. For a bank operating under a data-residency mandate, a hospital group subject to strict data-processing rules, or an industrial operator whose OT environment has no route to the internet at all, it is not a trade-off they're allowed to make. ### **The deployment gap** Serving a model such as GLM 5.3 at full precision requires hundreds of gigabytes of unified memory and yields limited inference speed when serving parallel conversations with high context windows. In human terms, they’re enormous. Those resource demands come partly from how these models are built. Many of today's strongest models use mixture-of-experts architectures. These models are made up of a multitude of small specialized neural networks, each called an **expert**. Only a small number of experts are active for each token, while the full expert pool still has to be stored and served. **That means paying a significant memory and infrastructure cost for capacity that may contribute little to the workload you're actually running.**  Security work, such as reviewing code for vulnerabilities, proposing patches, and running a penetration test, only calls on a small slice of that expert pool. But the memory cost doesn’t shrink to match: every request still has to load the full model, whether or not it is relevant to the job. Now add agents into the mix, and the usage of context explodes, which saturates memory and leads to agents fighting each other for room. Each one keeps a running record of everything it’s seen and done, and that record sits in GPU memory alongside the model itself, growing the longer an investigation runs and multiplying across every investigation running in parallel. That’s why model size matters here: the model and all that growing context draw from the same fixed pool of memory, so more of one leaves less room for the other. The goal is to make a frontier model more efficient to operate for a specific workload, preserving the capabilities that matter while freeing capacity for everything running alongside it. ## What can we remove without losing what matters? The heavy burden of carrying so many experts into a model can be turned into an advantage with the right techniques. In order to minimize the size of open-weight models in an agentic security context while maintaining high accuracy, we used quantization and pruning. **Expert pruning** removes some of the experts from the model, typically by deleting entire expert weight blocks and adjusting the model so each token only chooses among the ones that remain. The removal itself is mechanical. Deciding which experts to remove is the hard part, and the loss can be uneven: a smaller model may retain strong coding performance while losing much of its ability to understand a particular natural language. That can leave it unable to reliably interpret documentation, business rules, or application features described in that language. To decide what to keep, we started with the most natural piece of data: traces from our pentesting harness running internal benchmarks. These capture the code, tool calls, and responses that agents work through during a full pentest, giving us representative inputs to guide expert selection. **No customer data was ever involved.** This calibration step gives us a workload-specific basis for expert selection, without training new skills into the model. The harness traces covered the technical workload. We also needed to preserve language understanding: investigating an application means understanding its features, business rules, and intended workflows, including when its documentation or interface is in French, Dutch, or another language. We therefore added multilingual text to help preserve those capabilities during pruning. ### Selection matters as much as size Many pruning techniques exist to reduce the footprint of LLMs, so we decided to go with a technique that can preserve performance for our use cases: [Cerebras REAP](https://arxiv.org/abs/2510.13999), **R** outer-weighted **E** xpert **A** ctivation **P** runing. We used REAP’s contribution score with a domain-preserving aggregation strategy selected through fidelity experiments. Counting how often an expert is selected gives only part of the picture. REAP estimates its contribution using both the router’s weighting and the magnitude of the expert’s output. We also examine contributions across different groups of examples. Otherwise, a capability that matters to a less common workload can be lost in an overall average. Cybersecurity, coding, and language capabilities are distributed across experts; there is no cleanly labeled set of “cyber experts” to keep or discard. In the supporting [compression study](https://huggingface.co/datasets/0xSero/glm-5.3-reap-fidelity-study/blob/ed76f87450bf9c05f5c3cd9c7cbb43588aa42f7f/sweep_summary.json), models retaining the same number of experts differed substantially in how closely their outputs tracked the reference model. Size alone did not determine what survived. ## From 1.51 TB to 328 GB We achieved a total 78.2% model size reduction compared with GLM 5.3 at full precision, and a 32.8% reduction compared with GLM 5.3 with an AWQ INT4 quantization. Altar retains **168 of the original 256 routed experts** in each backbone expert layer, removing 88, or **34.4%** of them. The router still selects eight per token, now from the smaller bank. The other part of the reduction comes from **quantization**. A model’s weights are the numerical values it learns during training. Quantization stores those numbers with fewer bits, trading some precision for smaller stored weights. Unlike pruning, it does not remove experts. Our starting checkpoint used [AWQ](https://arxiv.org/abs/2306.00978) to store most expert weights in four bits instead of the BF16 model’s sixteen. AWQ uses information about the model’s activity on example inputs to limit the errors introduced by lower precision. The intermediate values produced during inference, called activations, remain 16-bit: hence **W4A16**, or four-bit weights and 16-bit activations. Some weights also retain higher precision. We then applied pruning to this already-quantized checkpoint. Comparing both parent representations shows what each step contributes: That is **78.2% less storage** than the full 16-bit model. Against the already-quantized parent, pruning removes another **160 GB**, a **32.8% reduction**. ## The impact of compression on vulnerability identification capabilities We have previously built an internal [CVE benchmark](https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026) which we use to assess a model's ability to identify complex real-world vulnerabilities using our AI Code Analysis harness: **32 known vulnerabilities across 30 repositories, with three runs per case**. We ran Altar against it. Altar averaged 60.4% recall per run and rediscovered 23 of the 32 vulnerabilities at least once across three runs. In comparison, the quantized GLM-5.3 AWQ averaged 61.5% recall and covered the same 23 vulnerabilities. The original GLM-5.3 model at full precision averaged 65.6% recall and covered 25 of 32. In other words, reducing the already-quantized checkpoint from 488 GB to 328 GB, a **32.8% reduction in stored weights**, resulted in approximately a one percentage point less average recall compared with the AWQ baseline, while retaining all of its vulnerability coverage. Compared with the original parent, Altar retained 23 of its 25 covered vulnerabilities, or 92%, with a 5.2 percentage-point decrease in average recall. That’s 92% of the parent’s vulnerability coverage kept at 33% less storage. That's the tradeoff we were looking for: a materially smaller model while preserving most of the parent's security capability. We report average recall per run separately from coverage across three runs: finding a vulnerability once is different from finding it consistently. Completed runs without a finding count as misses; incomplete runs are reported separately. This measures targeted CVE rediscovery within a pipeline that uses other models for surrounding stages. It does not measure blind discovery across an entire codebase, execute exploits to validate findings, or evaluate the fix-proposal stage. Those boundaries keep the benchmark distinct from the broader pentesting workflow we are crafting Altar to support. Additionally, we deployed Altar to our Aikido Machine fleet immediately after completing these evaluations. Shortly after deployment, it identified a valid critical-severity vulnerability during a client production pentest. ## What’s next The underlying idea is broader: sovereign security intelligence should run inside any environment it protects. Altar is only the beginning. On compression, we’re exploring lower-bit formats such as [EXL3](https://github.com/turboderp-org/exllamav3/blob/0740edc2da569fb99174023c1d2988b1e98cb41e/doc/convert.md), which could let us retain more experts, alongside further H200 serving optimizations. The next step is to go beyond compression into training: fine-tuning models for security workflows, improving tool use and long-horizon reasoning, and building a **self-learning pipeline informed by our internal benchmarks to guide and shape future models**. That work will extend across vulnerability research, code analysis, remediation and other defensive security workflows. **Aikido Labs exists to keep pushing that further: models that get more capable over time without losing the constraint that matters, defenders have to be able to run them entirely inside the environments they're responsible for protecting.**  Thanks to Z.AI for GLM-5.3, Cerebras for REAP, cyanwiki for the quantized model, and [0xSero](https://x.com/0xSero) for the compression work. The public [fidelity study and keep plans](https://huggingface.co/datasets/0xSero/glm-5.3-reap-fidelity-study/tree/ed76f87450bf9c05f5c3cd9c7cbb43588aa42f7f) and [pruning toolkit](https://github.com/0xSero/model-toolkit/tree/3ee1d140efff3a3d5129fd207b9ce6eb32df88b0) provide more technical detail, without publishing raw agent conversations. Altar’s weights are available under Aikido’s organization. Altar can be deployed and served comfortably using a 4-H200s node and the latest version of vLLM. [Download Altar](https://huggingface.co/AikidoSec/altar-1) for the model card, license, serving flags and deployment instructions. Want help running it inside your own environment? Contact [Yannick](mailto:yannick@aikido.dev) to talk through deploying Altar on-prem. The approach is expanding across Aikido's product line, including [Aikido Attack](https://www.aikido.dev/platform/attack) (AI pentesting), [Code Security Audit](https://www.aikido.dev/code/code-audit) and [Deep PR Review](https://www.aikido.dev/code/pr-review).