# How the case-init Script Enforces Authorization Gates Before ACT Execution

> Learn how the case-init script enforces authorization gates by creating a scope.md contract for validation. Discover how it secures ACT execution before it begins.

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

---

**TLDR:** The `case-init` script in the `zhaoxuya520/reverse-skill` repository enforces authorization gates by generating a machine-readable [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract that captures authorization evidence, network constraints, and asset scope, which [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) then validates to block Automated Capability Test (ACT) execution unless all security conditions are met.

The `reverse-skill` project implements a rigorous two-stage authorization gate system to ensure every ACT runs only against explicitly authorized targets. This article examines how [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) establishes these gates by preparing a case directory and writing a structured scope contract, and how [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh) enforces them at runtime.

## The Two-Stage Authorization Architecture

The authorization system operates as a **create-then-validate** pipeline. First, [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) prepares a case directory and writes a structured [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file containing all authorization metadata. Second, [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh) reads this contract and performs hard validation checks before allowing the ACT to proceed. This separation ensures that authorization decisions are auditable and tamper-evident.

## Stage 1: Establishing the Authorization Contract in case-init.sh

The initialization script captures authorization evidence through three complementary mechanisms that write to the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract.

### Preset-Driven Auth Grants

The script accepts security presets such as **`--preset offline-sample`**, **`--preset ctf-public`**, or the explicit **`--auth-granted`** flag. When invoked with these options (lines 73–86), the script sets `AUTH_GRANTED=1` and `AUTH_STATUS="granted"` in the environment. These presets encode trusted authorization contexts—such as local sample files or public CTF targets—eliminating the need for manual secret entry while maintaining an audit trail.

### Structured Scope Documentation

The script constructs an **`assets_block`** (lines 102–106) and writes a comprehensive [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file (lines 30–88) that serves as the single source of truth. Key fields include:

- `auth.status` (line 46): Records whether authorization was granted.
- `auth.basis` and `evidence_of_auth` (lines 47–48): Documents the legal or contractual basis for testing.
- `network_profile.mode` (lines 62–63): Defines the network interaction constraints.
- `ready_for_act` checklist entry (lines 80–81): A boolean flag indicating gate completion.

### The Hard-Gate Checklist

Before finalizing the scope, the script evaluates three internal flags: **`check_auth`**, **`check_scope`**, and **`check_net`** (lines 17–20). The final `ready_for_act` flag is set to `true` only when all required conditions are satisfied (lines 22–24):

- The `auth_status_resolved` variable equals `"granted"`.
- A valid network mode is defined.
- At least one in-scope asset exists (or an offline sample is present for offline mode).

## Stage 2: Runtime Enforcement via case-guard.sh

The [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) script performs the actual enforcement by reading only the contract sections defined in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md). It uses the **`section_field`** helper (lines 44–65) to extract values from [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

### The Four Mandatory Validation Checks

The guard validates four critical conditions before permitting ACT execution:

1. **Authorization Status Verification** – The `auth.status` field must explicitly equal `"granted"` (lines 67–71). Any other value, including empty or pending states, triggers a failure.
2. **Network Profile Validation** – The script confirms the `network_profile.mode` is supported. For `offline` mode, it additionally verifies the presence of an offline sample cue (lines 73–85).
3. **Asset Scope Confirmation** – At least one in-scope asset must be listed unless operating in `offline` mode (lines 88–106).
4. **Ready-for-Act Flag Check** – The `ready_for_act` field must be the string `"true"` (lines 9–12).

### Failure Handling and the --force Limitation

If any check fails, [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) aborts with **exit code 2** and prints the specific missing requirements (lines 19–27). Notably, the **`--force` flag never bypasses** these hard gates (lines 22–25); it may only override soft warnings, ensuring that authorization failures always block execution regardless of user flags.

## Practical Workflow Example

The following workflow demonstrates the complete authorization pipeline:

```bash

# Initialize a case with offline sample authorization

bash skills/scripts/case-init.sh \
    --hint "local apk analysis" \
    --preset offline-sample \
    --sample ./app.apk

# Inspect the generated authorization contract

cat work/<generated-case>/scope.md

# Validate gates before ACT execution (exits 0 only if authorized)

bash skills/scripts/case-guard.sh --case-root work/<generated-case>

# Proceed with skill execution only if guard succeeds

bash skills/scripts/master-route.sh --hint "apk reverse" \
    --case-root work/<generated-case>

```

If step three fails, the guard outputs the specific deficiency—such as `auth.status is not granted` or `ready_for_act is false`—and returns exit code 2, preventing [`master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/master-route.sh) from launching the ACT.

## Summary

- The [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) script generates a structured [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) contract that captures authorization evidence, network constraints, and asset scope.
- Preset flags like `--preset offline-sample` provide trusted authorization paths without requiring manual credential entry.
- The [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh) script enforces hard gates by validating four critical fields in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md): auth status, network profile, asset presence, and the ready-for-act flag.
- Authorization failures result in exit code 2, and the `--force` flag cannot bypass these security controls.
- Only after [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) exits successfully can the primary skill execution (ACT) proceed via [`master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/master-route.sh).

## Frequently Asked Questions

### What happens if case-guard.sh fails the authorization check?

When validation fails, [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) outputs the specific missing requirements to stderr and terminates with **exit code 2**. This exit code signals to calling scripts—such as [`master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/master-route.sh)—that the authorization gate is closed, preventing the ACT from executing. The error message identifies which check failed, such as missing `auth.status` or an undefined network profile.

### Can the --force flag bypass the authorization gates?

**No.** According to the source code in [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) (lines 22–25), the `--force` flag is explicitly designed to never bypass the hard authorization gates. While `--force` may override soft warnings or non-critical validations, the script maintains that auth status, network profile, and ready-for-act checks are mandatory regardless of force flags, ensuring security boundaries remain intact.

### What file contains the authorization evidence generated by case-init.sh?

The authorization evidence is persisted in **[`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)** within the generated case directory. This file contains structured fields including `auth.status`, `auth.basis`, `evidence_of_auth`, and `ready_for_act`, as written by [`case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-init.sh) between lines 30–88. The [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) script reads this file exclusively to determine authorization state.

### How does the script handle offline samples differently from network targets?

For offline samples, the script uses the **`--preset offline-sample`** flag to set `AUTH_STATUS="granted"` without requiring network credentials. The [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) records `network_profile.mode` as offline, and [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) validates this by checking for the presence of a sample file cue rather than live network assets (lines 73–85). This allows authorized analysis of local files while maintaining the same rigorous gate structure as network-based ACTs.