How to Configure network_profile Settings in scope.md for Authorization

The network_profile block in scope.md configures network restrictions that take effect only after auth.status: granted is declared, with four modes ranging from offline to unrestricted_lab.

The scope.md file serves as the single source of truth for security and reverse-engineering tasks in the reverse-skill repository. Before any "ACT" step executes, this document establishes legal permission and network boundaries. The network_profile settings work in tandem with the auth block to enforce strict operational security—ensuring tasks run only within explicitly authorized network confines.

Understanding the Authorization Pipeline

The repository enforces a two-stage validation process. First, the auth block declares legal permission. Second, the network_profile block restricts network exposure based on that authorization.

According to RULES.md, the engine must verify auth.status = granted before parsing any network_profile configuration. This sequential check appears in the routing core logic and prevents unauthorized network activity before it starts.

Key Files in the Pipeline

File	Purpose
examples/ctf-demo/scope.md	Working example with complete network_profile configuration
skills/ops/scope-contract.md	Official template defining all network_profile modes (lines 44-49)
RULES.md	Enforcement rules requiring auth-before-network validation
skills/ops/role-map.md	Role definitions for the sign-off checklist

Step 1: Establish Authorization with auth.status

Before configuring network_profile, populate the auth block in your case's scope.md:

## auth

- status: granted          # ← MUST be `granted` before proceeding

- basis: ctf_lab          # written contract, bug-bounty scope, etc.

- evidence_of_auth: platform-provided-CTF-terms
- MUST NOT proceed if status != granted

The basis field documents the legal foundation—CTF platform terms, signed contracts, or bug bounty agreements. The evidence_of_auth field provides an audit trail. Automation scripts like case-init.ps1 read this block first; if status is not granted, the engine aborts and permits only supplemental authorization uploads.

Step 2: Select a network_profile Mode

The network_profile block immediately follows auth in scope.md. Its mode field determines permitted network boundaries:

mode	Allowed Activity	Prohibited Activity
offline	Pure static analysis, local samples	Any outbound traffic, remote RPC
lab_only	IPs belonging to CTF lab / VM network	Production or external IPs
authorized_target_only	Assets listed under in_scope.assets	Anything outside that explicit list
unrestricted_lab	Full lab network (requires written permission)	Internet-facing production assets

These definitions are explicitly documented in the network_profile table of skills/ops/scope-contract.md.

Example: Restricted Target Configuration

## network_profile

- mode: authorized_target_only
- notes: |
    offline | lab_only | authorized_target_only | unrestricted_lab
    Change mode only after auth.status = granted.

This configuration limits all network activity to assets declared in the in_scope.assets list. Any attempt to contact external hosts triggers a guard violation.

Example: Lab Environment Configuration

## network_profile

- mode: lab_only
- notes: |
    CTF lab network 192.168.56.0/24 only
    No external DNS resolution permitted

Step 3: Runtime Enforcement Mechanism

When skills execute, the routing core performs sequential validation as specified in RULES.md:

1. Validate auth.status — abort if not granted
2. Parse network_profile.mode — inject into NETWORK_PROFILE environment variable
3. Apply network guards based on mode selection

For authorized_target_only mode, the internal guard evaluates:

if ($target -notin $scope.in_scope.assets) { 
    throw "Network profile violation" 
}

Downstream scripts such as skills/scripts/refresh-tool-index.ps1 read NETWORK_PROFILE to determine socket creation, remote service launches, or offline operation.

Step 4: Complete the Sign-Off Checklist

Before setting ready_for_act: true, verify all safety items in scope.md:

## signoff

- ready_for_act: true
- checklist:
  - [x] auth.status = granted
  - [x] in_scope.assets non-empty OR offline sample path set
  - [x] network_profile.mode chosen
  - [x] out_of_scope reviewed
  - [x] roles assigned (see skills/ops/role-map.md)

The routing engine transitions from INIT to PRIMARY execution only when all boxes are [x] marked.

Complete scope.md Example

# Case Scope

## meta

- case_id: demo01
- created: 2026-08-13T00:00:00+08:00
- operator: local
- primary_skill: pwn-chain/SKILL.md
- lead_role: lead
- specialist_roles: [pwn-specialist]

## auth

- status: granted
- basis: ctf_lab
- evidence_of_auth: CTF platform terms

## in_scope

- assets:
  - https://ctf.example.com/challenges/pwn1
- surfaces: [binary download, remote service]
- activities: [static analysis, exploit development]

## out_of_scope

- assets: [platform infrastructure]
- activities: [dos, phishing_real_users]

## network_profile

- mode: authorized_target_only
- notes: |
    offline | lab_only | authorized_target_only | unrestricted_lab
    Change mode only after auth.status = granted.

## deliverables

- report: true
- field_journal: true

## signoff

- ready_for_act: true
- checklist:
  - [x] auth.status = granted
  - [x] in_scope.assets non-empty OR offline sample path set
  - [x] network_profile.mode chosen
  - [x] out_of_scope reviewed
  - [x] roles assigned (see skills/ops/role-map.md)

Modifying network_profile Mid-Project

Authorization scopes can expand with additional written permission. Update scope.md programmatically:

$casePath = "work/demo01/scope.md"

# Append new profile after obtaining unrestricted lab permission

Add-Content $casePath @"

## network_profile

- mode: unrestricted_lab
- notes: |
    offline | lab_only | authorized_target_only | unrestricted_lab
    New permission granted for full lab network.
"@

# Update auth evidence

# Re-run validation via case-init.ps1

The automation re-parses the file, detects the new unrestricted_lab mode, and permits broader network usage—contingent on maintained auth.status: granted and updated evidence_of_auth.

Summary

• auth.status: granted is mandatory before any network_profile takes effect
• Four modes control network exposure: offline, lab_only, authorized_target_only, unrestricted_lab
• skills/ops/scope-contract.md defines the official network_profile specification
• RULES.md enforces auth-before-network validation in the routing engine
• Sign-off checklist ensures all safety gates pass before ACT execution
• NETWORK_PROFILE environment variable propagates mode to downstream tools

Frequently Asked Questions

What happens if I set network_profile without auth.status granted?

The routing engine aborts execution. Per RULES.md, the engine validates auth.status first; if not granted, only supplemental authorization uploads are permitted. No network_profile restrictions are parsed or enforced until authorization is established.

Can I use multiple network_profile modes in one scope.md?

Only one active network_profile mode applies at execution time. However, you may append updated network_profile blocks mid-project with new modes—each superseding the previous when case-init.ps1 re-parses scope.md. The automation uses the most recent mode declaration.

How does authorized_target_only validate target assets?

The engine compares any connection target against the in_scope.assets list. If the target is not explicitly listed, the guard throws a "Network profile violation" exception. This check runs before socket creation or service interaction.

Where is the network_profile environment variable used?

Downstream scripts including skills/scripts/refresh-tool-index.ps1 and custom tool wrappers read NETWORK_PROFILE to determine network behavior. Tools modify their connection logic based on whether the mode permits outbound sockets, DNS resolution, or restricts activity to local resources.

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