Managing Case Scope Boundaries with `auth.status` and `network_profile` Enforcement in reverse-skill

The reverse-skill repository enforces strict separation between case preparation and offensive action by requiring auth.status to be set to granted before any network_profile mode can be activated, with automated guards that abort execution if these boundaries are violated.

The reverse-skill framework implements a defense-in-depth workflow for reverse engineering and penetration testing operations. By treating authorization and network constraints as declarative policy documents rather than procedural checks, the system prevents accidental or unauthorized actions through automated enforcement at multiple layers.

The Two Core Enforcement Mechanisms

The boundary system revolves around two interdependent concepts defined in skills/scripts/case-init.ps1:

Concept	Purpose	Location
auth.status	Ensures explicit legal/organizational authorization before any offensive operations	Lines 67–81 of case-init.ps1
network_profile	Restricts network interaction to predefined safe modes (offline, lab-only, authorized target, unrestricted lab)	Lines 103–119 of case-init.ps1

These values are embedded in a machine-readable scope.md file that serves as the single source of truth for all downstream operations.

Case Initialization and Policy Generation

The case-init.ps1 script transforms user inputs into a formal scope contract. It resolves authStatusResolved from flags like -AuthGranted or explicit -AuthStatus values, then determines the effective networkMode from -NetworkProfile aliases.

Key resolution logic includes:

• Authorization states: pending (default) or granted (requires explicit flag or manual scope edit)
• Network profile normalization: Accepts aliases like lab, offline, target, unrestricted and maps them to canonical modes

The generated scope.md contains three critical sections:

auth:
  status: granted        # MUST be granted before ACT

network_profile:
  mode: authorized_target_only  # Locked until auth granted

signoff:
  ready_for_act: true    # Auto-computed from all conditions

The ready_for_act flag is automatically set to true only when auth is granted, assets are defined, and network mode permits interaction—echoed to console as shown in lines 14–16 of case-init.ps1.

The ACT Guard: Runtime Enforcement

Before any offensive operation executes, skills/scripts/case-guard.ps1 performs mandatory validation. Located at lines 47–87, the guard implements four hard checks:

1. auth.status equals granted — Rejects pending or missing values
2. network_profile.mode is valid and present — Must be one of: offline, lab_only, authorized_target_only, unrestricted_lab
3. Asset scope is non-empty — Unless operating in offline mode with a captured sample
4. ready_for_act is true — Final aggregate confirmation

Failure triggers exit code 2 (or 0 with -Force override for emergency scenarios).

# Validate scope before executing offensive operations

powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case

# Exit codes: 0 = ready, 1 = usage error, 2 = policy violation

Policy Coherence Verification

The skills/scripts/verify-routing-coherence.ps1 script (lines 46–52) ensures that documentation stays synchronized with enforcement. It scans RULES.md and RULES-zh.md for:

• Hard-gate language: "auth.status = granted", "MUST NOT ACT against targets"
• Rule ordering: Confirming "case-init → ACT" sequencing in all routing paths

This prevents documentation drift that could mislead operators about safety requirements.

# Verify repository policy consistency

powershell -File skills/scripts/verify-routing-coherence.ps1

Practical Workflow Examples

Initialize a fully authorized case

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -CaseName my-case `
    -AuthGranted -TargetUrl "https://app.example/" `
    -NetworkProfile authorized_target_only

Recover from pending authorization

When initialization omits -AuthGranted, manually edit work\my-case\scope.md:

auth:
  status: granted
in_scope:
  assets:
    - https://app.example/
network_profile:
  mode: authorized_target_only
signoff:
  ready_for_act: true

Then re-run the guard to confirm.

Key Files and Their Roles

File	Responsibility
skills/scripts/case-init.ps1	Scope generation, auth/network resolution
skills/scripts/case-guard.ps1	Runtime policy enforcement
skills/scripts/verify-routing-coherence.ps1	Documentation-policy alignment checks
RULES.md	Human-readable single source of truth
skills/ops/scope-contract.md	Schema reference for scope.md fields
skills/ops/role-map.md	Role definitions for post-scope operations

Summary

• Authorization precedes action: auth.status must be granted before any network_profile mode permits target interaction
• Machine-readable policy: scope.md acts as the runtime contract between preparation and execution phases
• Multiple enforcement layers: Initialization-time resolution, runtime guard validation, and static policy verification work together
• Fail-closed design: The guard aborts with exit code 2 rather than warn, ensuring violations cannot proceed accidentally

Frequently Asked Questions

What happens if I try to ACT without granting authorization?

The case-guard.ps1 script detects auth.status is not granted and terminates with exit code 2. No offensive commands execute. Use -Force only in documented emergency procedures.

Can I change the network profile after case initialization?

Yes, but only by editing scope.md directly—the case-init.ps1 script is designed for initial setup. Any change requires re-validation through case-guard.ps1 before subsequent ACT operations.

Why does offline mode not require in-scope assets?

Offline reverse engineering operates on captured samples rather than live targets. The guard logic explicitly permits empty in_scope.assets when network_profile.mode equals offline and a sample reference exists in the case documentation.

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