# How Authorization Is Handled Before Target Interaction in reverse-skill

> Discover how reverse-skill ensures authorization before target interaction. Learn about scope.md contracts for validated approval during case initialization.

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

---

**In reverse-skill, every actionable skill is gated by an explicit authorization grant recorded in a [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) template includes a "NOW" clause requiring operators to verify `auth.status=granted` before execution. For example, [`skills/attack-chain/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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
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

```powershell

# 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

```yaml

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/attack-chain/SKILL.md) and the global [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) (line 21) as a global policy statement, and in individual skill templates like [`skills/attack-chain/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.