The Complete AI Vulnerability Discovery Pipeline: From Authorization to Reporting While Avoiding Compliance Red Lines

AI is changing how vulnerability discovery works, but most "AI bug hunting" tutorials circulating online only cover tool installation and scanning while ignoring one fatal question: why would a vendor accept a vulnerability report generated by AI? In this AI vulnerability discovery system course released by Bilibili creator "Yi Ye," the focus is on the complete pipeline from authorization to reporting, with particular emphasis on manual review and compliance red lines—exactly where current AI bug hunting most easily fails.

Why AI Bug Hunting Needs a Complete Process

According to creator Yi Ye's analysis in the course, most vulnerabilities submitted in the AI bug hunting cases people see online are ignored by vendors. The reason is not that AI is insufficiently powerful, but that the process is missing. When AI-generated reports are submitted directly without manual review, vendors cannot confirm the authenticity and scope of impact of the vulnerability, so naturally they are hard-pressed to accept them.

The core logic of this course is: humans handle authorization and vulnerability verification, AI handles efficiency improvement, and together they form an eight-stage pipeline—authorization confirmation, asset collection, vulnerability scanning, AI analysis, manual review, reproduction verification, report generation, and submission for monetization. Each stage has clear outputs, rather than letting AI run the entire process as a black box.

Environment Setup: Graphical Tools and Model Selection

The first four chapters focus on "what to install and what to use." At the tool level, the ZQuad graphical interface is used to connect to Zhipu's GM model, lowering the operational barrier to AI vulnerability discovery. The creator mentions that after the first conversation is completed, you can start working in the lab environment without complex command-line configuration.

Model selection is another key point. The course compares AGIT (Automated Graphical Interaction Tool) with the logic of choosing large models, and explains core concepts, the Skype mechanism, and the complete MSP extension process. These contents form the infrastructure for subsequent use of AI tools in vulnerability discovery.

Notably, the course emphasizes three reusable assets: a self-built scale MCP configuration, prompt templates, and a graphical working environment. The creator states that regardless of which AI tool is used later, these three assets can be migrated and reused rather than being tied to a single product.

MCP (Model Context Protocol) is an open protocol that allows large language models to securely access external tools and data sources. It is essentially a standardized "plug" for AI models, enabling them to call local files, databases, APIs, or security tools without stuffing sensitive data directly into prompts. In vulnerability discovery scenarios, MCP can encapsulate scanners, asset mapping interfaces, lab environments, and other capabilities as tools callable by the model, allowing AI to perform operations within a controlled scope. The "self-built scale MCP configuration" mentioned in the article refers to building such a tool access layer according to one's own needs; its value lies in portability—when changing the underlying model or graphical interface, the tool access logic does not need to be rewritten.

Compliance Red Lines: The Biggest Bottleneck in AI Bug Hunting

The course devotes a dedicated chapter to compliance red lines because this is the biggest bottleneck encountered in AI bug hunting at present. Creator Yi Ye points out that AI only completes tasks, regardless of the means used—and that is precisely where the risk lies.

Specifically, SRC platforms usually allow only a limited amount of information to be obtained, but when AI has no strict limits, it may download all data on the target server, which exceeds the authorization red line. Another typical scenario is intranet probing: all platforms prohibit probing internal networks, but if AI discovers an RCE command execution vulnerability, it may directly go deep into the intranet to expand the attack, which is exactly the SRC red line. Operations such as deleting data are also dangerous behaviors that AI may "decide on its own."

Therefore, the course emphasizes constraining AI behavior through configuring corresponding compliance red lines, so that it discovers vulnerabilities within the rules rather than remediating afterward.

SRC (Security Response Center) is the official channel through which enterprises receive vulnerabilities submitted by external security researchers, such as Tencent SRC, Alibaba SRC, etc. SRC platforms usually set clear testing specifications: only designated domains and assets may be tested, probing internal networks and third-party systems is prohibited, downloading or deleting business data is prohibited, and high-frequency scanning with automated tools is prohibited. Vulnerabilities submitted by researchers must go through platform review, and rewards or acknowledgments are given only after authenticity and scope of impact are confirmed. Understanding SRC rules is a prerequisite for compliant AI bug hunting—AI itself does not read the rules, and if boundaries are not set at the tool and prompt levels, the model can easily touch these red lines driven by "completing the task," leading to rejected reports or even legal liability.

