Training Security-Specific Models to Stay Within Authorized Scope

1. After Capability Upgrades, Boundary Governance Must Be a First-Class Citizen

The value chain of security-specific models is expanding from “finding suspicious issues” to “proving that issues are exploitable,” “providing remediation recommendations,” and even performing authorized penetration testing tasks. The closer these capabilities get to the real attack chain, the higher the payoff from misuse and the more serious the consequences of a single boundary violation. Risks from traditional general-purpose models mostly appear as “saying the wrong thing”; risks from security models with tool-calling capabilities can appear as “doing the wrong thing”: scanning unauthorized assets, accessing out-of-scope data, executing irreversible actions, or expanding a validation request into a destructive operation.

Therefore, “staying within bounds” cannot rely only on system prompts or simple refusals. It should be broken out as a distinct capability and incorporated into training objectives, evaluation systems, runtime controls, and organizational access processes. In public industry discussions, research agents have not uncommonly exhibited boundary violations in isolated environments. This is a reminder that the risk boundary for tool-using models is not the same as a text boundary. Authorization evidence, action consequences, reversibility, and audit requirements must all be part of the model’s decision chain.

2. Break “Staying Within Bounds” into Five Trainable Capabilities

First, authorization evidence recognition. The model needs to distinguish between “the user claims to be authorized” and “verifiable authorization exists.” When information such as authorization tickets, target scope, time windows, and contacts is missing, the model should downgrade to read-only advice or patch analysis rather than directly executing validation actions.

Second, scope awareness. The model must understand target assets, application-layer entry points, account boundaries, data boundaries, and exclusions. For example, production-critical assets, third-party-hosted assets, and shared infrastructure should be excluded by default. When the authorized scope changes, the model should re-confirm rather than carry over historical context.

Third, action grading. Security actions can be divided into levels such as read-only scanning, validation requests, exploit validation, credential access, data export, and persistence operations. The higher the level, the more it requires approval, two-person review, and strong auditing. The model should know which actions can be executed automatically, which must be reviewed by a human, and which should be blocked outright.

Fourth, refusal and safe alternatives. A model that does not cross boundaries is not one that “does nothing”; it is one that “provides a safe alternative when it cannot perform an action.” For example, it does not output attack payloads but provides patch recommendations, detection rules, reproduction conditions, and remediation validation plans. It does not access out-of-scope targets but prompts the user to supplement authorization or narrow the scope.

Fifth, traceable decisions. The model should record “why it executed, what authorization it relied on, what tools it called, what the parameter summary was, and what the result was.” Audit information is not an auxiliary log; it is part of the model’s behavior.

Training data should cover positive examples, negative examples, ambiguous authorization, induced boundary violations, scope drift, and approval rejection scenarios. In post-training, policy alignment, tool-calling constraints, and red-team/blue-team exercises can internalize “verify authorization first, then act” as a process habit. The key is not to teach the model to refuse everything, but to learn “permitted but constrained.”

3. Evaluation System: Capability and Safety Axes Must Be Separate

Looking only at vulnerability discovery rate or exploit-validation success rate is insufficient. A more reasonable evaluation should include two axes. The capability axis focuses on vulnerability discovery quality, exploitability validation accuracy, patch recommendation adoption rate, false positive rate, and result reproducibility. The safety axis focuses on out-of-scope action rate, unauthorized tool-call rate, boundary-violation attempt rate, induced-attack success rate, irreversible-action interception rate, audit completeness rate, and whether the model can provide a usable safe alternative after refusal.

The evaluation environment should be isolated by default, use explicit allowlists for targets, and inject simulated authorization tickets and boundary-violation decoys. High-risk actions should have human-review gates, and the model’s performance under pressure and inducement should be recorded. Capability ratings and risk ratings should also be separated: reaching a certain capability level does not mean the model can be granted the same level of autonomous permission. For high-risk scenarios, small-scale pilots, short-lived authorization, and human oversight should be used.

4. Runtime Protection: Use Policy as Code to Hold the Last Gate

Model-layer alignment cannot replace runtime controls. A more robust approach is to decouple authorization policy from the model and have a policy engine enforce validation before tool calls. The following is an illustrative policy that does not correspond to any specific product interface:

policy:
  principal: "authorized_security_engineer"
  scope:
    assets: ["asset-group-a"]
    exclusions: ["production-critical", "third-party-hosted"]
  allowed_actions:
    - "vulnerability_scan"
    - "exploit_validation"
    - "patch_suggestion"
  requires_human_approval:
    - "exploit_validation"
    - "credential_access"
    - "data_export"
  constraints:
    network_egress: "deny_by_default"
    target_allowlist: "explicit"
    max_requests_per_minute: 30
    irreversible_actions: "block"
  audit:
    log_all_tool_calls: true
    record_authorization_ticket: true

This policy reflects several principles: deny by default, explicit allowlists, least privilege, short-lived credentials, blocking irreversible actions, and full auditing. At the infrastructure layer, general capabilities such as object storage, log services, monitoring and alerting, and container platforms—for example, from Baidu AI Cloud—can be used to store audit evidence, collect centralized logs, detect anomalous behavior, and isolate tasks. The key is to ensure that every tool call passes policy validation and leaves a traceable record.

5. Organizational Governance: Tiered Access and Closed-Loop Operations

At the organizational level, “defensive validation” and “authorized exploit development” should be managed in separate tiers. Defensive validation can be opened to verified security teams for vulnerability confirmation and remediation. Exploit development and authorized penetration testing should have higher thresholds, including identity verification, organizational security requirements, single sign-on, multi-factor authentication, and network address allowlists. Authorization should be issued per project, with clear targets, time windows, contacts, and stop conditions.

At the same time, a closed loop should be established: vulnerabilities discovered should enter disclosure and remediation workflows, and patches generated should undergo regression validation. Monitoring and alerts should be set for anomalous targets, anomalous frequencies, and anomalous data exports. Abuse monitoring and red-team assessments should be conducted regularly. Audit records should be retained, and responsibility boundaries between customers and vendors should be clearly defined. Only when training, evaluation, runtime controls, and organizational processes work together can dual-use capabilities be confined to the scope of authorized security research. Knowing how to exploit is a capability; staying within bounds is an engineering system.