How the Scope Contract Enforces network_profile Restrictions Before ACT

The scope contract enforces network_profile restrictions before ACT by combining a declarative policy in skills/ops/scope-contract.md that defines four allowed operational modes with a runtime PowerShell validator in skills/scripts/case-guard.ps1 that exits with code 2 if the network_profile.mode is missing or invalid, blocking the active scanning phase.

The zhaoxuya520/reverse-skill repository implements a strict scope contract mechanism to ensure that network_profile restrictions are validated before any ACT (active scanning, exploitation, or interaction) begins. This dual-layer enforcement system uses a declarative contract as the single source of truth, parsed at runtime by a guard script that acts as a mandatory checkpoint in the execution workflow.

Declarative Contract Definition in scope-contract.md

The foundation of the enforcement mechanism resides in skills/ops/scope-contract.md, which serves as the authoritative source documenting what network behaviors are permitted. According to the source code, lines 81‑88 of this contract define a strict matrix that maps each network_profile mode to specific traffic permissions—including whether outbound network traffic, production-target access, or internet connectivity is permitted.

The Four Allowed network_profile Modes

The contract recognizes exactly four valid values for network_profile.mode:

• offline: No outbound network traffic permitted
• lab_only: Only lab or CTF target IPs may be contacted
• authorized_target_only: Connections restricted to explicitly authorized production targets
• unrestricted_lab: Full lab environment access without external restrictions

Each mode carries explicit prohibitions defined in the contract matrix, ensuring operators cannot accidentally enable unauthorized network access during ACT operations.

Runtime Enforcement via case-guard.ps1

While the contract declares the policy, skills/scripts/case-guard.ps1 serves as the runtime enforcement layer. This PowerShell script acts as a mandatory gate that must complete successfully before any ACT operations proceed.

Parsing and Validation Logic

At lines 55‑62, the guard extracts the network_profile section from the generated scope.md file and validates the mode value against the whitelist:

$networkSection = Get-ScopeSection -Text $scope -Name 'network_profile'
$netMode = Get-SectionField -Section $networkSection -Name 'mode'
$allowedNetworkModes = @('offline','lab_only','authorized_target_only','unrestricted_lab')
if ([string]::IsNullOrWhiteSpace($netMode)) {
    $issues.Add('network_profile.mode missing')
} elseif ($netMode -notin $allowedNetworkModes) {
    $issues.Add("network_profile.mode is unsupported: $netMode")
}

If validation fails, the script adds the specific issue to an error collection and terminates with exit code 2, explicitly blocking downstream ACT execution. A successful validation returns exit code 0, allowing the workflow to proceed.

Workflow Integration and the ACT Gate

The enforcement mechanism integrates into the standard workflow through invocation by entry-point scripts such as skills/scripts/smoke.ps1. The execution flow requires:

1. case-guard.ps1 runs against the case directory
2. Exit code 0 confirms valid scope contract compliance
3. Only then does the PRIMARY skill proceed to ACT

This creates a hard dependency where network_profile configuration is verified before active scanning or exploitation tools execute, as mandated by RULES.md.

Emergency Override Behavior

Operationally, the guard supports a -Force parameter that alters the enforcement behavior. When invoked with -Force, validation issues generate warnings but return exit code 0, allowing the operator to bypass restrictions while accepting full responsibility for the override. Without this flag, any missing or unsupported network_profile.mode value results in immediate termination with exit code 2.

Configuring network_profile in scope.md

To satisfy the contract requirements, the scope.md file in each case directory must declare the network restriction level explicitly:

## network_profile

- mode: lab_only
- notes: |
    lab_only = only lab/CTF target IPs may be contacted

This declaration is parsed by Get-ScopeSection and validated against the contract whitelist. According to RULES.md, both auth.status=granted and a properly set network_profile are mandatory prerequisites before any ACT operation can commence.

Summary

• Declarative source of truth: The skills/ops/scope-contract.md file defines four valid network_profile modes (offline, lab_only, authorized_target_only, unrestricted_lab) and their associated restrictions at lines 81‑88.
• Runtime validation: skills/scripts/case-guard.ps1 parses scope.md at lines 55‑62, validates the mode against the whitelist, and exits with code 2 if the configuration is invalid or missing.
• Workflow blocking: Entry-point scripts like smoke.ps1 invoke the guard before primary skills reach the ACT stage, ensuring network restrictions are verified before active scanning begins.
• Override capability: The -Force flag allows execution with warnings only, shifting compliance responsibility to the operator while maintaining the default hard-block behavior.

Frequently Asked Questions

What happens if network_profile.mode is not set in scope.md?

If the network_profile.mode field is missing or empty, case-guard.ps1 detects this condition at lines 55‑62, adds "network_profile.mode missing" to the issues collection, and exits with code 2. This prevents the ACT script from running until the configuration is corrected and a valid mode is specified.

Can I use a custom network_profile mode not listed in the contract?

No. The validator in case-guard.ps1 explicitly checks against the array @('offline','lab_only','authorized_target_only','unrestricted_lab'). Any other value triggers an "unsupported" error and exit code 2, blocking execution as defined in the contract at lines 81‑88 of scope-contract.md.

How does the scope contract integrate with the main execution workflow?

The contract is enforced when entry-point scripts like skills/scripts/smoke.ps1 invoke case-guard.ps1 before launching primary skills. The guard must return exit code 0 before any skill marked as PRIMARY proceeds to the ACT stage, creating a mandatory checkpoint that validates network_profile restrictions according to RULES.md policy.

What is the difference between the contract definition and the guard script?

The skills/ops/scope-contract.md file serves as the declarative specification that documents allowed modes and restrictions, while skills/scripts/case-guard.ps1 serves as the runtime enforcement mechanism that reads the generated scope.md, validates the actual configuration values using Get-ScopeSection and Get-SectionField, and physically blocks ACT execution if violations are detected.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}