Belgian cybersecurity company Aikido has released Altar, an open-weight artificial-intelligence model customized from Z.AI’s GLM-5.3 for cybersecurity work. The central promise is deployment: organizations can run the model within their own environment to analyze sensitive source code and security context rather than submitting that material to an external AI service. Reuters reported that Aikido is deploying the technology in products used by customers including Belgian bank Belfius. [1]
That distinction matters more than the arrival of another coding or security assistant. Security teams routinely work with proprietary code, internal architecture diagrams, credentials-adjacent configuration files, incident evidence and unpatched vulnerability details. For many regulated or security-sensitive organizations, sending that material to a third-party model provider remains a governance obstacle even when the potential productivity benefits are clear. Altar is an attempt to shift that boundary by bringing the model to the code, rather than moving the code to the model.
Why local deployment changes the security-AI equation
Generative AI can assist application-security teams with tasks such as explaining unfamiliar code, tracing user-controlled input through an application, proposing secure alternatives, prioritizing findings and drafting remediation guidance. But the usefulness of those tasks depends on context. A model often needs more than an isolated code snippet: it may need to inspect repositories, dependency manifests, infrastructure configuration, build settings and the business logic that determines whether a suspicious pattern is actually exploitable.
That same context is often among a company’s most protected information. Uploading it to an externally hosted service can raise questions about data residency, retention, training use, access controls, contractual liability and cross-border transfer. Even where a vendor offers enterprise privacy terms, some organizations have policies or regulatory obligations that favor keeping material in infrastructure they control.
An open-weight model does not automatically solve every one of those issues, but it gives customers a meaningful deployment option. In a local installation, an organization can place the model on its own servers or in a cloud tenant it administers, connect it to internal code-management and security systems, and control the network paths available to it. The relevant security boundary becomes the customer’s operating environment, not a public inference endpoint.
This is especially relevant in banking and other heavily governed sectors. Belfius’s use of products incorporating the model is therefore a practical signal that Aikido is targeting environments where data control is a prerequisite for adoption, not a secondary feature. Reuters did not disclose the scope of Belfius’s deployment, the model’s performance results, or the precise infrastructure configuration. [1]
What “open-weight” means—and what it does not
Open-weight refers to the availability of a model’s learned parameters, or weights, for others to download and run. It is distinct from merely having an API, where a provider runs the model and customers submit prompts to it. With access to weights, a company or its security vendor can operate inference on chosen hardware, tune the serving stack, apply its own access controls and, subject to the applicable license, adapt the model for specialized use.
Aikido said Altar is customized from Z.AI’s GLM-5.3 model. That suggests a base-model-plus-specialization approach: a general-purpose language model is adapted for security workflows, potentially through fine-tuning, instruction tuning, curated security examples, tool integration or a combination of those methods. The reported announcement does not provide a parameter count, benchmark methodology, training-data description, licensing terms, hardware requirements or independent evaluation results. Those omissions make it too early to compare Altar directly with proprietary coding models or other open-weight models on accuracy, cost or vulnerability-detection performance.
The distinction is important because a cybersecurity model should be judged on more than its ability to produce plausible-looking code commentary. In practice, useful evaluation would test whether it can identify relevant flaws with acceptable false-positive rates, reason across multiple files, distinguish exploitable issues from low-risk patterns, generate patches that preserve application behavior, and accurately state uncertainty when evidence is incomplete.
It should also be assessed as part of a system rather than as a standalone chatbot. A security assistant becomes materially more capable when it can retrieve the right repository context, read results from static analysis and software-composition tools, query issue trackers, and produce auditable links to the evidence behind its recommendations. Conversely, poorly constrained tool access can create a new route for data exposure or unsafe automated changes.
Local models move responsibility to the buyer
Running a model locally can reduce exposure to an outside inference provider, but it is not synonymous with secure operation. Organizations must secure the model-serving infrastructure, identity and access controls, source-code connectors, logs, prompt histories, embeddings and backup systems. They also need to determine whether prompts or outputs are retained and where monitoring data is sent.
There are model-specific risks as well. A model can hallucinate vulnerabilities, misunderstand proprietary frameworks, recommend insecure patches or be manipulated by instructions embedded in code comments, documentation or tickets. This last category, commonly called prompt injection, is particularly relevant when an AI system reads untrusted repository content or external advisories. Local hosting changes where the data resides; it does not eliminate the need to treat model inputs as potentially adversarial.
For that reason, the most defensible early uses are likely to be advisory: triaging findings, summarizing code paths, explaining dependency risk and drafting remediation proposals for human review. Automatically merging security changes, altering production configuration or acting on model-generated severity decisions requires stronger controls, testing and approval workflows.
Cost is another trade-off. Hosted models concentrate the expense of accelerators, inference optimization and model operations with the provider. Self-hosting can give an organization predictable control and potentially lower marginal cost at sufficient scale, but it requires hardware capacity, deployment expertise, patching and observability. For some customers, a managed deployment in a dedicated private environment may remain more practical than operating the complete stack themselves.
Aikido’s market position and the broader shift
Aikido enters a security-AI market in which code-analysis vendors, developer-platform companies and foundation-model providers are all adding generative interfaces. Many of those offerings are delivered as cloud services. Aikido’s differentiation, based on the announcement, is not that AI can assist security work—an increasingly common claim—but that the underlying model can be deployed in a customer-controlled environment.
That positioning aligns with a broader enterprise demand for models that can run close to sensitive data. The appeal is strongest where repositories contain regulated information, intellectual property, national-security-relevant software or material that cannot readily leave a controlled network. It may also matter for organizations with strict data-sovereignty policies or limited tolerance for vendor concentration.
Open weights can create a different form of vendor relationship rather than eliminating vendors altogether. Customers may still rely on Aikido for the security workflow, model packaging, updates, integrations and support. The practical question is whether the customer retains control over code and inference data while receiving a product that is easier to operate than a do-it-yourself model stack.
The move also places pressure on hosted AI providers to make their data boundaries more transparent. Clear answers on retention, training use, isolation, geographic processing, audit logs and private-network connectivity will increasingly determine whether a security team can approve an AI feature. In that sense, locally deployable models may expand the addressable market for AI-assisted security work even if cloud-hosted products remain technically strong.
What customers should ask before deploying it
The Altar announcement establishes a deployment proposition, not a complete security case. Prospective users should seek technical and contractual detail before using any local model against production repositories.
- Data flow: What code, metadata, prompts, outputs and telemetry leave the customer environment, if any?
- Model provenance: What license applies to the base model and Aikido’s customization, and what restrictions govern commercial use or redistribution?
- Evaluation: Which security tasks were tested, against what datasets or real-world findings, and how were false positives and missed vulnerabilities measured?
- Operational controls: Can administrators restrict repository access, isolate network egress, manage retention and produce audit records?
- Human oversight: Which actions are suggestions only, and which—if any—can modify code, tickets or security settings?
The answers will determine whether local deployment is a meaningful control or simply a different installation method. A credible implementation should give teams evidence they can present to security, legal, compliance and engineering leaders—not just an assurance that the model is private.
What to watch next
The next test for Altar will be evidence of operational capability. Customers will want to know how it performs on multi-repository applications, whether it can work effectively with existing scanners and developer tools, what infrastructure it needs, and how Aikido maintains model and security updates. Independent testing would be particularly valuable because vulnerability detection is susceptible to demonstrations that look persuasive while failing on noisy, real-world codebases.
More broadly, the release reflects an emerging split in enterprise AI architecture. Some workloads will remain best served by large remote models with broad capabilities and fast provider-led improvements. Others—especially work involving crown-jewel code and active security incidents—will favor local or tightly isolated deployment even if that means accepting a narrower model, more operational overhead or slower upgrades. Aikido is betting that application security belongs increasingly in the second category.
Editor’s Take
I think the important product decision here is to make deployment part of the security proposition. Security teams do not lack demos of models that can summarize a function or suggest a patch. They lack an easy way to use that capability on the repositories they are least willing to upload. If Altar can be installed with disciplined access controls and useful integration into the tools teams already use, that removes a real adoption blocker.
I would watch for benchmark detail, deployment requirements and proof that the model improves triage or remediation without flooding engineers with confident but wrong findings. “Open-weight” is valuable control, not a magic security property. The companies that win this market will make local operation genuinely manageable while showing, with evidence, that the model earns a place in a human-reviewed security workflow.
References
- Reuters, via MarketScreener – Belgium’s Aikido launches cybersecurity AI model as demand for local tools grows
