Wiz Atlas Uncovers Over 200 Vulnerabilities

Google-owned cloud security company Wiz recently unveiled Atlas, an AI-powered vulnerability discovery system. Rather than asking a single large model to read code from scratch, guess at vulnerabilities, and write reports, Atlas breaks security research into a multi-agent pipeline: some agents understand the code, some propose attack hypotheses, others challenge them, and the system ultimately builds an environment, executes attacks, and confirms vulnerabilities.

As of July 29, Wiz says Atlas has discovered and validated more than 200 security issues across several well-known open-source projects and earned a total of $100,000 in GitHub bug bounties. According to the CyberGym benchmark results published by Wiz, Atlas scored 90.9%, outperforming systems including GPT-5.5-Cyber, Claude 4.6, and Claude Mythos Preview.

Those figures are eye-catching, but what makes Atlas truly noteworthy is not that it is yet another specialized security agent. Rather, it presents an engineering approach that more closely resembles a real-world security team: the model is no longer treated as an omnipotent black box, but placed within a system that combines static analysis, program graphs, role-based checks and balances, and executable validation.

Not One AI Security Expert, but an AI Security Team

Traditional single-agent approaches usually follow a straightforward path: give the model the code or repository, ask it to find vulnerabilities, and then have it produce an analysis and remediation recommendations. This works well for demonstrations, but it can easily break down in real-world codebases.

The reasons are not complicated. Large projects may contain millions of lines of code, complex dependencies, build scripts, privilege boundaries, and cross-module calls. The model must understand not only each local function but also how data flows from external input all the way to dangerous operations. A larger context window does not mean the model can reliably maintain a complete and accurate map of the program.

Atlas addresses this by first breaking the task down.

According to Wiz, its workflow broadly consists of the following stages:

1. Understand the target and build a threat model: Identify the software’s exposed entry points, critical assets, trust boundaries, and potential attacker capabilities.
2. Build a code property graph: Organize syntax structures, control flow, data flow, and function call relationships into a queryable program graph.
3. Generate vulnerability hypotheses: Have multiple agents independently search for potential attack entry points and exploit chains, rather than relying solely on a single model’s initial judgment.
4. Conduct adversarial review: Three agents respectively take on the roles of supporting the case, challenging the analysis, and making the final decision.
5. Set up a test environment: Automatically install dependencies, compile the project, and prepare the conditions needed to trigger the vulnerability.
6. Perform attack validation: Generate attack inputs or proof-of-concept programs to confirm whether the issue can be reproduced in a real environment.
7. Produce a vulnerability report: Only candidate issues that pass execution-based validation are included in the final results.

This architecture resembles not a chatbot, but a security research team with clearly defined responsibilities. One researcher proposes a hypothesis, a colleague attempts to disprove it, and a lead decides whether to report it based on code evidence and reproduction results.

Here, multi-agent design is not about having several models hold a lively meeting. It is about creating controlled cognitive conflict. Security research particularly needs this kind of conflict, because the most dangerous behavior of large models is not that they do not know something, but that they can generate a remarkably complete explanation for an incorrect judgment.

The Code Property Graph Is Atlas’s “Map”

Another key component of Atlas is the Code Property Graph, commonly abbreviated as CPG.

Simply splitting source code into chunks and feeding them to a model is essentially like asking the model to read a stack of engineering documents with some of the page numbers scrambled. A code property graph instead links the abstract syntax tree, control-flow graph, data flow, and call relationships, allowing the system to answer more specific questions: Can an HTTP parameter reach a command-execution function without validation? Can a low-privilege interface reach a high-privilege operation through a sequence of calls? Can a particular validation check be bypassed through another control-flow path?

This is especially important for finding compound vulnerabilities.

Many high-value vulnerabilities do not appear as an obviously incorrect line of code. Instead, they require a combination of conditions: an attacker first taints a configuration field, then triggers an asynchronous task, and subsequently exploits a flaw in privilege checks to make malicious data reach a dangerous function. Each step may appear reasonable on its own; only when connected do they form a complete attack chain.

