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

> Learn how the auth/scope gate in reverse-skill prevents unauthorized target access by enforcing strict authorization barriers before exploitation steps can proceed. Discover the critical role of scope.md and valid network profi...

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

---

**The auth/scope gate enforces a hard-coded authorization barrier that blocks all active exploitation steps until [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh), the script reads `auth status` from [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and aborts if not granted:

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) with default `auth.status=pending`
3. Display the resolved status for operator awareness

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) and [`RULES_zh.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES_zh.md):

> *"Run the platform-native case-init until [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) has `auth.status=granted` plus a legal `network_profile`. `-Force`/`--force` never bypasses the gate."*

This policy is actively enforced:

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/.github/workflows/ci.yml) workflow adds automated verification that prevents silent bypasses:

```yaml
- 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/README_AI.md) | Instructs human operators to set `auth.status=granted` plus valid `network_profile` before any target ACT |
| [`AGENTS.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/AGENTS.md) | Reiterates that offline samples require explicit authorization |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) before any ACT can execute
- **[`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/.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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

### How does the gate distinguish between different environments?

The `network_profile` field in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/.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.