AI Vulnerability Research Is Advancing: How Enterprises Should Build Their Security Architecture

Specialized security models are changing how vulnerability research is done. They can discover software vulnerabilities, validate exploitability, and help researchers write remediation. These capabilities need to be examined separately: which numbers can be referenced, which scenarios have already been implemented, what enterprises should do first, and which steps must remain under human control. This article addresses each point and closes with a self-check table that can be used directly for internal assessment.

1. How AI Is Changing the Vulnerability Research Workflow

Traditional vulnerability research depends heavily on human effort. Researchers first need to understand how software runs, then perform static and dynamic analysis, identify suspicious points, write verification code, and finally confirm whether a vulnerability can be triggered in a real environment. Developing verification code is often the most time-consuming part, frequently requiring long debugging cycles around memory layout and control flow.

A new generation of specialized models can participate in this workflow end to end. By understanding assembly instructions, memory management mechanisms, and complex code logic, these models can generate runnable verification code for a given vulnerability, eliminating a large amount of repetitive debugging. For defenders, the vulnerability validation cycle can potentially be shortened. The prerequisite is that teams can quickly judge whether the results are credible, and this still requires human involvement.

2. What Empirical Data Shows and What It Does Not

In a commonly used vulnerability exploitation benchmark, the new-generation model achieved an exploit success rate of about 48.5%, compared with 32.1% for the previous-generation model, a relative improvement of about 51%. These figures come from the developer’s internal evaluation. The original report did not disclose the full dataset name, test environment parameters, or model version, so citations should refer back to the original report to verify the methodology.

The improvement in success rate shows that the model has made progress on complex-condition triggers and memory-corruption vulnerabilities. It does not mean the model can reliably handle all vulnerabilities.

Scenario	New-generation specialized model	Comparison model	Metric	Denominator note
Vulnerability exploitation benchmark	About 48.5%	32.1% (previous-generation specialized model)	Exploit success rate	Total tasks in the benchmark; the exact count needs to be verified against the original report
Web black-box penetration testing	40.3%	32.0% (general-purpose flagship model)	Vulnerability recall rate	Total known vulnerabilities in the test set

Note: The two rows use different denominator definitions. Exploit success rate measures the proportion of exploitation tasks completed successfully, while vulnerability recall rate measures the proportion of known vulnerabilities that were found. The comparison baselines also differ: one is a previous-generation specialized model, and the other is a general-purpose flagship model. Therefore, the differences between the two rows cannot be compared directly, nor can they be used to rank models in absolute terms.

3. How Do Kernel and Black-Box Web Scenarios Perform?

How Does AI Automate Low-Level System and Kernel Vulnerability Discovery?

The research team tested the model on mainstream operating system kernels and generated hundreds of runnable exploits. Kernel vulnerabilities often involve race conditions or memory corruption, and manual analysis is time-consuming. The model audits kernel source code, combines symbolic execution and taint analysis to locate defects such as uninitialized variables and out-of-bounds reads and writes, and then generates test programs to trigger those defects.

These results come from the research team’s own experiments, and the article does not provide independently reproduced data. At present, they should be treated only as directional reference and should not be used to evaluate the security of a specific product.

What Does Recall Rate Mean in Black-Box Web Penetration Testing?

In scenarios where source code is unavailable, the model interacts with the application to find problems, for example by sending crafted HTTP requests and analyzing response status codes and page structure. In a purpose-built web application test set, the new-generation model achieved a vulnerability recall rate of 40.3%, compared with 32.0% for the general-purpose flagship model.

The model can find high-risk issues such as unauthorized access, SQL injection, and cross-site scripting, which shows that it can chain together multi-step clues. But 40.3% also means that about 60% of known vulnerabilities were still not found. For security teams, it is better suited to supplement manual penetration testing than to carry out all testing work on its own.

4. Why Do Specialized Models Perform Better on Security Tasks?

General-purpose large models are trained with strict safety alignment. When faced with attack and exploitation requests, they refuse at a relatively high rate. Even if those restrictions are removed, their performance on specialized security tasks still lags behind specialized models.

Specialized models are trained on large amounts of security research corpora, vulnerability reports, and exploit code, and they use specially designed reinforcement learning feedback. In tests involving common enterprise infrastructure such as code hosting platforms, relational databases, and continuous integration tools, general-purpose models often lack specific protocol and context knowledge and struggle to construct effective test payloads. Specialized models can accurately call interfaces in controlled environments and validate the complete attack path.

This has a direct impact on defenders. The attack barrier is decreasing, and defenders need tools of comparable precision. Otherwise, the capability gap between the two sides will continue to widen.

5. What Are the Risk Level and Compliance Boundaries of These Models?

According to the Frontier Model Risk Preparedness Framework cited by the developer, this type of model is rated “Severe” in the cybersecurity domain. This means the model already has cyberattack capabilities that require stricter safeguards, and malicious use could cause broad systemic threats. When procuring and using such models, enterprises should require suppliers to explain their safeguards and usage restrictions.

