Dual-Use Security AI Models: Capability Boundaries and Engineering Governance

Security-specialized models are evolving from general-purpose conversational assistants into dedicated capability components for offensive and defensive security scenarios. According to public materials, an attack-defense-specialized model released by a research team constructed hundreds of working exploits in general-purpose operating system kernels and uncovered dozens of previously unknown high-severity vulnerabilities in mainstream browsers; in out-of-scope decoy tests conducted without additional deployment prompts, its authorization scope retention rate reached 99.93%. These results send a clear signal: such models can no longer just read code and write reports—they are beginning to perform vulnerability discovery, exploit validation, and penetration test path planning. At the same time, their dual-use nature is amplified. Organizations must not only ask “how capable is the model” but also answer three harder questions: is the boundary controllable, is the process auditable, and are the results reproducible?

1. Capability Leap: From Assisted Auditing to Attack-Defense Validation

Traditional security tools excel at rule matching, dependency scanning, and known-signature detection, but they still depend on human expertise for cross-file semantic understanding, complex configuration inference, attack chain composition, and test path planning. The value of security-specialized models shows up at three levels.

First, vulnerability discovery moves from “single-point alerting” to “contextual reasoning.” A model can combine code structure, data flow, permission models, configuration files, and call chains to judge whether a given input can reach a dangerous operation, and explain why a report is a false positive. In code auditing, for example, the model should not merely flag a suspicious function; it should also state trigger conditions, impact scope, version dependencies, and remediation advice. High-quality output includes reproducible steps, not just conclusions.

Second, exploit generation moves from “proof of concept” to “exploitability validation.” Within an authorized lab environment, the model can generate validation scripts or exploit chain drafts based on vulnerability type to confirm whether a flaw is genuinely exploitable. But “able to generate an exploit” does not mean “exploitable in production”—that depends on target versions, runtime configuration, mitigations, permission boundaries, and network conditions. Enterprises should restrict exploit validation to isolated environments and retain human approval and rollback mechanisms.

Third, web penetration testing moves from “manual, item-by-item attempts” to “plan-driven execution.” The model can help map attack surfaces, generate test cases, analyze response differences, and prioritize risks. But the key to pentesting is not the number of requests—it is the authorization scope, test window, rate limits, and chain of evidence. Any automated test must first confirm that the target is on the allowlist before executing controlled actions.

2. Reading the Metrics: Four Qualifiers Behind the Numbers

Publicly disclosed exploit counts, unknown high-severity findings, and authorization retention rates are useful reference points, but they cannot be equated directly with production security posture. Four qualifiers matter when interpreting them.

First, the experimental environment. Hundreds of working exploits may depend on specific versions, configurations, and compilation options; outside those conditions, success rates change. Enterprises should require model outputs to carry environment assumptions, reproduction steps, and failure conditions.

Second, sample selection. The number of unknown high-severity vulnerabilities found correlates with test samples, codebase size, and audit depth. Comparing teams by raw counts is misleading; focus instead on finding quality, reproduction rates, fix-verification loops, and duplicate rates.

Third, the definition of authorization. A 99.93% authorization retention rate shows the model performed well in out-of-scope decoy tests, but retention is not attack success rate, nor is it proof of fail-safe behavior. It only indicates that, on a specific test set and under specific prompt conditions, the model rarely crossed preset boundaries. Real environments must also cover prompt injection, tool abuse, credential leakage, data exfiltration, and denial of service.

Fourth, risk rating. Rating the model at the highest danger level is essentially a reminder to organizations: the stronger the capability, the higher the requirements for admission, isolation, auditing, and incident response. Risk ratings should be translated into concrete admission rules rather than remaining a label.

3. Authorization Boundaries: Three Layers of Control—Policy, Enforcement, Audit

Governing dual-use models cannot rely on prompts alone. Prompts can be bypassed, and models can behave in unexpected ways. A more robust approach is three layers of control: policy, enforcement, and audit.

The policy layer defines “who can do what”: asset allowlists, explicit denylists, test time windows, rate limits, read-only versus write-action grading, and human approval for high-risk actions. The enforcement layer defines “how actions are constrained”: isolated test network segments, rollback snapshots, least-privilege credentials, traffic mirroring, sandboxed execution, and an emergency stop switch. The audit layer defines “whether events can be reconstructed afterward”: recording the principal, target, action digest, approver, time, result, and evidence hash.

The following pseudocode shows a simplified action guard:

def guard_action(action, grant, asset, now):
    if action.risk == "high" and not grant.human_approved:
        return "require_approval"
    if asset not in grant.allowlist:
        return "deny_out_of_scope"
    if asset in grant.denylist:
        return "deny_explicit"
    if now > grant.expire_at:
        return "deny_expired"
    if action.rate > grant.max_rate:
        return "throttle"
    return "allow_with_limits"

Audit records should use structured fields so they are searchable, traceable, and resistant to tampering:

record = {
  "actor": "executing principal",
  "target": "authorized asset identifier",
  "action_digest": "action summary",
  "decision": "allow/deny/pending approval",
  "approval": "approval record",
  "timestamp": "time",
  "evidence_hash": "evidence hash"
}

For high-privilege actions, adopt a “model proposes the plan, human confirms, controlled execution, result review” workflow. The model may propose test paths and validation scripts, but it should not, by default, hold direct permission to execute attack actions against production environments.

4. Evaluation: Turning the Highest Risk Rating into Admission Rules

Enterprises should build internal evaluation sets rather than relying on public demos. Evaluation dimensions should cover at least: vulnerability discovery recall and false positive rate, reproduction success rate, exploit validation stability, effectiveness of remediation advice, out-of-scope decoy pass rate, prompt injection resistance, data leakage risk, denial-of-service risk, and tool abuse risk.

Evaluation results should map to a tiered admission matrix. For example: low-risk tasks may run automated read-only analysis; medium-risk tasks run in isolated testing ranges with human spot checks; high-risk tasks require dual approval, a limited time window, full session recording, and audit trails; offensive actions against production environments are in principle prohibited from automated execution. Model versions, prompt templates, knowledge bases, and plugin configurations should all be brought under change management, with regression evaluations rerun on every upgrade.

5. Engineering Rollout: Four Phases and a DevSecOps Loop

A practical adoption path has four phases. Phase one: read-only code auditing and dependency analysis to validate discovery quality and false positive control. Phase two: validation in an isolated range to confirm exploitability and reproduction conditions. Phase three: authorized penetration testing windows, executing controlled tests within explicit scope and rate limits. Phase four: remediation advice, regression validation, and an operations feedback loop.

At the process level, a security-specialized model can plug into threat modeling for requirements, secure coding suggestions, dependency checks during builds, dynamic validation in testing, release gates, and operational monitoring and alerting. At the infrastructure level, generic services such as the container platform, logging, monitoring and alerting, and object storage available from Baidu AI Cloud can be used to build isolated execution environments, audit log pipelines, and evidence preservation mechanisms; the specific combination should be designed around each enterprise’s existing architecture and compliance requirements.

6. Organization and Compliance: A Governance Checklist for Dual-Use Capabilities

Finally, organizations need to institutionalize the governance of dual-use capabilities. A recommended checklist includes: model access control and tenant isolation; purpose declarations and authorization approvals; keeping keys and sensitive data out of model context; test data masking; human review of high-risk actions; emergency stop and permission revocation; periodic audit log reviews; vendor security assessments; and incident response plans. Only by combining capability, process, infrastructure, and audit evidence can security-specialized models improve vulnerability governance efficiency while operating within controllable boundaries.