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

> Master case scope boundaries in reverse-skill using auth.status and network_profile enforcement. Learn how automated guards ensure strict separation between preparation and action for secure operations.

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

---

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

```yaml
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).

```powershell

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

```powershell

# Verify repository policy consistency

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

```

## Practical Workflow Examples

### Initialize a fully authorized case

```powershell
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`:

```yaml
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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) | Human-readable single source of truth |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) | Schema reference for [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) fields |
| [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.