How Authorization Is Handled Before Target Interaction in reverse-skill

In reverse-skill, every actionable skill is gated by an explicit authorization grant recorded in a scope.md contract created during case initialization, ensuring no target interaction occurs without validated approval.

The reverse-skill framework treats authorization as a mandatory precondition rather than an optional step. Before any network activity or target engagement, the system enforces a strict workflow centered on skills/scripts/case-init.ps1 that creates a contractual boundary between the operator and the target environment.

The Authorization Gate: Case Initialization

The authorization workflow begins with the case-init script, which serves as the primary gatekeeper for all downstream operations. When invoked, this PowerShell script generates a work/<case>/scope.md file that functions as both a technical configuration and a legal contract governing the engagement.

Recording Authorization via CLI Flags

The script accepts explicit authorization parameters that determine whether the case proceeds to an actionable state. When the operator provides the -AuthGranted flag or sets -AuthStatus to granted, the script records auth.status: granted in the scope document【/cache/repos/github.com/zhaoxuya520/reverse-skill/main/skills/scripts/case-init.ps1|line 46‑52】.

Generating the Scope Contract

The generated scope.md contains a mandatory auth section that tracks status, legal basis, and evidence of authorization. Critically, the script explicitly injects the directive "MUST NOT proceed if status ≠ granted" into this contract, creating a hard stop for unauthorized operations【/cache/repos/github.com/zhaoxuya520/reverse-skill/main/skills/scripts/case-init.ps1|line 66‑71】.

Enforcing Authorization Across the Repository

Authorization enforcement extends beyond initialization into global policies and individual skill implementations, creating multiple layers of protection.

Global Policy in RULES.md

The repository-wide RULES.md file codifies the authorization requirement at line 21, stating: "MUST NOT ACT against targets until auth.status=granted and network_profile set". This global rule ensures consistency across all skill invocations and prevents accidental target engagement.

Skill-Level Verification

Every skill's SKILL.md template includes a "NOW" clause requiring operators to verify auth.status=granted before execution. For example, skills/attack-chain/SKILL.md at line 10 explicitly prohibits action when authorization is missing: "auth.status!=granted 禁止 ACT"【/cache/repos/github.com/zhaoxuya520/reverse-skill/main/skills/attack-chain/SKILL.md|line 10】.

The Readiness Check Algorithm

Before marking a case as ready for action, case-init.ps1 computes a ready_for_act boolean by validating three strict conditions at lines 96-102:

• auth.status equals granted
• At least one in-scope asset is defined (TargetUrl or InScopeAssets)
• network_profile is not set to offline

Only when all three conditions evaluate to true does the system set ready_for_act: true in the scope file, permitting downstream skills to execute【/cache/repos/github.com/zhaoxuya520/reverse-skill/main/skills/scripts/case-init.ps1|line 96‑102】.

Practical Implementation Examples

Initializing an Authorized Case

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web application pentest" `
    -CaseName "acme‑2026‑web" `
    -AuthGranted `
    -TargetUrl "https://app.example.com" `
    -NetworkProfile authorized_target_only

Runtime Authorization Guards in Skill Scripts

# Inside a skill script – quick guard before any network activity

if ((Get-Content $scopePath -Raw) -notmatch 'status:\s*granted') {
    Write-Error "Authorization not granted – aborting."
    exit 1
}

Structure of the Generated Authorization Contract

# Excerpt from the generated scope.md (auth section)

auth:
  - status: granted
  - basis: own_system
  - evidence_of_auth: cli‑flag AuthGranted or AuthStatus=granted
  - MUST NOT proceed if status != granted

Summary

• Authorization is contractual: The scope.md file created by case-init.ps1 serves as a binding contract that must record auth.status: granted before any target interaction.
• Multi-layer enforcement: The authorization gate operates at the initialization script level, global RULES.md policy level, and individual skill template level.
• Three-condition readiness: A case only achieves ready_for_act: true when authorization is granted, assets are defined, and the network profile permits connectivity.
• Hard stop language: The system uses explicit "MUST NOT proceed" directives rather than optional warnings, creating a fail-safe boundary against unauthorized access.

Frequently Asked Questions

What happens if I run a skill without authorization in reverse-skill?

The skill script checks scope.md for auth.status: granted before executing network operations. If the status is missing or not granted, the script aborts with an error or warning, preventing any target interaction according to the guards in skills/attack-chain/SKILL.md and the global RULES.md policy.

How do I grant authorization when creating a new case?

Use the -AuthGranted flag or specify -AuthStatus granted when calling skills/scripts/case-init.ps1. This records the authorization in the work/<case>/scope.md file and sets the ready_for_act flag to true, provided other readiness conditions are met.

Where is the authorization requirement documented in the source code?

The requirement appears in skills/scripts/case-init.ps1 (lines 46-52 and 66-71) where the scope contract is generated, in RULES.md (line 21) as a global policy statement, and in individual skill templates like skills/attack-chain/SKILL.md (line 10) as operational guards.

Can I bypass the network profile requirement while keeping authorization?

No. The ready_for_act boolean in case-init.ps1 (lines 96-102) requires three simultaneous conditions: valid authorization, defined assets, and a network profile that is not offline. The system treats these as interdependent safety controls that cannot be selectively disabled.

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