The automated attack and exploitation techniques discussed in this article are intended only for penetration testing, red team exercises, and internal defensive validation with written authorization. Before use, the authorization scope and time window must be clearly defined, and complete operation records must be retained. Unauthorized probing, exploitation, or testing against other parties’ systems may constitute a violation of law in many jurisdictions.

6. How Should Enterprises Build Defense? Three Paths for Operationalizing AI Security Capabilities

1. Integrate with the Security Operations Center for Alert Correlation and Threat Hunting

Models can perform correlation analysis across large volumes of alerts, extract attack features, and connect alert handling with threat hunting into a closed loop. Combined with existing log services and monitoring platforms, they can first filter out a large number of false positives and then locate the real attack chain.

It is advisable to start with one high-frequency alert type, such as anomalous logins, as a pilot. Measure the results using a human-reviewed false positive rate: each week, sample a certain number of model decisions, have analysts confirm them one by one, and record false positives and false negatives. After effectiveness is confirmed, gradually expand to other alert types.

2. Add AI Code Auditing to the CI/CD Pipeline and Compare It with Conventional Tools

Run AI auditing, static application security testing (SAST), and dynamic application security testing (DAST) at the build stage to find defects as early as possible. The conclusions from the three types of tools should be compared with one another, with particular attention to three categories: issues reported by only one tool, issues reported by two tools, and issues where two tools reach opposite conclusions. Avoiding reliance on only one side can significantly reduce missed detections.

Data security is a prerequisite for this step. Core business code is a highly sensitive asset and should not be submitted in plaintext to public large-model APIs. Teams should prioritize privately deployed models or compliant channels approved by legal and security departments.

If these two conditions cannot be met, desensitize the source code before sending it for external analysis. The specific steps are as follows:

1. Perform static scanning to identify secrets, tokens, internal IP addresses, internal domains, and database connection strings in code and configuration, and replace them all with placeholders.
2. For files that require logic analysis, perform syntax-tree-level (AST-level) de-identification, preserving function structure, control flow, and call relationships while replacing business identifiers with consistent aliases.
3. Store the mapping between aliases and original names separately on the internal network and do not send it out with the code.
4. Before external transmission, conduct manual sample review to confirm that no sensitive information has been missed.
5. Record the file scope, time, and approver for each external transmission to support later traceability.

Desensitized code may still leak business logic, so it should still be managed as a sensitive asset and must not be treated as public information.

3. Apply AI Red-Blue Teaming in Attack-Defense Exercises

The focus of attack-defense exercises is to validate detection and response capabilities, not to compare whose model is stronger. The exercise should follow these steps:

1. Define scope and authorization. Enterprise management should sign written authorization listing target systems, time windows, prohibited operations, and the emergency stop contact.
2. Build an isolated sandbox. The sandbox should replicate the production environment’s network topology and service versions, but it should not connect to real data or use production credentials. External network access should be disabled by default, with only authorized egress allowed.
3. Establish a baseline. Record log volume, alert rules, and asset inventory before the exercise for later comparison.
4. Run an AI-assisted simulated attack chain inside the sandbox, covering stages from initial access discovery and privilege escalation to lateral movement. Record execution time and results for each stage.
5. Have the blue team monitor in parallel and record detection time, alert quality, and response actions for each stage.
6. Summarize detection gaps, fix rules, add logs, and adjust response processes.
7. After remediation, re-run the same attack chain to verify whether the gaps have been closed.
8. After the exercise, destroy the sandbox and temporary credentials and archive all records.

Throughout the process, personnel should retain the authority to stop the exercise at any time. If connectivity between the sandbox and the production environment is discovered, the exercise should be stopped immediately and investigated.

7. Enterprise AI Security Capability Self-Check Table

Enterprises can check item by item in the table below and start building from the earliest level they can satisfy. Only after all foundational-level items have been achieved should they proceed to advanced-level pilots.

Basic Level

• Security alerts have been centralized on a unified platform, and high-frequency alerts have manual handling records.
• Core code repositories have been connected to static scanning, and plaintext secrets and tokens are prohibited.
• At least one authorized penetration test is conducted each year, with written authorization and a scope list.
• It is clearly defined which code and data must not be sent to external large models.

Advanced Level

• One high-frequency alert type has been selected for an AI correlation pilot, with human-reviewed false positive rate data.
• AI auditing, SAST, and DAST run in parallel in the CI pipeline, and the three sets of conclusions have comparison records.
• An independent isolated sandbox exists, red-blue exercises are conducted at least quarterly, and detection time is recorded.
• Code goes through a desensitization process before external transmission, and a private model or an approved compliant channel is used.

Mature Level

• AI threat hunting has formed a closed loop, and alert handling time has a baseline and trend chart.
• Audit conclusions have remediation rate and regression verification records, and the AST de-identification process has been automated.
• Simulated attack chains run automatically in the sandbox on a regular basis, and detection coverage is measured using frameworks such as ATT&CK.
• Model use is included in internal audit, operation logs are traceable, and the risk level is reviewed once a year.

If any basic-level items have not been achieved, the basic level should be completed first. After all advanced-level items have been achieved, enterprises can consider expanding the scope of AI tool use.