# How `case-guard.sh` Enforces Authorization Boundaries in Reverse-Skill

> Discover how case-guard.sh enforces authorization boundaries by validating scope.md for auth grants, network compliance, and asset definitions, ensuring secure ACT operations.

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

---

**[`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) enforces authorization boundaries by validating a case's [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file for mandatory auth grants, network profile compliance, asset definitions, and sign-off readiness before permitting any ACT operation.**

The [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) script in the `zhaoxuya520/reverse-skill` repository serves as a mandatory security gate that runs before any analysis, code execution, or tool invocation (ACT). By systematically inspecting the case's [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) configuration, it ensures that only properly authorized, scoped, and reviewed cases proceed through the workflow.

## Core Validation Checks

The script performs five sequential authorization boundary checks. Each failure accumulates an issue and ultimately blocks execution with exit code 2.

### 1. Presence of [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)

The gate first verifies that the case configuration exists at the expected path. In [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh) lines 33-37, the script aborts immediately if [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) is missing:

```bash
if [[ ! -f "$SCOPE_PATH" ]]; then
    fatal "scope.md not found at $SCOPE_PATH"
fi

```

Without this file, no authorization context exists—halting execution is the only safe response.

### 2. Auth Status Verification

The script extracts the `auth.status` field and requires it to be **granted**. Lines 67-72 implement this check:

```bash
AUTH_STATUS=$(yq '.auth.status' "$SCOPE_PATH")
if [[ "$AUTH_STATUS" != "granted" ]]; then
    ISSUES+=("auth.status is not granted")
fi

```

This enforces the fundamental authorization boundary: explicit permission must be recorded before any ACT can occur.

### 3. Network Profile Mode Restrictions

The `network_profile.mode` field must match an allowed whitelist: `offline`, `lab_only`, `authorized_target_only`, or `unrestricted_lab`. Additionally, `offline` mode requires evidence of offline sample availability. Lines 73-82 codify this:

```bash
NETWORK_MODE=$(yq '.network_profile.mode' "$SCOPE_PATH")
if [[ "$NETWORK_MODE" == "offline" ]]; then
    OFFLINE_CUE=$(yq '.network_profile.offline_sample // ""' "$SCOPE_PATH")
    if [[ -z "$OFFLINE_CUE" ]]; then
        ISSUES+=("network_profile.mode is offline without offline sample cue")
    fi
fi

```

This boundary prevents accidental online operations against unauthorized targets.

### 4. Asset Definition Requirements

When not operating in `offline` mode, the script validates that `in_scope.assets` contains at least one entry. Lines 88-106 check this:

```bash
if [[ "$NETWORK_MODE" != "offline" ]]; then
    ASSETS_COUNT=$(yq '.in_scope.assets | length' "$SCOPE_PATH")
    if [[ "$ASSETS_COUNT" -eq 0 ]]; then
        ISSUES+=("in_scope.assets appears empty")
    fi
fi

```

Empty asset lists in networked modes indicate incomplete scoping—a boundary violation that must block progress.

### 5. Sign-Off Readiness Flag

Finally, the script requires explicit confirmation that the case is ready for ACT. Lines 108-112 validate:

```bash
READY=$(yq '.signoff.ready_for_act' "$SCOPE_PATH")
if [[ "$READY" != "true" ]]; then
    ISSUES+=("ready_for_act is not true")
fi

```

This human-attested boundary ensures deliberate, reviewed authorization.

## Execution Outcomes

### Success Path

When all checks pass, the script outputs confirmation and exits cleanly (lines 14-17):

```bash

# Typical usage

bash skills/scripts/case-guard.sh --case-root work/my-case

# Output

# CASE-GUARD OK: work/my-case

# Exit code 0

```

### Failure Path

Any validation failure produces a detailed issue report and exit code 2 (lines 19-27):

```bash

# Missing authorization

bash skills/scripts/case-guard.sh --case-root work/my-case

# Output

# CASE-GUARD NOT READY: work/my-case

#  - auth.status is not granted

# Exit code 2

```

## The `--force` Flag Limitation

The script accepts a `--force` parameter for compatibility, but **this flag does not bypass authorization boundaries**. Lines 22-25 explicitly warn:

```bash

# Using --force (no effect on hard gates)

bash skills/scripts/case-guard.sh --case-root work/my-case --force

# Output when issues remain

# CASE-GUARD NOT READY: work/my-case

#  - auth.status is not granted

# CASE-GUARD: --force does not bypass scope hard gates.

# Exit code 2

```

According to the `zhaoxuya520/reverse-skill` source code, this design guarantees that `--force` cannot override the repository's mandatory authorization policy.

## File Structure and Integration

| File | Role in Authorization Enforcement |
|------|-----------------------------------|
| [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh) | Core gate implementation; validates all boundary conditions |
| `work/<case>/scope.md` | Per-case authorization record with `auth`, `network_profile`, `in_scope.assets`, and `signoff` sections |
| [`skills/scripts/case-init.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-init.sh) | Creates properly structured [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) during case setup |
| [`skills/config/routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) | Ensures [`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) executes before permitted ACT operations |

## Summary

- **[`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh)** validates five mandatory authorization boundaries before any ACT proceeds
- **Hard gates** ([`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) presence, `auth.status`, `ready_for_act`) cannot be bypassed by `--force`
- **Network profiles** restrict operational modes and require evidence for offline claims
- **Asset scoping** ensures target clarity in networked environments
- **Exit code 2** consistently signals authorization boundary violations for CI/CD integration

## Frequently Asked Questions

### What happens if [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) is missing?

The script calls `fatal` and exits immediately with a "scope.md not found" message. This is the first and most fundamental check at lines 33-37 in [`skills/scripts/case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/case-guard.sh). No further validation occurs without the configuration file present.

### Can `--force` override a denied authorization?

No. As explicitly implemented in lines 22-25, `--force` "does not bypass scope hard gates." The flag exists only for backward compatibility with calling scripts. Authorization boundaries require actual changes to [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) fields, not command-line flags.

### Which network profile modes are permitted?

The allowed values are `offline`, `lab_only`, `authorized_target_only`, and `unrestricted_lab`. The `offline` mode carries an additional requirement: the `network_profile.offline_sample` field must contain a valid offline sample cue such as "sample", "offline path", or a recognizable file extension.

### How does the script communicate validation results?

[`case-guard.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/case-guard.sh) uses exit codes and structured console output. Exit code 0 indicates all boundaries satisfied. Exit code 2 signals one or more violations, with each issue listed explicitly for diagnostic clarity. This design supports automated pipeline integration where exit code checking triggers appropriate workflow routing.