How reverse-skill Enforces Security Boundary for Penetration Testing Scope

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, 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 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

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

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 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)
• 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	Defines the mandatory workflow requiring case-init.ps1 execution before any ACT
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	Documents scope and authorization evidence collection procedures
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. 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.

Who can set auth.status to "granted"?

Role authorization is governed by 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.

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