Manual Review: The Necessary Gate Before Submitting AI Reports

The course repeatedly emphasizes one point: AI-generated vulnerability reports are not necessarily true, nor are they necessarily acceptable to vendors. The role of manual review is to judge whether the vulnerability discovered by AI actually exists, whether its scope of impact is accurate, and whether it complies with platform rules.

In the complete process, after AI analysis identifies items where vulnerabilities exist, manual review and reproduction are required, and only successful reproduction enters the report generation stage. The report itself also needs to be processed by combining AI and human judgment, rather than directly delivering AI output as the final product. This division of labor—"AI provides efficiency, humans provide judgment"—is the core of what distinguishes this course from fast-food tutorials on the market.

Vulnerability reproduction refers to the process in which a security researcher, based on the description in a vulnerability report, re-triggers the vulnerability in a controlled environment to prove that it truly exists and that its scope of impact matches the report. Successful reproduction is the key basis for a report being accepted by a vendor: the vendor needs to confirm that the vulnerability can be triggered stably, that exploitation conditions are clear, and that affected component versions are explicit before entering the remediation process. AI-generated reports often contain hallucinations—they may describe false positives as high-risk vulnerabilities or exaggerate the scope of impact. Manual reproduction requires researchers to actually execute exploitation steps, observe response differences, and record the environment and versions, thereby filtering out untrue reports. This is also why the course lists "reproduction verification" as a separate stage in the pipeline: without reproduction, an AI report is just a piece of text.

How Ten Chapters Connect into a Pipeline

The course has ten chapters in total. The first four address environment and tool issues, chapters five through seven explain how to extend AI tools, and chapter eight begins hands-on practice: using the configured tools and extensions to conduct a complete vulnerability discovery process against a website, finally leading to the writing of vulnerability reports.

All demonstrations are completed in an authorized lab environment. The creator specifically notes that cybersecurity itself is an industry with clear legal red lines, and that launching harmful attacks against real websites without authorization is illegal, so course demonstrations are conducted only through lab environments. This point is especially important in the context of AI lowering the attack threshold—the easier the tools are to use, the more process and compliance awareness are needed as a safeguard.

Key Takeaways

• The core of AI bug hunting is not the tools, but the complete pipeline of "authorization—assets—scanning—AI analysis—manual review—reproduction—reporting—submission."
• Submitting AI-generated reports directly without manual review is the main reason vulnerabilities are ignored.
• Compliance red lines are the biggest bottleneck in AI bug hunting: AI may download data beyond authorization, go deep into intranets, or delete data, and must be constrained in advance.
• Graphical tools (ZQuad connected to Zhipu GM model) lower the operational barrier, but model selection and extension configuration remain key.
• All demonstrations are completed in authorized lab environments; testing real targets must be authorized.

One-line Summary

AI bug hunting requires an eight-stage pipeline, with manual review and compliance red lines being key.

Paragraph Summary

The article introduces Bilibili creator "Yi Ye's" AI vulnerability discovery system course, pointing out that most online AI bug hunting tutorials only cover tool installation and scanning while ignoring why reports are ignored by vendors. The course's core is an eight-stage pipeline of "humans handle authorization and verification, AI handles efficiency": authorization confirmation, asset collection, vulnerability scanning, AI analysis, manual review, reproduction verification, report generation, and submission for monetization. The first four chapters cover environment setup, using the ZQuad graphical interface to connect to Zhipu's GM model, and emphasize three reusable assets: self-built MCP configuration, prompt templates, and a graphical environment. Compliance red lines are regarded as the biggest bottleneck: AI may download data beyond authorization, go deep into intranets, or delete data, and must be constrained in advance. Manual review judges the authenticity and scope of impact of vulnerabilities, and only successful reproduction enters the report stage. All demonstrations are completed in authorized lab environments.