How Reverse-Skill Enforces Authorization Before Executing Actions

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 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
• 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. 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:

# 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

# 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]. 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:

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]—invokes [skills/scripts/case-guard.ps1] (or its Bash equivalent) before executing target-oriented actions. This guard script reads 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:

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

# 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] documentation clarifies that 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] 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 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 (Linux/macOS) with explicit authorization flags to create the 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 before any target-oriented action executes.
• -Force and --force flags are explicitly prohibited from bypassing authorization checks according to [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], 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 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]. This file resides within the case-specific working directory created during initialization and serves as the persistent authorization record for the entire engagement lifecycle.

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