# How Reverse-Skill Enforces Authorization Before Executing Actions

> Reverse-Skill enforces strict authorization before executing actions. Learn how its hard gate system verifies permissions and network profiles to prevent unauthorized command execution.

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

---

**Reverse-Skill implements a mandatory hard gate authorization system that requires explicit written permission (`auth.status = granted`) and a validated network profile in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) before any target-oriented command can execute, with no mechanism available to bypass this safety check.**

Reverse-Skill is an open-source penetration testing and security auditing framework designed to prevent unauthorized actions through rigorous pre-execution validation. Understanding how reverse-skill authorization works is critical for security professionals who need to maintain compliance and audit trails during active engagements. The system enforces a case-based workflow where every action requires documented authorization before execution begins.

## The Hard Gate Authorization Model

Reverse-Skill treats authorization as a non-negotiable prerequisite rather than a configurable option. According to the **[RULES.md]** policy file, the framework operates on a **case-initialization workflow** that must be completed before any target-oriented command (ACT) can run.

This design creates a **hard gate** that cannot be circumvented. The authorization chain requires three specific components:

- **Written authorization** documented explicitly in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)
- **Network context validation** specifying the operational environment
- **Guard verification** executed before every skill invocation

Unlike frameworks that rely on user prompts or configurable safety levels, Reverse-Skill aborts execution immediately if the authorization contract is incomplete or malformed.

## Step-by-Step Authorization Workflow

### 1. Case Bootstrap with case-init Scripts

Authorization begins with platform-specific initialization scripts. Users must run the native `case-init` utility to establish a legal foundation for the engagement.

On Windows systems, this involves **[`skills/scripts/case-init.ps1`]**, while Linux, macOS, and Kali platforms use **[`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh)**. These scripts perform the critical function of creating the authorization contract only when explicitly instructed.

The initialization requires the `-AuthGranted` flag (PowerShell) or equivalent confirmation (Bash) to write `auth.status = granted` to the scope file:

```powershell

# Windows initialization with authorization

powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/case-init.ps1 `
    -Hint "Investigate AD trust" -CaseName "ad-audit" -AuthGranted -NetworkProfile authorized_target_only

```

```bash

# Linux/macOS initialization

bash skills/scripts/case-init.sh --hint "Analyze IoT firmware" \
    --case-name "iot-firmware" --preset offline-sample --sample ./firmware.bin

```

### 2. Scope Creation and the scope.md Contract

The initialization process creates **`work/<case>/scope.md`**, a mandatory contract file structured according to **[[`ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ops/scope-contract.md)]**. This Markdown file serves as the single source of truth for authorization status and operational boundaries.

The contract requires two critical fields:

- **`auth.status = granted`** — Explicit written permission from the client or legal asset owner
- **`network_profile`** — A validated network context such as `lab`, `authorized_target_only`, or an offline-sample profile

You can inspect the generated authorization scope using standard file commands:

```powershell
cat work/ad-audit/scope.md

# Expected content:

# auth.status = granted

# network_profile = authorized_target_only

```

### 3. Guard Enforcement via case-guard.ps1

Every skill script—including the master routing entry **[[`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md)]**—invokes **[`skills/scripts/case-guard.ps1`]** (or its Bash equivalent) before executing target-oriented actions. This guard script reads [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and performs strict validation.

If `auth.status` is not explicitly set to `granted` or if the `network_profile` field is invalid, the guard aborts execution with a non-zero exit status. This enforcement happens automatically inside any skill script:

```powershell

# Inside any skill script

& "$PSScriptRoot/../case-guard.ps1"

# The guard will exit with a non-zero status if the gate is not satisfied.

```

## Authorization Failure Handling

When authorization is missing or pending, Reverse-Skill prevents execution regardless of the command issued. Attempting to run a skill without completing the authorization workflow results in immediate termination:

```powershell

# Assume auth.status is still "pending" in scope.md

powershell -File skills/scripts/master-route.ps1 -Hint "Run Bloodhound"

# → case-guard aborts: "ERROR: auth.status != granted – aborting ACT."

```

This failure mechanism applies universally across all skill invocations. The **[[`ops/precedent-auth.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ops/precedent-auth.md)]** documentation clarifies that [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) itself does not grant authorization; rather, it serves as the verification target that the `case-init` process populates when proper legal authority is confirmed.

## Security Guarantees: No Force Bypass

The **[[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)]** file explicitly states that `-Force` or `--force` flags **never** bypass the authorization gate. This architectural decision prevents accidental or malicious overrides that could result in unauthorized access to target systems.

Security teams can rely on the following guarantees:

- The authorization gate is **stateless**—it checks the current [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) on every execution
- No command-line flag or environment variable can override a missing `auth.status = granted`
- The case directory maintains an immutable audit trail linking every action to its authorized scope

## Summary

- **Reverse-Skill authorization** requires running `case-init.ps1` (Windows) or [`case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-init.sh) (Linux/macOS) with explicit authorization flags to create the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract.
- The **`auth.status = granted`** field in `work/<case>/scope.md` serves as the immutable authorization token checked by every skill.
- **[`skills/scripts/case-guard.ps1`]** enforces the hard gate by validating [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) before any target-oriented action executes.
- **`-Force` and `--force` flags are explicitly prohibited** from bypassing authorization checks according to **[[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)]**.
- The system creates a **reproducible audit trail** by storing the scope, timeline, and evidence within the case directory structure.

## Frequently Asked Questions

### Can I bypass the reverse-skill authorization gate with the -Force flag?

No. According to **[[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)]**, the `-Force` or `--force` flags explicitly never bypass the hard gate. This design prevents accidental execution of actions against unauthorized targets. The authorization check in **[`skills/scripts/case-guard.ps1`]** occurs before command-line arguments are evaluated for force overrides.

### What files are required to establish authorization in Reverse-Skill?

Authorization requires the creation of **`work/<case>/scope.md`** containing `auth.status = granted` and a valid `network_profile`. This file is generated by **[`skills/scripts/case-init.ps1`]** (or the `.sh` variant) only when the `-AuthGranted` parameter is provided during case initialization.

### How does the case-guard script validate authorization status?

The **[`skills/scripts/case-guard.ps1`]** script reads the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file from the current case directory and checks for the presence of `auth.status = granted`. It also validates that the `network_profile` field contains an approved value such as `lab`, `authorized_target_only`, or an offline sample profile. If either check fails, the script exits with a non-zero status and aborts the parent skill execution.

### Where is the authorization scope stored in a Reverse-Skill case?

The authorization scope is stored in **`work/<case>/scope.md`**, which follows the contract defined in **[[`ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ops/scope-contract.md)]**. This file resides within the case-specific working directory created during initialization and serves as the persistent authorization record for the entire engagement lifecycle.