How `case‑init.ps1` Establishes the Ops Gate with `auth.status=granted` in Reverse‑Skill

case‑init.ps1 enforces the operations gate through a validated, multi‑step resolution process that sets auth.status=granted only when explicit authorization is provided via CLI flags or parameters, then embeds this status into the scope.md contract.

The case‑init.ps1 script serves as the entry point for the reverse‑skill framework, preparing new case directories and generating the authoritative scope.md contract. A core security principle of this framework is the ops gate: downstream automation must not proceed without explicit authentication. This article examines exactly how case‑init.ps1 establishes this gate through parameter handling, validation logic, and contract generation.

Parameter Declaration for Auth Control

The script declares two complementary parameters that operators use to establish authorization status:

[Parameter()]
[switch] $AuthGranted,

[Parameter()]
[string] $AuthStatus

• [switch] $AuthGranted: A boolean flag that immediately grants authorization when present.
• [string] $AuthStatus: Allows explicit string values (pending, granted, denied, unknown) for precise control.

These parameters appear at lines 13‑14 of skills/scripts/case-init.ps1, giving operators flexible ways to set the ops gate.

The Auth Resolution Pipeline

case‑init.ps1 implements a layered resolution process that determines the final authStatusResolved value. The pipeline prioritizes explicit input while maintaining safe defaults.

Step 1: Default to Pending

$authStatusResolved = 'pending'

At initialization (lines 70‑71), the script assumes a restrictive posture. No operations can proceed without deliberate authorization.

Step 2: Immediate Grant via Switch

if ($AuthGranted) {
    $authStatusResolved = 'granted'
}

When -AuthGranted is supplied (lines 71‑72), the status flips directly to granted. This provides a concise CLI option for authorized operators.

Step 3: Explicit Status with Validation

if ($AuthStatus) {
    $clean = $AuthStatus.Trim().ToLower()
    $valid = @('pending','granted','denied','unknown')
    if ($clean -in $valid) {
        $authStatusResolved = $clean
    } else {
        Write-Warning "Invalid AuthStatus '$AuthStatus'; using '$authStatusResolved'"
    }
}

The -AuthStatus parameter (lines 72‑78) allows fine‑grained control. The script:

• Normalizes input via Trim().ToLower()
• Validates against an explicit allowlist
• Falls back gracefully with a warning for invalid values

Evidence and Audit Trail

The script constructs an evidenceAuth variable (lines 83‑87) that documents how authorization was established:

if ($AuthGranted) {
    $evidenceAuth = "cli-flag AuthGranted"
} elseif ($AuthStatus) {
    $evidenceAuth = "AuthStatus=$authStatusResolved"
} else {
    $evidenceAuth = "default pending"
}

This audit trail becomes part of the permanent case record, supporting compliance and forensic review.

The Ready‑for‑Act Gate Check

Authorization alone does not open the ops gate. The script enforces three mandatory conditions at lines 25‑31:

$ready = (
    ($authStatusResolved -eq 'granted') -and
    ($inScopeAssets.Count -gt 0) -and
    ($NetworkProfile -ne 'offline')
)

Condition	Purpose
authStatusResolved -eq 'granted'	Explicit authorization confirmed
inScopeAssets.Count -gt 0	At least one target asset defined
NetworkProfile -ne 'offline'	Network mode permits action

If any condition fails, ready remains $false and the script emits a diagnostic warning. This multi‑factor gate prevents accidental execution against unauthorized or undefined targets.

Scope.md Contract Generation

The authoritative enforcement mechanism is the generated scope.md file (lines 98‑102). The script injects the auth block:

## auth

- status: granted
- basis: own_system
- evidence_of_auth: cli-flag AuthGranted
- MUST NOT proceed if status != granted

The hard comment “MUST NOT proceed if status != granted” creates a machine‑readable and human‑auditable contract. Downstream tools—including master‑route.ps1—parse this file and respect its constraints.

Runtime Verification

The script concludes with explicit console output (lines 15‑16):

Write-Host "auth.status=$authStatusResolved network_profile=$NetworkProfile ready_for_act=$readyStr"

Operators immediately verify gate status:

auth.status=granted network_profile=authorized_target_only ready_for_act=true

Practical CLI Examples

Create a Pending Case (No Authorization)

powershell -File skills/scripts/case-init.ps1 -Hint "web pentest"

Result: auth.status=pending, ready_for_act=false

Grant Authorization via Switch

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthGranted -TargetUrl "https://target.example/"

Result: auth.status=granted, ready status depends on assets and network profile.

Explicit Status Override

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthStatus "granted" -TargetUrl "https://target.example/"

Equivalent to -AuthGranted with explicit string control.

Force Ready State with Full Prerequisites

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" -AuthGranted -TargetUrl "https://target.example/" `
    -NetworkProfile authorized_target_only -ReadyForAct

This demonstrates the complete gate opening: granted auth, defined assets, and permissive network profile.

Key Files in the Ops Gate Architecture

File	Role
skills/scripts/case-init.ps1	Core script; resolves auth status and enforces gate conditions.
skills/scripts/lib/WorkRoot.ps1	Discovers work directory for case placement.
skills/ops/scope-contract.md	Specification defining auth.status requirements for downstream tools.
skills/scripts/master-route.ps1	Optional router that respects the scope contract for skill execution.

These components form a defense‑in‑depth system where case‑init.ps1 establishes the gate and downstream automation validates it.

Summary

• case‑init.ps1 default posture is restrictive: auth.status starts as pending and gates remain closed.
• Authorization requires explicit action: Operators must supply -AuthGranted or valid -AuthStatus.
• Validation prevents configuration errors: Invalid status strings are rejected with warnings.
• Multi‑factor readiness check: ready_for_act demands granted auth, defined assets, and non‑offline network.
• scope.md becomes the single source of truth: The contract embeds status and enforcement language for all downstream tools.

Frequently Asked Questions

What happens if I provide both -AuthGranted and -AuthStatus?

The switch takes precedence in resolution order, but explicit -AuthStatus subsequently overwrites if valid. In practice, use one or the other to avoid confusion. The final authStatusResolved reflects the last valid assignment.

Can I bypass the ops gate by editing scope.md manually?

While physical file access permits modification, the design intent treats scope.md as the authoritative contract. Framework tools validate the file's integrity through additional mechanisms. Operational procedures should treat unauthorized modifications as security incidents.

Why does the script require assets and network profile for ready_for_act?

The three‑condition gate prevents two common failure modes: executing against undefined targets (empty asset list) and attempting network operations in air‑gapped mode (offline profile). This aligns with the principle of least privilege in offensive security workflows.

How do downstream tools consume the auth.status value?

Tools like master-route.ps1 parse the generated scope.md and check the ## auth block before executing skills. The hard comment "MUST NOT proceed if status != granted" serves as both human instruction and parsing anchor for automated validators.

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