# How to Grant Authorization for a Case in reverse-skill: A Complete Guide

> Learn to grant authorization for a case in reverse-skill using the case-init.ps1 script and verify its status. Follow this guide for seamless case management.

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

---

**Grant authorization in reverse-skill by running `skills/scripts/case-init.ps1` with the `-AuthGranted` flag or a preset that implicitly sets `auth.status=granted`, then verify that `ready_for_act=true` appears in the generated `work/<case>/scope.md` file.**

The reverse-skill repository implements a strict authorization gate that blocks any ACT (analysis, exploitation, or testing) until explicit permission is documented. Before you can execute offensive security operations, you must initialize a case with proper authorization credentials and scope definitions using the PowerShell initialization script. This guide walks you through the exact commands, parameters, and validation steps required to satisfy the authorization contract enforced by the framework.

## Understanding the Authorization Gate in reverse-skill

Reverse-skill enforces a hard authorization gate through `skills/scripts/case-init.ps1` before any ACT phase can begin. The script generates a [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file in `work/<case>/` that serves as the legal and technical contract for the engagement.

The authorization status is stored in the **auth** section of [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and must resolve to `granted` for the case to proceed. According to the source code in `case-init.ps1` (lines 58-78), the script evaluates multiple input parameters to determine the final `auth.status` value and the corresponding `network_profile` restrictions.

## Prerequisites for Granting Case Authorization

The script sets the `ready_for_act` flag to `true` only when three mandatory conditions converge:

1. **Authorization Status**: The `auth.status` field must explicitly read **granted**.
2. **Scope Definition**: At least one in-scope asset must be present via `-TargetUrl`, `-Sample`, or `-InScopeAssets`.
3. **Network Profile**: The selected `network_profile` must permit ACT operations (the `offline` profile only works with explicit local samples).

If any condition fails, `ready_for_act` remains `false` and the script outputs a README_NEXT block instructing you to manually edit [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

## Methods to Grant Authorization

You can establish authorized status through three distinct input methods, each writing to the auth block in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

### Using the -AuthGranted Flag

The simplest method passes the boolean switch `-AuthGranted` to immediately set `auth.status: granted`.

```powershell
powershell -File skills/scripts/case-init.ps1 `
  -Hint "web pentest" `
  -CaseName my-web-case `
  -AuthGranted `
  -TargetUrl "https://app.example.com" `
  -NetworkProfile authorized_target_only

```

This command creates the case directory, writes the authorization record, and marks the target URL as in-scope.

### Using -AuthStatus for Explicit Control

For granular control over authorization states, use the `-AuthStatus` parameter with validated values (`pending`, `granted`, `denied`, or `unknown`).

```powershell
powershell -File skills/scripts/case-init.ps1 `
  -Hint "custom case" `
  -CaseName custom-case `
  -AuthStatus granted `
  -NetworkProfile lab_only `
  -InScopeAssets "192.168.1.10" "10.0.0.5"

```

The script validates the input against the allowed enumeration before writing to [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

### Using Presets for Implicit Authorization

Presets such as `-Preset offline-sample`, `ctf-public`, or `own-system` automatically set `auth.status=granted` while configuring compatible `network_profile` and `evidence_of_auth` fields.

```powershell
powershell -File skills/scripts/case-init.ps1 `
  -Hint "offline apk" `
  -CaseName my-apk-sample `
  -Preset offline-sample `
  -Sample ".\app.apk"

```

As implemented in `case-init.ps1` (lines 58-78), these presets bundle authorization with environment-specific defaults.

## Configuring Network Profiles for ACT

The `network_profile` parameter defines the operational boundaries and must align with your authorization type. Available modes include:

- **`offline`**: For local samples only; requires explicit `-Sample` input.
- **`lab_only`**: Restricts activity to designated lab infrastructure.
- **`authorized_target_only`**: Permits live targeting of explicitly authorized assets.
- **`unrestricted_lab`**: Broader lab access with fewer network constraints.

For live penetration testing targets, you must specify `authorized_target_only` or `unrestricted_lab` alongside granted authorization status.

## Step-by-Step Workflow to Grant Authorization

Follow this sequence to properly authorize a case in reverse-skill:

1. **Execute case-init.ps1** with either `-AuthGranted` or a preset that includes implicit authorization.
2. **Define the network profile** using `-NetworkProfile` to match your engagement type.
3. **Supply scope assets** via `-TargetUrl`, `-Sample`, or `-InScopeAssets` to satisfy the in-scope requirement.
4. **Review the script output** confirming `auth.status`, `network_profile`, and `ready_for_act` values.
5. **Inspect `work/<case>/scope.md`** to verify the YAML structure contains the auth block and signoff section.

## Validating Authorization in scope.md

After initialization, examine `work/<case>/scope.md` to confirm authorization before proceeding to the primary skill. The file should contain:

```yaml

## auth

- status: granted
- basis: own_system
- evidence_of_auth: cli-flag AuthGranted or preset …

## network_profile

- mode: authorized_target_only

```

Locate the **signoff** section and confirm `ready_for_act: true`. Only when this flag appears may you open the primary skill and begin the ACT phase, per the routing rules defined in [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md).

## Summary

- **Authorization Gate**: Reverse-skill blocks ACT operations until `skills/scripts/case-init.ps1` creates a valid [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) with `auth.status: granted`.
- **Grant Methods**: Use `-AuthGranted`, `-AuthStatus granted`, or authorization-bearing presets (`offline-sample`, `ctf-public`, `own-system`).
- **Mandatory Scope**: You must provide at least one target asset via `-TargetUrl`, `-Sample`, or `-InScopeAssets`.
- **Network Alignment**: Select a non-offline `network_profile` for live targets; `offline` requires local samples.
- **Validation**: Verify `ready_for_act: true` in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) before engaging the primary skill.

## Frequently Asked Questions

### What happens if I try to run ACT without granting authorization?

The framework will abort the operation. According to [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) and the routing logic in the repository, the master route checks for `ready_for_act=true` in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) before dispatching to any primary skill. Without explicit authorization documented in the auth block, the gate remains closed and the system prompts you to complete case initialization.

### Can I change authorization status after creating the case?

Yes. You can manually edit `work/<case>/scope.md` to modify the `auth.status` field, or rerun `case-init.ps1` with the same case name and updated parameters. The script regenerates the scope contract, but you must verify that `ready_for_act` recalculates to `true` after any changes to authorization or scope assets.

### Why does the offline preset grant authorization automatically?

The `offline-sample` preset implies you are analyzing your own files or publicly available CTF samples where you inherently own the asset or have explicit permission to analyze it. As coded in `case-init.ps1` (lines 58-78), this preset sets `auth.status=granted` with `basis: own_system` or equivalent evidence, eliminating the need for explicit contractual authorization required for third-party targets.

### What is the difference between -AuthGranted and -AuthStatus?

`-AuthGranted` is a boolean switch that sets the status to `granted` without additional parameters. `-AuthStatus` accepts a string value (`pending`, `granted`, `denied`, `unknown`) allowing you to initialize cases in non-granted states for workflow tracking. Both write to the same `auth.status` field in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md), but `-AuthStatus` provides explicit state machine control for complex engagement workflows.