How the auth/scope Gate Prevents Unauthorized Target Access in reverse-skill

The auth/scope gate enforces a hard-coded authorization barrier that blocks all active exploitation steps until scope.md contains auth.status=granted and a valid network_profile, with no override possible via --force or -Force flags.

The auth/scope gate is a core safety mechanism in the zhaoxuya520/reverse-skill repository that ensures no penetration testing or active exploitation (ACT) occurs without documented, explicit authorization. This article examines how the gate is implemented across multiple layers—from initialization scripts to CI enforcement—to prevent unauthorized target access.

What the auth/scope Gate Requires

Before any skill can execute against a target, two conditions must be met in the case's scope.md file:

• auth.status=granted — manually set by the operator after obtaining proper authorization
• network_profile — set to a legal value (e.g., lab, production, staging)

These requirements are enforced regardless of execution context: interactive shell, automated pipeline, or CI workflow.

The case-guard Script: The Final Checkpoint

The case-guard script serves as the last line of defense before any tool runs. Both the Bash and PowerShell implementations perform identical validation logic.

Bash Implementation

In skills/scripts/case-guard.sh, the script reads auth status from scope.md and aborts if not granted:

# Example successful execution

bash skills/scripts/case-guard.sh

# Output:

#   ✅ auth.status = granted

#   ✅ network_profile valid

If authorization is missing, the script adds an issue and terminates:

auth.status is not granted

PowerShell Implementation

The skills/scripts/case-guard.ps1 script mirrors this behavior using the $authGranted flag. Both versions reject any attempt to bypass the check.

Initialization and Status Resolution

The case-init scripts create the foundation for proper authorization tracking. Located at skills/scripts/case-init.sh and skills/scripts/case-init.ps1, these scripts:

1. Create a new case folder under work/<case>/
2. Generate scope.md with default auth.status=pending
3. Display the resolved status for operator awareness

# Initialize a new case

bash skills/scripts/case-init.sh --hint "Example target"

# The script outputs the current status (pending by default)

# Operator must manually edit scope.md to set:

#   auth.status=granted

#   network_profile=lab

Only after this manual step does the gate become passable.

Explicit --force Blocking

A critical design decision prevents emergency bypasses. According to RULES.md and RULES_zh.md:

"Run the platform-native case-init until scope.md has auth.status=granted plus a legal network_profile. -Force/--force never bypasses the gate."

This policy is actively enforced:

# Attempted bypass

bash skills/scripts/case-guard.sh --force

# → Error: case-guard --force bypassed auth.status hard gate

The gate treats force flags as a failure condition, not a shortcut.

CI Pipeline Enforcement

The .github/workflows/ci.yml workflow adds automated verification that prevents silent bypasses:

- name: Run case guard
  run: |
    bash skills/scripts/case-guard.sh
    guardExit=$?
    if [[ $guardExit -eq 0 ]]; then
      echo "All good"
    else
      echo "case-guard --force bypassed auth.status hard gate" >&2
      exit 1
    fi

If case-guard exits abnormally or detects force usage, the CI job fails explicitly. This guarantees that automated testing cannot circumvent authorization requirements.

Supporting Documentation and Contracts

Multiple files reinforce the auth/scope gate policy:

Document	Purpose
README_AI.md	Instructs human operators to set auth.status=granted plus valid network_profile before any target ACT
AGENTS.md	Reiterates that offline samples require explicit authorization
skills/ops/scope-contract.md	Provides a checklist where auth.status = granted must be marked complete

This documentation layer ensures the gate is discoverable and understandable across different user roles.

Three-Layer Defense Architecture

The auth/scope gate operates through complementary enforcement layers:

1. Initialization layer — case-init scripts establish scope.md structure and default to pending status
2. Execution layer — case-guard scripts perform mandatory pre-flight checks with no override mechanism
3. Automation layer — CI workflows detect and reject any attempt to force past the gate

This defense-in-depth approach means authorization bypass would require coordinated changes across multiple independent components—making accidental or malicious circumvention extremely unlikely.

Summary

• The auth/scope gate requires auth.status=granted and a valid network_profile in scope.md before any ACT can execute
• skills/scripts/case-guard.sh and case-guard.ps1 implement the final authorization check with identical logic across platforms
• --force and -Force flags are explicitly rejected and treated as errors rather than bypasses
• CI enforcement in .github/workflows/ci.yml prevents automated pipelines from silently skipping authorization
• Initialization scripts, rules documents, and scope contracts create multiple touchpoints where the requirement is documented and validated

Frequently Asked Questions

What happens if I forget to set auth.status=granted?

The case-guard script will detect the missing or non-granted status, log an issue ("auth.status is not granted"), and abort the operation. No tools will execute against the target.

Can I use --force in an emergency situation?

No. According to RULES.md and the implementation in both case-guard variants, force flags never bypass the auth/scope gate. Attempting to use --force generates an explicit error and blocks execution. Authorization must be properly documented in scope.md.

How does the gate distinguish between different environments?

The network_profile field in scope.md specifies the environment context (lab, production, staging, etc.). The case-guard scripts validate this profile in addition to auth.status, ensuring both authorization and scope boundaries are confirmed before any action.

Where is the auth/scope gate enforced beyond local scripts?

The gate is enforced in CI through .github/workflows/ci.yml, which checks the case-guard exit code and fails the build if authorization is missing or if force flags were used. This prevents unauthorized execution in automated testing and deployment pipelines.

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