0sec Labs Open-Sources 0: A Three-Form AI Security Testing Tool

AI is entering the deep waters of security offense and defense, but most tools still lock model capabilities inside a cloud black box. 0sec Labs recently open-sourced an AI security testing harness called 0, attempting to use a local-first tooling system to connect code auditing, penetration testing, reverse engineering, and vulnerability remediation into a closed loop.

Three-form architecture: one foundation, three ways to use it

According to 0sec Labs' public description, 0 provides three runtime forms at the same time: a browser console (Web UI), a headless command line (CLI), and an MCP server. These are not independent tools, but different entry points sharing the same underlying security capability foundation.

The Web UI targets scenarios requiring visual interaction and is suitable for human review of AI-generated audit conclusions; the headless CLI targets automated pipelines and can be embedded in CI processes or used for batch processing tasks; the MCP server exposes 0's capabilities to AI clients that support the Model Context Protocol, allowing other agents to directly call this security toolchain.

This design approach is noteworthy: it does not package security capabilities into a closed product, but instead accommodates three consumption modes at once—human operation, script automation, and agent interoperability. For security teams, this means the same AI audit logic can be reused across different workflows without rebuilding for each entry point.

Bring your own model provider: a local-first security boundary

Another key setting of 0 is "with your own model provider." This runs counter to the current path of mainstream SaaS-based AI security products—the latter usually require uploading code or binary samples to the vendor's servers.

0sec Labs chooses to let the tool run locally, with model calls going through a provider configured by the user. For security teams handling core codebases, undisclosed vulnerabilities, or sensitive client assets, this has great practical significance: concerns about data leaving the domain are significantly reduced, and the complexity of compliance review also decreases.

It should be noted objectively that the original information does not disclose which model providers are specifically supported, whether local inference backends are compatible, or whether the functions of each form are fully equivalent. These details will directly affect how deeply it can be adopted in real security teams.

"Bring Your Own Model" (BYOM) is a model that has gradually become popular in AI tool design in recent years: the tool itself is not bound to a model, but instead exposes the interface for model calls, leaving users to fill in API keys, model endpoints, or local inference service addresses themselves. The opposite is the "black box" approach in which SaaS vendors uniformly host models—users only see input and output, not which model was used in between, whether logs are retained, or where data flows. For security teams, BYOM means that, on the one hand, they can choose model services that have already passed internal review, and on the other hand, they can fully confine highly sensitive tasks such as code auditing to a self-controlled environment. The cost is that users must bear the burden of model selection, cost control, and differences in inference quality themselves, and the reliability of the tool itself also depends more on the capabilities of the model chosen by the user.

Covered scenarios: from code auditing to reverse engineering

0 claims to cover four types of security tasks: code review, pentesting, reverse engineering, and fixes. Putting "discovery" and "fixes" in the same harness is what distinguishes it from many point security tools.

The output of traditional security tools is often a vulnerability report, and remediation is still completed manually. If 0 can complete localization, verification, and patch suggestions in the same context, in theory it can shorten the chain from alert to handling. However, AI-generated remediation suggestions still require manual review in high-risk codebases, and this will not change because of the integration of tool forms.

The existence of the MCP entry point also suggests another usage: integrating 0 as a security sub-agent into a larger automation system, allowing the main agent to call code auditing or reverse engineering capabilities when needed. Such combinations are still at an early exploratory stage in the open-source community, and their actual effectiveness remains to be verified.

Model Context Protocol (MCP) is a standardized protocol proposed and open-sourced by Anthropic at the end of 2024, used to let AI clients (hosts) discover and call external tools, data sources, and prompt templates in a unified way. MCP can be understood as the "USB-C interface on the AI application side": the server declares which tools and resources it provides, and the client can call them without writing separate adaptation code for each tool. In security scenarios, this means 0 can be connected as an MCP server to Claude, IDE plugins, or other agent frameworks, with the main agent triggering capabilities such as code auditing and reverse engineering on demand during reasoning, without manually switching tools. The limitation of MCP is that the orchestration quality of tool calls depends heavily on the planning ability of the host model, and mature specifications for cross-tool permissions and audit boundaries are still lacking.

The judgment behind the open-source strategy

Open-source security tools are nothing new, but few projects open-source an entire AI security harness. 0sec Labs' choice sends two signals: first, it hopes to expand rules and detection capabilities through community contributions; second, it treats "local operation + bring your own model" as a differentiating selling point rather than building barriers through the model itself.

For users, the direct benefit of open source is auditability—security tools themselves also need to be security-checked. A closed-source security AI tool is inherently contradictory in logic, and 0's open posture is at least more defensible at the trust level.

At present, information about 0 is still concentrated at the functional level, lacking performance benchmarks, false positive rate data, and cases from real offense and defense scenarios. When evaluating such tools, it is recommended to first conduct small-scale comparative tests using public codebases before deciding whether to introduce them into formal processes.

One-line Summary

0sec Labs open-sources the local-first AI security framework 0, integrating auditing, pentesting, reverse engineering, and fixes.

Paragraph Summary

0sec Labs has open-sourced an AI security testing framework called 0, with local-first operation and bring-your-own-model-provider as its core settings, covering four types of tasks: code review, penetration testing, reverse engineering, and fixes. The tool provides three forms—Web UI, headless CLI, and MCP server—sharing the same underlying security capability foundation and serving human review, automated pipelines, and agent interoperability respectively. Compared with mainstream SaaS-based AI security products, 0 keeps code and samples local and routes model calls through user-configured providers, significantly reducing the risk of sensitive data leaving the domain and improving the auditability of the security tool itself. However, the original article does not disclose the supported model list, performance benchmarks, or false positive rates, and actual adoption results still need to be verified through small-scale comparative tests on public codebases.