In 2026, the rapid spread of OpenClaw touched off a Cambrian explosion of agents: autonomous AI agents, Coding Agents, and Security Agents with a measure of real autonomy are all growing fast. Many of them chose the open form — open-weight models, open-source agent frameworks, with “transparent and auditable” written into the marketing. During the AVL Code alpha, some users put the question to us: and you — why aren't you open source?
Our answer is direct: AVL Code respects open source, and the product itself stands on the shoulders of countless open-source projects. But for a security agent that faces the adversary head-on, we chose closed source. This is not a rejection of “transparency”; it is a necessary restraint on a double-edged sword. Here are our four reasons.
1. An Agent Is Capability, Not Scaffolding in the Traditional Sense
The modern echo of Linus's Law goes: “Open-source the agent, and a large enough community will polish it safer for you.” That may hold for a development scaffold — a bug in a code generator is, in the end, just a bug: one more pair of eyes, one less defect.
But a security agent is not scaffolding in the traditional sense — we have argued before that a “specialized harness” built for a specific battlefield beats a bigger, fuller general-purpose one. What it embeds is detection logic, attack knowledge, triage models, and response capability — the agent itself is capability, and capability is inherently two-way. The same body of knowledge for “identifying malicious behavior” is, read in reverse, a map of “how to evade identification”; the same orchestration for “automated sample triage” becomes, with a swapped prompt, an assembly line for “automated production of detection-evading samples.” A vulnerability is merely one special kind of bug an attacker can exploit; in a security agent, the whole thing is dual-use.
Hence our first principle: a security agent must limit and restrain itself. It needs guardrails, capability boundaries, and blocked paths to its own misuse. To open-source such a double-edged sword indiscriminately is to hand over both sharpened edges at once — and attackers are never polite enough to take only the defensive one. This is also why, when one and the same agent can both write code and turn a requirements mind-map into an enterprise-grade system end to end and triage a real malicious sample, we designate samples/ a read-only analysis zone where execution tools are force-disabled — a line that does not slacken even with unrestricted mode switched on. Give the AI freedom; never hand over the steering wheel.
2. Asymmetry Is What a Security Agent Stands On
The sharpest blade in any adversarial contest is asymmetry: an intrusion is, by nature, a process in which the scales of information tip steadily toward the attacker. A closed-source system holds a double asymmetry over the attacker — system-level and configuration-level — while open source disarms itself, ceding the system layer and keeping only configuration.
A security agent hones that blade sharper still. An agent's entire value lies precisely in its asymmetric knowledge over the attacker — its detection signatures, heuristic thresholds, behavioral baselines, triage weights. Once the source is open, what the adversary reads is not “a piece of software” but the detector's complete decision criteria, ready to be tuned against and bypassed (adversarial samples, detection evasion, prompt-layer circumvention). We felt this most keenly when reconstructing adversarial samples like the steganographic payload the Darkhotel group hid inside a JPEG: the real value was never in “being able to analyze it” but in the triage logic the attacker cannot read — open-source that, and you send out the answer key stapled to the exam. This is exactly what it means to collapse “binary-level vulnerability hunting” down to “source-level hunting” — you believe you are ceding transparency; what you are actually ceding is the asymmetry you live by.
Someone will quote Bruce Schneier: “Public security is always more secure than proprietary security.” But mind the boundary of that claim: it applies only to the narrow domain of cryptographic algorithms, security protocols, and security source code, where mathematical provability exists, mainstream algorithms are few, codebases are small, and implementations are vetted through standardized reuse. An adversarial detection strategy is not an algorithm with provable security — it is an empirical, evolving knowledge base locked in a live game with its opponents. Stretching Kerckhoffs's principle (security should rest on the key, not on the secrecy of the algorithm) over detection strategy is a dangerous category leap. We hold to closed source not out of a “secrecy equals security” superstition, but out of a refusal to publish, as if it were an algorithm, something that never belonged to the algorithm's domain.
3. Commit to the Binary Before You Talk Supply Chain Trust
There is a question no one has ever truly answered: how do you prove the shipped binary matches the source? The 2024 xz-utils backdoor (CVE-2024-3094) laid the answer on the table — a maintainer “benign” for years hid a lethal payload, primed to fire only under specific conditions, inside test files, in the open the entire time, and it came within a hair of riding the distributions into every Linux machine on the planet. Constructions like this cannot be adjudicated at the level of code logic at all; even once caught, no one can prove the burial was deliberate. Open-source transparency does not stop a patient, malicious committer.
So we moved the anchor of trust from “readable source” to “verifiable release”: we commit to the compiled binary form, backed by certificates and signatures, as the supply-chain foundation of our releases. This is not a step backward; it is facing a fact the open-source narrative has long sidestepped —
Open source cannot guarantee consistency with the released binaries, because almost no user takes the “audit the source, compile it yourself” path to deployment.
What the vast majority of people pull down are precompiled packages, images, weight files. The promise that “you can audit the source” is theoretical; what you actually run is a binary you never compiled with your own hands from any source you audited. That gap between trusted source and what actually runs is exactly where supply chain attacks make their home. This is no abstract worry — we ourselves used AVL Code to reverse engineer the released build of a popular tool, checking whether it hid client-side behavior invisible from the documentation, and questions like that usually come clear only once you crack open the binary. Reproducible Builds do exist, but the bar is high and the verifiers are few. That being so, the real security gap between a “closed source + strong signatures + trusted release chain” path and an “open source + binaries nobody reproduces” path is far smaller than the slogans claim — and it is the signature and the certificate that actually hold the floor. In AVL Code, this takes concrete form: skill-package signature verification with national crypto SM2 / SM3, local credentials encrypted and bound to the machine ID, and a release chain we hold in our own hands.
And open source lowers the bar for counterfeiting along the way: with the full source in hand, editing in a payload and recompiling a convincing “release” costs next to nothing; add the reality that nobody compiles from audited source anyway, and these trojaned lookalikes circulate in broad daylight. Software “given a facelift” and stuffed with a trojan is nothing new; but as the battlefield moves from installers to model weights, extensions, and agent toolchains, it will only get faster and stealthier.
4. In the AI Era, the Open-Source Explosion Favors the Attacker
The open-source community is often imagined as “the eyes of the whole world,” as if attention flowed automatically to every line of code. The reality is wildly uneven — “the many eyes” dote on a handful of star projects, while the great majority of security-critical components go unexamined for years. And when every model, every agent framework, every toolchain ships open source by default, that dilution is pushed to its limit.
In fairness: the long strides projects like Linux and Firefox have made in security are real. But their essence is not that “openness” automatically converted into security; it is that on top of the open source grew systematic, rigorous, high-caliber community operations — stable maintainer rosters, disciplined response processes, sustained funding and staffing. The problem is that these operations can only be afforded by a few large, famous projects. Heartbleed in 2014 was a slap across the face: OpenSSL underpinned a vast share of the internet's sites and devices, yet a fatal vulnerability lurked for roughly two years — and until it blew up, the project was maintained by a tiny team scraping by on scattered donations. If even OpenSSL cannot win security attention commensurate with its importance, then “enough eyeballs” never show up on their own.
Here hides the most misread link in the chain. The age of the open-source explosion has produced not a beneficial gathering of security resources, but a convenience for attackers' vulnerability hunting. Benevolent, professional attention does not descend on its own — it is diluted across millions of repositories and never truly focuses on any one security-critical component. On the attacker's side, though, the gathering is happening for real: they scan open source systematically, diff patches in bulk, and now run LLM-assisted code audits that read your source at scale, automatically. An old metaphor puts it well: a flower may grow in the open field, but its visitors are not only bees — pests come too. Now that large models have turned “enough eyeballs” into cheap compute for the offense, the pests drawn to an open flowerbed work far harder than the bees.
In the end, open-source transparency does give users one thing — a “felt sense of safety” that no closed system can deliver through a user agreement, and we acknowledge that value. But today's reality must be appended: in the overwhelming majority of customer scenarios, that safety is psychological, not actual — because customers neither read the source through nor compile from source they have audited. Meanwhile the convenience the same transparency creates for attackers is actual, cashable, and far greater. Transparency is a balance scale: on one side, a “right to audit” users almost never exercise; on the other, a “read to your heart's content” attackers exercise immediately.
Real security comes from effectively concentrating benevolent, professional attention. Our answer is to internalize that focus — sustained investment by our own red team and our own researchers, and our signature binary-triage craft (hashing and entropy, IOC extraction, PE / ELF / Mach-O parsing, disassembly, YARA matching) built directly into the agent — rather than hoping a crowd's goodwill shows up on its own. The logic is plain: it is the non-open-source side, with a sustainable business model in place first, that can shoulder the larger security cost.
Closing: Keep the Blade Pointed at the Side It Should Face
The whole “open source equals security” argument rests on three premises: the publisher is benevolent, the users are innocent, and the attacker is not among them. For a security agent, the third premise is structurally broken — its adversaries are by definition among its users, and attackers will be first in line to take it, study it, and counter it. This is exactly what sets a security agent apart from all general-purpose software, and the root of why the open-source logic of general-purpose software cannot simply be copied over.
One more thing must be said: closed source is not hostility toward open source. Antiy respects open source and is itself a participant and beneficiary — we have released open-source code of our own (such as APM), sponsored open-source security projects like Androguard, the Android reverse engineering framework, and supported Software Freedom Day for years running. It is precisely because we stand inside it and know its true grain that we see all the more clearly: open source is a remarkable way of collaborating, but it is not a synonym for security — and it should never be the default delivery form for an adversarial security agent.
So, we chose closed source:
- Not to refuse oversight, but to replace “auditable source” with “verifiable releases” — certificates, signatures, third-party audits, a public methodology; the one thing withheld is the detection core that can be circumvented once read;
- Not to manufacture mystery, but to preserve the asymmetry an adversarial tool must keep over its attackers;
- Not to lock capability away, but to bind a double-edged sword to its own restraints.
For general-purpose software, open source can be a friend of security; for a security agent that faces the adversary head-on, transparency is itself a surrender of asymmetry. We chose closed source to keep the edge of this double-edged sword pointed, always, at the side it was meant to face.
We'll be waiting for you in AVL Code — riding a donkey, closed source, blade turned toward the dragon.
AVL Code — the AVL security engine, with intelligence at your side. From the Antiy Landi team.