AI-Assisted Vulnerability Discovery in Practice: Balancing Offense and Defense Through Tiered Access

1. Why Security Work Needs Tiered Access

Software security has long faced a dilemma: the same analytical capability that helps defenders find flaws before release can also help attackers move faster. Large language models have made clear progress in code comprehension, logical reasoning, and automated execution, and vulnerability research efficiency has risen accordingly. Researchers can read through large codebases faster. But if a model applies a single policy to all users, two failure modes emerge: excessive refusal blocks legitimate security research, while excessive permissiveness lowers the bar for attacks.

Tiered access is an engineering response to this tension. It determines how deep the model may go based on the user’s identity, purpose, and authorized scope. Ordinary users receive more tightly restricted capabilities. Professional teams can use deeper vulnerability analysis features only after identity and authorization are verified. The basis for tiering must be auditable and revocable, and must not rely solely on the model’s own judgment, because the model cannot verify whether the other party actually holds authorization for the target system.

2. A Five-Stage Implementation Chain for AI-Assisted Vulnerability Discovery

A mature vulnerability discovery process typically contains five stages. The output of each stage feeds the next, and traceable evidence is retained for later review.

2.1 Asset Understanding

The model first needs to understand the target system, including code structure, dependencies, build configuration, and runtime environment. For large codebases, a common approach is to build a symbol index and call graph first, then focus attention on entry functions, privilege boundaries, and data parsing modules. Placing an entire repository into context is costly and easily causes the model to miss critical paths.

2.2 Candidate Generation

The model combines static analysis results with semantic reasoning to propose suspicious locations, such as missing bounds checks, integer overflow, unvalidated external input, and incorrect resource release ordering. This stage produces only candidates; conclusions must wait until after verification. False positive rates are usually high, and candidates must be handed to subsequent stages for validation.

2.3 Exploitability Verification

Candidate flaws need confirmation of whether they are actually triggerable and under what conditions. Verification should be performed in an isolated environment, with the goal of answering two questions: under what conditions the flaw triggers, and how large the impact scope is. The output of verification should be an abstract description of reproduction steps, the category of triggering input, and log evidence, so that security engineers can review it. It should not output attack payloads that can be used directly.

2.4 Attack Path Analysis

The severity of a single flaw must be assessed within the full path. For example, a local information disclosure flaw combined with a privilege escalation flaw will have a noticeably higher risk level. Path analysis typically models assets, privileges, and flaws as a directed graph, starting from external entry points and checking whether reachable paths to sensitive assets exist. The more accurate the graph nodes, the more reliable the prioritization.

2.5 Remediation and Regression

Remediation recommendations should include specific change locations, the remediation rationale, and regression test cases. After remediation, the same verification process must be re-run to confirm the flaw is eliminated and no new issues were introduced.

The pipeline skeleton below illustrates the gating relationships between stages. The functions are placeholder implementations:

from collections.abc import Callable
from dataclasses import dataclass, field
@dataclass
class Finding:
    location: str
    category: str
    evidence: list[str] = field(default_factory=list)
    verified: bool = False
    severity: str = "unknown"
def run_pipeline(
    repo_path: str,
    reviewer_scope: set[str],
    audit_log: Callable[[dict], None],
) -> list[Finding]:
    candidates = generate_candidates(repo_path)         # Asset understanding + candidate generation
    audit_log({"stage": "candidates", "count": len(candidates)})
    confirmed: list[Finding] = []
    for finding in candidates:
        if finding.location not in reviewer_scope:      # Scope gate: only process code within authorized scope
            audit_log({"stage": "scope", "location": finding.location, "result": "skipped"})
            continue
        finding = verify_in_sandbox(finding)            # Verify in isolated environment, no usable payloads output
        if finding.verified:
            finding.severity = score_in_path(finding)   # Assess severity in the context of attack paths
            confirmed.append(finding)
        audit_log({"stage": "verify", "location": finding.location, "verified": finding.verified})
    return confirmed                                    # Handed to human review before entering remediation

The audit log records every gating decision. When disputes arise, the team can reconstruct the decision process at the time.

3. How to Evaluate Security Model Capability

Public benchmark results are easy to misread. Determining whether a model is suitable for security work requires breaking down the following dimensions:

Dimension	Question to Ask	Decision Use
Task definition	Are test cases close to real codebases, or artificially constructed simplified samples?	Whether results can be extrapolated to production
Reproducibility	Are results stable across repeated runs on the same input, and comparable across versions?	Whether the tool can enter regular workflows
Data isolation	Could test samples appear in model training data, inflating results?	Whether scores are trustworthy
False negative and false positive rates	How high is recall on known flaws, and what proportion of candidates are real?	Workload and risk in the verification stage
Context window effectiveness	After code exceeds the window, can critical paths still be found?	What segmentation strategy large repositories need
Output compliance	Does output contain directly usable attack payloads, and is refusal policy consistent?	Whether it can pass security review

Evaluations should use the team’s own historical flaw samples and retain a blind test set that is not shared externally. Looking only at public leaderboards makes it hard to judge how a model will perform on your own code.

4. Enterprise Pilot Deployment and Control Design

4.1 Tiered Access Control

Access levels should be bound to role and authorization, not to personal preference. A common approach:

Level	Applies To	Available Capabilities	Release Condition
L0	General developers	Code comprehension, coding standard checks	Account login
L1	Security engineers	Candidate generation, static analysis assistance	Department head approval
L2	Authorized red teams or vulnerability researchers	Isolated environment verification, path analysis	Written authorization scope and identity verification

Each level should have an expiration date. After authorization expires or personnel leave, permissions must be revoked automatically.

4.2 Output Content Filtering Gate

Before model output is displayed or exported, it must pass through a unified gate. The gate checks three categories of content: directly executable payloads, code locations beyond the authorized scope, and snippets containing credentials or personal information. Output that hits a rule enters a human review queue and is not returned directly to the user.

Sending code externally also carries risk. The scanning process sends source code to the model service. Enterprises should use only privately deployed or contracted service endpoints, desensitize sensitive information before sending, and clearly define retention periods for logs and intermediate results.

4.3 Three-Phase Pilot Implementation Steps

Phase one is baseline evaluation, lasting roughly two to four weeks. Select a project with a known high count of flaws, measure recall and false positive rates using historical flaw samples, and record tool operating costs. This phase does not connect to production code.

Phase two is controlled trial, lasting roughly one quarter. Connect two or three codebases and open only L1-level capabilities. Track the weekly human confirmation rate of candidates; if the confirmation rate stays low, adjust prompting strategy or tighten scope.

Phase three is limited rollout. After confirming the false positive rate is manageable and the gate runs stably, gradually open L2-level capabilities and integrate the tool into the security review process. Each time the scope expands, re-run the baseline test to confirm metrics have not regressed.

5. Core Checklist for Tool Adoption

Before adopting such tools, security teams can work through the following questions:

• Is the basis for tiering auditable, and can permissions be revoked with one action?
• Is the verification environment isolated from the production network, and is outbound connectivity prohibited?
• Is output gated, and can payload-type content be intercepted?
• Are the code egress endpoints, desensitization rules, and log retention periods confirmed in writing?
• Are evaluation metrics based on the organization’s own samples, rather than public leaderboards alone?
• Has a baseline regression test been completed before each scope expansion?

Tools are only part of the process. With tiering, gating, and auditing done properly, AI-assisted vulnerability discovery can genuinely reduce risk.