What Is the Purpose of the Scope Contract in reverse-skill? A Complete Guide to Authorized Security Testing

The scope contract in reverse-skill serves as the central gate-keeping document that enforces a hard pre-ACT barrier, requiring explicit authorization and defined boundaries before any active scanning, hooking, exploiting, or reverse-engineering operations can proceed.

The scope contract (skills/ops/scope-contract.md) is the foundational enforcement mechanism in the reverse-skill repository. It codifies legal, technical, and policy constraints that protect both the analyst and the target by ensuring no destructive action occurs without proper validation. This article examines how the contract functions as the single source of truth for determining whether and how security activities may proceed.

Core Responsibilities of the Scope Contract

The scope contract achieves six critical objectives that together form a comprehensive boundary enforcement system.

Enforce a Hard Pre-ACT Barrier

Before any ACT operations—defined as active scanning, hooking, exploiting, or reverse-engineering—can begin, the repository requires a populated work/<case>/scope.md file that complies strictly with the contract. The routing scripts in skills/scripts/master-route.ps1 and master-route.sh validate this file and abort execution if auth.status is not granted or if the network profile is invalid. In such cases, only documentation or routing steps are permitted.

As defined in skills/ops/scope-contract.md (lines 3-5), this barrier is non-negotiable and built into the core routing logic.

Capture Explicit Authorization

The auth section records three mandatory fields:

• status: Must be granted for any ACT to proceed
• basis: The legal or policy foundation for authorization (e.g., written_contract, verbal_approval)
• evidence_of_auth: Ticket numbers, contract IDs, or other traceable references

Scripts such as case-init.ps1 and case-init.sh validate this field during case creation. The routing engine re-verifies it at execution time. Any value other than granted triggers immediate termination with exit code 2.

Define Exactly What May Be Touched

The contract uses explicit in_scope and out_of_scope lists to enumerate:

• Assets: IP addresses, hostnames, application instances
• Surfaces: Web, API, binary, firmware, hardware interfaces
• Activities: recon, exploit_validate, full_exploit, post_exploit

This structure prevents scope-drift—the common failure mode where an analyst scans an entire domain when only one host is authorized. The routing engine checks these lists against requested operations and blocks any mismatch.

Restrict Network Connectivity

The network_profile block specifies one of four constrained modes:

Mode	Description
offline	No network connectivity permitted
lab_only	Only local lab infrastructure reachable
authorized_target_only	Strict single-target enforcement
unrestricted_lab	Broader lab access with logging

Scripts enforce the chosen mode at the OS level, blocking disallowed outbound traffic before any ACT tool executes.

Provide a Checklist for Readiness

The signoff checklist forces manual verification of four prerequisites before ready_for_act can be set to true:

1. auth.status equals granted
2. in_scope.assets is non-empty
3. network_profile.mode is explicitly chosen
4. out_of_scope reviewed and acknowledged

The routing scripts read this flag to decide whether to launch the primary skill. No flag, no execution.

Tie Together Other Operational Contracts

The scope contract is referenced throughout the repository architecture:

• RULES.md (lines 157-158): Codifies the "must-before-ACT" rule
• Skill definitions: Inherit boundary constraints from the contract
• case-guard.sh: Additional runtime enforcement layer

This ensures every component respects identical boundary definitions regardless of entry point.

How the Scope Contract Is Implemented

Case Initialization

Creating a compliant case requires executing the initialization scripts with proper parameters:

# Windows

powershell -NoProfile -ExecutionPolicy Bypass `
  -File skills\scripts\case-init.ps1 `
  -Hint "Enumerate internal web service" `
  -CaseName "internal-web"

# Linux/macOS/Kali

bash skills/scripts/case-init.sh \
  --hint "Enumerate internal web service" \
  --case-name "internal-web"

These scripts write work/internal-web/scope.md that must match the template in skills/ops/scope-contract.md (lines 7-14). The template pre-populates required headers and provides validation hints.

Runtime Contract Verification

The routing engine performs pattern-based validation before launching any primary skill. Simplified logic from master-route.ps1:

$scopePath = Join-Path $CaseRoot 'scope.md'
$scope = Get-Content $scopePath -Raw -Encoding UTF8

if ($scope -match 'auth:\s*status:\s*granted') {
    Write-Host "✅ Auth granted"
} else {
    Write-Error "❌ Auth not granted – aborting ACT"
    exit 2
}

if ($scope -match 'ready_for_act:\s*true') {
    # proceed to primary skill

} else {
    Write-Error "❌ Scope not ready for ACT"
    exit 2
}

This same verification appears in skills/scripts/verify-routing-coherence.ps1 (lines 159-165) and case-guard.sh, creating defense-in-depth against accidental or malicious bypass.

Compliant Scope Document Example

A valid scope.md that satisfies all contract requirements:

## auth

- status: granted
- basis: written_contract
- evidence_of_auth: ticket/12345

## in_scope

- assets:
  - 10.10.10.5
- surfaces:
  - web
- activities:
  - recon
  - exploit_validate

## network_profile

- mode: authorized_target_only
- notes: |
    Only the IP listed above may be contacted.

## signoff

- ready_for_act: true
- checklist:
  - [x] auth.status = granted
  - [x] in_scope.assets non‑empty
  - [x] network_profile.mode chosen

This structure aligns with skills/ops/scope-contract.md (lines 36-91) and will permit the routing engine to proceed to ACT operations.

Key Files Supporting the Scope Contract

File	Function
skills/ops/scope-contract.md	Master contract definition, template, and validation rules
skills/scripts/case-init.ps1 / case-init.sh	Case creation with contract-compliant scope generation
skills/scripts/master-route.ps1 / master-route.sh	Runtime enforcement of contract conditions
RULES.md / RULES_zh.md	Policy documentation referencing contract requirements
skills/scripts/verify-routing-coherence.ps1	Unit tests for contract compliance in routing pipeline
skills/scripts/case-guard.sh	Additional guard preventing authorization bypass

Summary

• The scope contract (skills/ops/scope-contract.md) is the mandatory gate-keeper before any ACT operations in reverse-skill
• It enforces explicit authorization through the auth.status: granted requirement
• Asset boundaries are defined through in_scope and out_of_scope lists that prevent scope-drift
• Network restrictions are locked via network_profile.mode with four progressively permissive levels
• The signoff checklist ensures human verification before ready_for_act enables execution
• Multiple scripts—case-init, master-route, case-guard, and verify-routing-coherence—implement layered enforcement

Frequently Asked Questions

What happens if I try to run a skill without a valid scope.md?

The routing scripts detect the missing or invalid file and terminate with exit code 2. Only documentation and routing steps remain available. No ACT operations can proceed until a compliant scope.md is present with auth.status: granted and ready_for_act: true.

Can the scope contract be bypassed by editing scripts directly?

The repository implements defense-in-depth through case-guard.sh and verify-routing-coherence.ps1. These components re-verify contract conditions independently of the main routing scripts, making bypass attempts detectable and preventable through the validation pipeline.

How does the network_profile mode restrict actual traffic?

The contract specifies the mode in scope.md, and implementation-specific scripts (referenced in routing logic) translate this into OS-level firewall rules, network namespace isolation, or proxy configurations. The authorized_target_only mode, for example, typically results in DROP rules for any destination not matching in_scope.assets.

Is the scope contract required for offline analysis?

Yes. The contract applies to all cases regardless of network requirements. Even network_profile.mode: offline requires complete scope.md documentation including authorization, asset lists, and signoff. This ensures consistent audit trails and prevents accidental future connectivity.

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