# How reverse-skill Enforces Security Boundary for Penetration Testing Scope

> Discover how reverse-skill enforces security boundaries in penetration testing. Learn about its authorization workflow for ACT execution and scope file requirements.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-14

---

**The reverse-skill framework enforces a mandatory authorization workflow where no offensive action (ACT) can execute until a generated scope file contains `"auth.status": "granted"` and a valid `network_profile`.**

The *reverse‑skill* penetration-testing framework implements a strict **security boundary enforcement** mechanism that separates planning from execution. Before any real offensive operations occur, the framework requires explicit scope generation and multi-condition authorization verification. This design prevents accidental or unauthorized actions and ensures full auditability of every engagement.

## Scope Generation: The Foundation of Boundary Enforcement

Every penetration-testing engagement begins with mandatory scope creation. The runner script `skills/scripts/case-init.ps1` must be executed with a task hint to initialize a new case.

This script generates a **scope document** at:

```

work/<case>/scope.md

```

The scope file defines the complete engagement parameters:

- **Allowed targets** — specific IP ranges, domains, or systems
- **Permitted techniques** — which offensive methods are authorized
- **Operational boundaries** — time windows, data handling rules, and restrictions

According to [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md), this step is non-optional. The workflow explicitly requires scope generation before any ACT (action) phase can commence. Without this file in place, all subsequent operations are automatically blocked.

## Authorization Verification: The Dual-Condition Gate

The framework implements a hard gate controlled by the **auth subsystem**. Two conditions must be satisfied simultaneously:

1. **`auth.status` field set to `"granted"`**
2. **`network_profile` field must be present and valid**

These conditions are stored in `work/<case>/scope.md` as structured JSON. Only when both evaluate true does the framework lift the "no-ACT" lock.

The [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) file codifies this as a **hard security rule**: any skill script attempting real offensive actions will terminate immediately if authorization is incomplete or missing.

## Runtime Enforcement: Script-Level Guards

Every offensive skill in reverse-skill contains standardized guard logic that validates the authorization state at runtime. These guards execute before any ACT operations and enforce fail-closed behavior.

### Standard Authorization Guard Pattern

```powershell

# Guard: ensure scope exists and auth is granted before proceeding

if (-not (Test-Path "work/$case/scope.md")) {
    Throw "Scope file missing – run case-init first."
}
$auth = (Get-Content "work/$case/scope.md" | ConvertFrom-Json).auth
if ($auth.status -ne "granted" -or -not $auth.network_profile) {
    Throw "Auth status not granted or network profile missing – abort."
}

```

This pattern appears consistently across the skill library. The guard structure provides three layers of protection:

- **Existence check** — verifies the scope file was generated via `case-init.ps1`
- **Status verification** — confirms `auth.status` equals `"granted"`
- **Profile validation** — ensures `network_profile` is populated

If any check fails, the script throws a terminating error with a descriptive message, preventing execution from continuing.

### Standalone Authorization Check

For scripts requiring explicit re-verification, the same logic can be extracted:

```powershell
if ((Get-Content work\<case>\scope.md | ConvertFrom-Json).auth.status -ne "granted") {
    Write-Error "Authorization not granted – aborting ACT."
    exit 1
}

```

## Evidence and Auditability Requirements

The security boundary extends beyond runtime enforcement to include **documentation and audit trail** requirements.

The [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) file specifies how to record:

- The generated scope and its provenance
- The authorization decision and who approved it (mapped via [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md))
- The `auth.status` transition to `"granted"`

This ensures every authorized engagement can be reconstructed forensically, linking specific offensive actions to pre-approved scopes.

## Key Implementation Files

| File | Purpose |
|------|---------|
| [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md) | Defines the mandatory workflow requiring `case-init.ps1` execution before any ACT |
| [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) | Codifies hard security rules including the `"auth.status": "granted"` requirement |
| `skills/scripts/case-init.ps1` | Generates `work/<case>/scope.md` from task hints |
| [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) | Documents scope and authorization evidence collection procedures |
| [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md) | Maps roles responsible for setting and approving `auth.status` |

## Summary

The reverse-skill framework's **security boundary enforcement for penetration testing scope** operates through four interconnected mechanisms:

- **Mandatory scope generation** via `case-init.ps1` creates auditable engagement parameters
- **Dual-condition authorization** requires both `"auth.status": "granted"` and `network_profile` presence
- **Runtime script guards** enforce fail-closed behavior across all offensive skills
- **Evidence collection requirements** ensure complete audit trails for every authorized action

## Frequently Asked Questions

### What triggers the "no-ACT" lock in reverse-skill?

The framework enters a locked state by default for any new case. The lock persists until `skills/scripts/case-init.ps1` generates a valid `work/<case>/scope.md` file and the authorization fields satisfy the dual-condition check. This design ensures zero offensive actions occur without explicit, documented approval.

### Can skill scripts bypass the authorization guard?

No. The guard logic is embedded directly in skill scripts and evaluates local state from [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md). There is no centralized override mechanism—each script independently verifies authorization. This distributed enforcement prevents single-point failures and ensures consistent protection across the entire skill library.

### What information does the scope file contain?

The `work/<case>/scope.md` file includes JSON-structured data: the engagement hint and parameters from initialization, target specifications, authorized techniques, time boundaries, the `auth` object with `status` and `network_profile` fields, and role assignments referencing [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md).

### Who can set `auth.status` to `"granted"`?

Role authorization is governed by [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md), which defines which personas have approval authority. The evidence-finding path requires documenting both the scope generation and the authorization decision with role attribution, creating accountability for every granted status change.