# How reverse-skill Handles Case Management and Authorization: A Deep Dive into the Hard-Gate Security Model > Discover how reverse-skill's hard-gate security model manages cases and authorization. Learn about its two-phase workflow for secure skill execution and scope definition. - Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) - Tags: deep-dive - Published: 2026-08-24 --- **reverse-skill enforces a mandatory two-phase authorization workflow where `case-init` establishes scope and auth status, then `case-guard` acts as an immutable hard gate that prevents any skill execution until explicit authorization is granted and scope is defined.** The `zhaoxuya520/reverse-skill` repository structures every penetration test and reverse-engineering engagement as a formalized *case* with strict access controls. Unlike traditional toolkits that rely on user discipline, this framework implements a **policy-driven hard gate** that makes unauthorized execution technically impossible. The architecture separates case setup from execution validation, ensuring analysts cannot accidentally run skills against out-of-scope or unauthorized targets. ## The Case Lifecycle: From Initialization to Execution Every engagement follows a rigid three-step pipeline defined in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) and enforced by the core scripts in `skills/scripts/`. ### Phase 1: Establishing the Contract with case-init.ps1 The `case-init.ps1` script initializes the engagement directory under `work/` and generates the authoritative [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file. This script resolves authorization parameters, network profiles, and target assets to compute the `ready_for_act` boolean. Key enforcement points in this phase include: - **`-AuthGranted` flag**: Sets `auth.status` to **granted** only when explicitly passed or when using a preset that implies ownership. - **`-NetworkProfile` validation**: Selects from `offline`, `lab_only`, `authorized_target_only`, or `unrestricted_lab` modes. - **`in_scope.assets` population**: Requires at least one URL, domain, or local sample path; empty scopes are rejected immediately. - **`ready_for_act` computation**: Returns true only when `auth.status = granted` **and** assets are present **and** the network mode permits action. ```powershell # Initialize a case with explicit authorization powershell -File skills/scripts/case-init.ps1 ` -Hint "web pentest" -CaseName web-test ` -AuthGranted -TargetUrl "https://target.example" ` -NetworkProfile authorized_target_only ``` ### Phase 2: The Immutable Guard with case-guard.ps1 Before any skill module executes, `case-guard.ps1` (or its Bash equivalent [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh)) validates the case directory. This script reads [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and performs hard-gate checks that cannot be overridden. The guard verifies: - `auth.status` equals **granted** - `in_scope.assets` is non-empty (or an offline sample path exists) - `network_profile.mode` matches the allowed enumeration - `ready_for_act` is true when the user requests to ACT If any check fails, the script exits with code **2**, blocking further execution. According to [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md), the `-Force` flag is explicitly **compatible only**—it never bypasses these authorization checks. ```powershell # Validate the case before running skills powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\web-test ``` ## Core Authorization Components The authorization model relies on a declarative contract stored in each case’s metadata. ### The scope.md Contract Located at `work/{case-name}/scope.md`, this file is the single source of truth for engagement boundaries. It stores: - `auth.status`: Either `granted` or `pending` - `in_scope.assets`: Array of authorized targets - `network_profile.mode`: Operational network restrictions - `ready_for_act`: Boolean gate controlled by the framework As documented in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md), network profile changes are permitted only after `auth.status` is set to granted. ### The ready_for_act Gate This computed boolean acts as the final circuit breaker. The formula ensures that: 1. Authorization status is explicitly granted 2. Scope contains valid assets 3. Network configuration aligns with the authorization level Only when all three conditions satisfy does the framework permit the transition from reconnaissance to active testing. ### Why -Force Cannot Bypass Authorization The repository’s [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md) explicitly states that `auth.status=granted` plus a valid `network_profile` or offline sample must be ready before ACT is permitted. The documentation clarifies that `case-guard --force` or `-Force` **must not bypass this hard gate**. This design prevents social engineering or configuration mistakes from circumventing the authorization framework. ## Cross-Platform Implementation The security model is implemented in both PowerShell and Bash to support heterogeneous environments: - **`skills/scripts/case-guard.ps1`**: Windows and PowerShell Core environments - **[`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh)**: Linux and macOS environments Both implementations enforce identical validation logic and exit codes, ensuring consistent behavior across operating systems. ## Practical Workflow Example The following sequence demonstrates a complete authorized engagement: ```powershell # Step 1: Initialize with explicit authorization powershell -File skills/scripts/case-init.ps1 ` -Hint "Web pentest" -CaseName api-security ` -AuthGranted -TargetUrl "https://api.example.com" ` -NetworkProfile authorized_target_only # Step 2: Hard-gate validation (exits 2 if unauthorized) powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\api-security # Step 3: Execute primary skill only if guard succeeds powershell -File skills/scripts/master-route.ps1 ` -Hint "Web pentest" -OutDir work\api-security ``` If the guard detects missing authorization, undefined scope, or network policy violations, it terminates with exit code 2 and outputs a descriptive error, preventing `master-route.ps1` from executing. ## Summary - **Case initialization** via `case-init.ps1` generates the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract and computes `ready_for_act` based on explicit authorization flags. - **Immutable validation** via `case-guard.ps1` acts as a hard gate that exits with code 2 if `auth.status` is not granted or scope is undefined. - **Force resistance**: The `-Force` flag is explicitly designed to be compatible with, not bypass, authorization checks as per [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md). - **Cross-platform enforcement**: Both PowerShell and Bash implementations ensure consistent security boundaries across Windows and Unix environments. - **Source of truth**: The [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file and [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) define the mandatory fields required for any skill execution. ## Frequently Asked Questions ### What happens if case-guard.ps1 detects missing authorization? The script immediately exits with code 2 and prints a clear error message indicating which validation failed (missing `auth.status`, empty `in_scope.assets`, or unsupported `network_profile.mode`). This exit code prevents subsequent skill scripts from executing, ensuring the hard gate remains intact. ### Can the authorization checks be disabled with the -Force flag? No. According to the repository’s [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md), the `-Force` parameter is **compatible only** and explicitly cannot bypass the authorization requirements. The hard-gate design intentionally prevents any command-line flag from overriding `auth.status=granted` requirements. ### What file defines the required fields for case authorization? The [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) file specifies the schema for case authorization, including required fields such as `auth.status`, `network_profile.mode`, `in_scope.assets`, and the `ready_for_act` boolean. This contract is enforced by both `case-init.ps1` during creation and `case-guard.ps1` during validation. ### How does reverse-skill support Linux/macOS environments? The repository provides [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh), a Bash implementation that mirrors the PowerShell guard’s logic. It performs identical validation of [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md), enforces the same exit code 2 on failure, and respects the `-Force` compatibility rules, ensuring consistent case management across operating systems.