# How the Scope Contract Enforces network_profile Restrictions Before ACT

> Learn how the scope contract enforces network_profile restrictions before ACT. Discover the declarative policy and runtime PowerShell validator that prevent invalid network profiles.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-15

---

**The scope contract enforces network_profile restrictions before ACT by combining a declarative policy in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file and validates the mode value against the whitelist:

```powershell
$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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file in each case directory must declare the network restriction level explicitly:

```markdown

## 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) policy.

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

The [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md), validates the actual configuration values using `Get-ScopeSection` and `Get-SectionField`, and physically blocks ACT execution if violations are detected.