Static analysis tools excel at tracing paths according to deterministic rules, but they can struggle with business semantics and complex exploitation conditions. Large models are good at interpreting intent and proposing hypotheses, but they may misunderstand actual call relationships. Atlas’s approach is to use the CPG as a structured map, have models infer attack routes, and then use an execution environment to verify whether those routes are actually traversable.

This is a more pragmatic choice than simply increasing model size.

Three Agents “Argue” to Address False Positives

Automated vulnerability scanning has always faced an unavoidable problem: finding 10,000 suspicious points is not difficult; proving which of them can actually be exploited is.

Traditional SAST tools often produce large numbers of alerts. At the rule level, all of these alerts may be justified, but development teams eventually discover that many are already protected by upstream validation, runtime configuration, privilege boundaries, or framework mechanisms. Once false positives become too numerous, the scan report turns into a backlog that no one wants to address.

Pure large-model approaches also produce false positives—and models can make those false positives sound even more credible. A model can generate a vulnerability name, attack path, scope of impact, and even a patch without ever actually running the target project.

Atlas assigns three roles to each candidate vulnerability:

• The proponent looks for supporting code evidence and fills in the attack prerequisites and exploit chain;
• The challenger checks whether the hypothesis overlooks validation, permissions, types, or runtime constraints;
• The arbiter weighs the evidence from both sides and determines whether the issue should proceed to execution-based validation.

This division of roles cannot guarantee correctness, but it can reduce the model’s tendency to keep reinforcing its initial conclusion. More importantly, Atlas ultimately creates a dedicated test environment and actually submits attack inputs. A report must not merely sound plausible; it must be reproducible whenever possible.

From the perspective of a security product’s value, automatically generating a PoC or attack-validation program may be more important than discovering the candidate vulnerability itself. What developers truly need is reproducible evidence: which versions are affected, what configuration is required, where the input enters, what abnormal behavior occurs, and whether the issue can still be triggered after the fix.

Large Models Handle Only the Hardest Parts

Having multiple agents repeatedly read large repositories can quickly send costs out of control. Atlas does not assign every step to the most powerful model. Instead, it uses a tiered routing strategy.

The system calls larger, more expensive models with stronger reasoning capabilities only for tasks such as analyzing complex exploit chains, evaluating conflicting evidence, and making final decisions. Code property graph queries, preliminary filtering, and repetitive tasks with clear boundaries are handled by smaller models or deterministic analysis tools.

| Stage | Best-suited capability | Primary consideration | | --- | --- | --- | | Code structure extraction | Deterministic tools, program graph analysis | Stable results and repeatable execution | | Preliminary candidate screening | Small models, rule-based systems | High call volume requires cost control | | Compound attack-chain reasoning | Highly capable large models | Requires cross-file and multi-step reasoning | | Adversarial review | Multi-agent collaboration | Reduces bias from a single conclusion | | Vulnerability confirmation | Isolated environments, test harnesses | Uses execution results to reduce false positives |

This is essentially model routing for security: inexpensive models perform the search, expensive models make judgments, program-analysis tools provide facts, and the runtime environment performs the final inspection.

For enterprise-grade agent systems, this architecture is also more instructive than “use the flagship model for every task.” Model capabilities change rapidly, and prices fluctuate. If a system decouples code parsing, state management, evidence validation, and model reasoning, it can replace an individual model without rewriting the entire vulnerability research workflow.

90.9% Is Impressive, but It Does Not Directly Equal Real-World Detection Rate

Wiz says Atlas achieved a score of 90.9% on CyberGym, an AI vulnerability research benchmark, outperforming several security-focused models. This indicates that its system design is effective at least on the target test set, but the score should not yet be interpreted as meaning that Atlas can “discover 90.9% of real-world vulnerabilities.”

Security benchmark results depend heavily on testing conditions, including:

• Whether the full codebase, build environment, and historical information are provided;
• How many tokens, how much time, and how many compute resources each task is allowed to consume;
• Whether the system can make repeated attempts and call external tools;
• Whether success means locating suspicious code, explaining the root cause, or completing a real exploit;
• Whether the comparison target is a standalone model or a complete agent system equipped with a similar toolchain.

