# How to Configure network_profile Settings in scope.md for Authorization

> Learn to configure network_profile settings in scope.md for authorization. Understand the four restriction modes from offline to unrestricted lab and secure your network effectively.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-13

---

**The `network_profile` block in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/examples/ctf-demo/scope.md) | Working example with complete `network_profile` configuration |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) | Official template defining all `network_profile` modes (lines 44-49) |
| [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) | Enforcement rules requiring auth-before-network validation |
| [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md):

```markdown

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

### Example: Restricted Target Configuration

```markdown

## 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

```markdown

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

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

```markdown

## 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

```markdown

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

```powershell
$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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)** defines the official `network_profile` specification
- **[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.