Atlas itself is more than just a model. It combines models, code graphs, task orchestration, static analysis, and an execution framework. Its performance compared with a standalone model therefore demonstrates primarily that “systems engineering can significantly amplify model capabilities,” not necessarily that the underlying model itself is smarter.

Moreover, the publicly reported benchmark score and the tally of more than 200 vulnerabilities currently come mainly from Wiz’s own disclosures. A more complete technical report and third-party review are still needed to determine which projects were involved, how severe the vulnerabilities were, how duplicate issues were deduplicated, what the average validation cost was, and whether performance remains consistent on private enterprise codebases.

The $100,000 in GitHub bug bounties provides a stronger external signal than an ordinary demonstration: at least some of the findings passed review by project maintainers or bug bounty programs. But the bounty amount likewise cannot substitute for complete data on precision, recall, and cost per vulnerability.

Atlas Will Not Replace Security Researchers, but It Will Change the Productivity Structure of Vulnerability Discovery

Atlas’s short-term value may not lie in enabling companies to eliminate their security teams, but in expanding the amount of code that can be economically reviewed by several times.

The bottlenecks in manual security research are obvious. Senior researchers are scarce and cannot continuously conduct deep investigations into every dependency, every version update, and every edge-case call path. Traditional scanners offer broad coverage but often lack business context. Systems like Atlas occupy the space between the two: they first automate the search across a vast attack surface, then hand off reproducible issues with relatively complete evidence to humans for confirmation and coordinated disclosure.

For development teams, Atlas may first be adopted in the following scenarios:

• Conducting in-depth reviews of high-risk code changes before merging;
• Automatically building a threat model and attempting exploitation when a new dependency enters the software supply chain;
• Performing targeted testing of authentication, serialization, file handling, and command-execution paths before a release;
• Continuously analyzing legacy codebases for hidden attack chains that span modules and multiple steps;
• Automatically running regression validation after a vulnerability is fixed to determine whether the patch blocked only one entry point.

However, it also introduces new engineering and governance challenges. Automated attack inputs must be executed in a strictly isolated environment. Building unfamiliar projects may run malicious installation scripts. Models need to read large amounts of private code, raising concerns about data boundaries and access control. Automatically generated PoCs are themselves high-risk assets and cannot be distributed as casually as ordinary scan logs.

Vulnerability disclosure also still requires human judgment. Whether a validated vulnerability should be disclosed immediately, how to contact maintainers, whether downstream supply chains are affected, and how to control information before a patch is released are not problems that can be solved automatically by increasing the number of agents to ten.

The Real Barrier Is Not Multi-Agent Design, but a Closed Loop

Multi-agent systems are no longer a scarce concept. Any team can build a prototype by assigning different roles to several models and having them critique one another. Atlas’s barrier to entry lies in connecting code structure, model reasoning, and real execution into a closed loop—and making that loop run reliably across hundreds of projects.

This is also the key distinction between Atlas and an ordinary code-review copilot: the former does not aim merely to produce a professional-sounding vulnerability explanation, but to move all the way from attack-surface modeling to executable evidence.

If Wiz later discloses more project lists, vulnerability categories, false-positive rates, and average costs, Atlas could become an important baseline for assessing whether AI security agents are truly practical. Until then, a 90.9% score and more than 200 vulnerabilities are enough to demonstrate the direction’s potential, but not enough to declare automated vulnerability research a solved problem.

A more accurate assessment is: AI can already take over much of the search, hypothesis generation, and environment setup involved in vulnerability research, while human researchers will gradually shift toward high-risk decisions, complex business-context analysis, and disclosure governance.

The security industry used to sell more alerts. The new generation of systems represented by Atlas must deliver fewer but more credible vulnerabilities that can actually be reproduced. That is much harder—and much more useful.

References

• IT Home: Google-Owned Wiz Unveils Atlas Vulnerability Discovery System—An overview of Atlas’s multi-agent architecture, code property graphs, adversarial validation workflow, CyberGym results, and bug bounties.